ISA标准和惯例ISA(InteractiveServicesArchitecture)交互式服务架构1)软件设计模式ISA设计团队采用Factory模式来实现ISA设计的主要方面。2)UMLISA架构使用RationalRose设计工具来创建复杂的面向对象系统的对象模型。3)ISA1.4的实现ISA1.4的实现采用下面的软件:CORBA(CommonObjectRequestBrokerArchitecture)2.0IDLXMLIIOP作为基本的互操作能力协议4)ISA对象模型分布式对象技术:采用CORBA2.0作为理想的ISA兼容系统的实现,理由:面向对象的能力定位的独立性语言的独立性实现的独立性硬件架构的独立性操作系统的独立性协议的独立性传输的独立性5)CORBA服务CORBA提供了大量的预定义服务,(1)命名服务任何分布式系统都要解决的关键问题之一是怎样获得对象的引用,不管对象的实际位置。对象位置透明是CORBA的主要特征之一。CORBA命名服务提供了一个分层的分布式命名服务。(当服务器对象开始执行时,它用CORBA命名服务注册自身为一特殊的名字。客户端可使用此名字向命名服务器发出一请求,然后命名服务器返回一对象引用供客户端调用对象的方法。)为了客户端高效使用命名服务,ISA定义了标准的命名分层结构,客户端很清楚要使用的对象的标准名字。(2)命名结构CORBA命名服务以树结构分层命名的方式存储对象引用,类似于Windows的文件系统。ISA架构采用了一个非常特殊的策略来使用CORBA命名服务和决定注册到命名服务的对象类型。此策略就是命名服务中的FactoryObjectReference。Factory模式是:将对象的创建交由父类中定义的一个标准方法来完成,而不是其构造函数,究竟该创建何种对象由具体的子类负责决定,并提供一个共同的接口来创建相互关联的多个对象。Factory对象是创建其它对象的对象。(3)通知服务分布式系统中,当一些组件感兴趣的事件出现后,需要通知相关的系统组件。CORBA通知服务提供了一个框架来异步发送通信消息(通知)到对象,提醒指定的事件已发生。CORBA通知服务使用supplier/consumer分布式模型。ISA事件模型由下面组件组成:·PUSHSupplier(推供应商):一ISA组件、连接到“代理推消费者”,通过调用适当的推方法来传输事件数据到消费者。·ProxyPushConsumer(代理推消费者):事件通道支持的一个接口,代理所有注册到事件通道的推消费者,接收事件并发送到实际的消费者。·PushConsumer(推消费者):一ISA组件,连接到代理推消费者.·ProxyPushSupplier(代理推供应商):事件通道支持的一个接口,工作在事件通道的消费者端。消费者连接“代理推供应商”。(4)通知服务支持三种方式的事件交付·InCORBA::Any·ACosNotification::StructuredEvent·AsequenceofStructuredEvents基于事件通知使用的类型,适当的代理消费者和供应商必须被用于各自的供应商和消费者端。事件通知经事件通道发送到组件。一个事件通道是一个CORBA对象,它允许其它的对象相互通信而无需知道对方。供应商是对象,提供事件到事件通道。消费者是对象,从事件通道接收事件。提供事件的过程有时是调用publishing事件。通知服务提供了QoS设置,允许应用程序控制为事件消息交付的QoS所需的东西。ISA事件模型使用通知服务的通信推事件模型。(此模型中,每个个体都关注事件通道提供的代理消费者。代理消费者从供应商处接收事件通信,然后使用代理供应商传递事件数据到实际的消费者。简单说,供应商调用在消费者的接口来推事件。(5)事件过滤通知服务支持事件过滤,给事件消费者过滤事件的能力。事件消费者能定义过滤器,它封装了一套限制,并添加到proxy或admin。过滤器包含了限制表达式,限制表达式定义了过滤标准。每个限制表达式由事件类型序列组成,使用限制语言,缺省的限制语言是EXTENDED_TCL。实时流协议RTSP(RealTimeStreamingProtocol)是由RealNetworks和Netscape共同提出的,该协议定义了一对多应用程序如何有效地通过IP网络传送多媒体数据。RTSP在体系结构上位于RTP和RTCP之上,它使用TCP或RTP完成数据传输。HTTP与RTSP相比,HTTP传送HTML,而RTP传送的是多媒体数据。HTTP请求由客户机发出,服务器作出响应;使用RTSP时,客户机和服务器都可以发出请求,即RTSP可以是双向的。6.3RTSP协议实时流协议(RTSP)是应用级协议,控制实时数据的发送。RTSP提供了一个可扩展框架,使实时数据,如音频与视频,的受控、点播成为可能。数据源包括现场数据与存储在剪辑中数据。该协议目的在于控制多个数据发送连接,为选择发送通道,如UDP、组播UDP与TCP,提供途径,并为选择基于RTP上发送机制提供方法。6.3.1简介6.3.1.1目的实时流协议(RTSP)建立并控制一个或几个时间同步的连续流媒体。尽管连续媒体流与控制流交*是可能的,通常它本身并不发送连续流。换言之,RTSP充当多媒体服务器的网络远程控制。RTSP连接没有绑定到传输层连接,如TCP。在RTSP连接期间,RTSP用户可打开或关闭多个对服务器的可*传输连接以发出RTSP请求。此外,可使用无连接传输协议,如UDP。RTSP流控制的流可能用到RTP,但RTSP操作并不依赖用于携带连续媒体的传输机制。实时流协议在语法和操作上与HTTP/1.1类似,因此HTTP的扩展机制大都可加入RTSP。协议支持的操作如下:从媒体服务器上检索媒体:用户可通过HTTP或其它方法提交一个演示描述。如演示是组播,演示式就包含用于连续媒体的的组播地址和端口。如演示仅通过单播发送给用户,用户为了安全应提供目的地址。媒体服务器邀请进入会议:媒体服务器可被邀请参加正进行的会议,或回放媒体,或记录其中一部分,或全部。这种模式在分布式教育应用上很有用,会议中几方可轮流按远程控制按钮。将媒体加到现成讲座中:如服务器告诉用户可获得附加媒体内容,对现场讲座显得尤其有用。如HTTP/1.1中类似,RTSP请求可由代理、通道与缓存处理。6.3.1.2协议特点RTSP特性如下:可扩展性:新方法和参数很容易加入RTSP。易解析:RTSP可由标准HTTP或MIME解吸器解析。安全:RTSP使用网页安全机制。独立于传输:RTSP可使用不可*数据报协议(UDP)、可*数据报协议(RDP),如要实现应用级可*,可使用可*流协议。多服务器支持:每个流可放在不同服务器上,用户端自动同不同服务器建立几个并发控制连接,媒体同步在传输层执行。记录设备控制:协议可控制记录和回放设备。流控与会议开始分离:仅要求会议初始化协议提供,或可用来创建唯一会议标识号。特殊情况下,SIP或H.323可用来邀请服务器入会。适合专业应用:通过SMPTE时标,RTSP支持帧级精度,允许远程数字编辑演示描述中立:协议没强加特殊演示或元文件,可传送所用格式类型;然而,演示描述至少必须包含一个RTSPURI。代理与防火墙友好:协议可由应用和传输层防火墙处理。防火墙需要理解SETUP方法,为UDP媒体流打开一个缺口。HTTP友好:此处,RTSP明智的采用HTTP观念,使现在结构都可重用。结构包括Internet内容选择平台(PICS)。由于在大多数情况下控制连续媒体需要服务器状态,RTSP不仅仅向HTTP添加方法。适当的服务器控制:如用户启动一个流,他必须也可以停止一个流。传输协调;实际处理连续媒体流前,用户可协调传输方法。性能协调:如基本特征无效,必须有一些清理机制让用户决定那种方法没生效。这允许用户提出适合的用户界面。6.3.1.3扩展RTSP由于不是所有媒体服务器有着相同的功能,媒体服务器有必要支持不同请求集。RTSP可以如下三种方式扩展,这里以改变大小排序:以新参数扩展。如用户需要拒绝通知,而方法扩展不支持,相应标记就加入要求的段中。加入新方法。如信息接收者不理解请求,返回501错误代码(还未实现),发送者不应再次尝试这种方法。用户可使用OPTIONS方法查询服务器支持的方法。服务器使用公共响应头列出支持的方法。定义新版本协议,允许改变所有部分。(除了协议版本号位置)6.3.1.4操作模式每个演示和媒体流可用RTSPURL识别。演示组成的整个演示与媒体属性由演示描述文件定义。使用HTTP或其它途径用户可获得这个文件,它没有必要保存在媒体服务器上。为了说明,假设演示描述描述了多个演示,其中每个演示维持了一个公共时间轴。为简化说明,且不失一般性,假定演示描述的确包含这样一个演示。演示可包含多个媒体流。除媒体参数外,网络目标地址和端口也需要决定。下面区分几种操作模式:单播:以用户选择的端口号将媒体发送到RTSP请求源。组播,服务器选择地址:媒体服务器选择组播地址和端口,这是现场直播或准点播常用的方式。组播,用户选择地址:如服务器加入正在进行的组播会议,组播地址、端口和密匙由会议描述给出。6.3.1.5RTSP状态RTSP控制通过单独协议发送的流,与控制通道无关。例如,RTSP控制可通过TCP连接,而数据流通过UDP。因此,即使媒体服务器没有收到请求,数据也会继续发送。在连接生命期,单个媒体流可通过不同TCP连接顺序发出请求来控制。所以,服务器需要维持能联系流与RTSP请求的连接状态。RTSP中很多方法与状态无关,但下列方法在定义服务器流资源的分配与应用上起着重要的作用:SETUP:让服务器给流分配资源,启动RTSP连接。PLAY与RECORD:启动SETUP分配流的数据传输。PAUSE:临时停止流,而不释放服务器资源。TEARDOWN:释放流的资源,RTSP连接停止。标识状态的RTSP方法使用连接头段识别RTSP连接,为响应SETUP请求,服务器连接产生连接标识。6.3.1.6与其他协议关系RTSP在功能上与HTTP有重叠,与HTTP相互作用体现在与流内容的初始接触是通过网页的。目前的协议规范目的在于允许在网页服务器与实现RTSP媒体服务器之间存在不同传递点。例如,演示描述可通过HTTP和RTSP检索,这降低了浏览器的往返传递,也允许独立RTSP服务器与用户不全依*HTTP。但是,RTSP与HTTP的本质差别在于数据发送以不同协议进行。HTTP是不对称协议,用户发出请求,服务器作出响应。RTSP中,媒体用户和服务器都可发出请求,且其请求都是无状态的;在请求确认后很长时间内,仍可设置参数,控制媒体流。重用HTTP功能至少在两个方面有好处,即安全和代理。要求非常接近,在缓存、代理和授权上采用HTTP功能是有价值的。当大多数实时媒体使用RTP作为传输协议时,RTSP没有绑定到RTP。RTSP假设存在演示描述格式可表示包含几个媒体流的演示的静态与临时属性。6.3.2协议参数6.3.3RTSP信息RTSP是基于文本的协议,采用ISO10646字符集,使用UTF-8编码方案。行以CRLF中断,但接收者本身可将CR和LF解释成行终止符。基于文本的协议使以自描述方式增加可选参数更容易。由于参数的数量和命令的频率出现较低,处理效率没引起注意。如仔细研究,文本协议很容易以脚本语言(如:Tcl、VisualBasic与Perl)实现研究原型。10646字符集避免敏感字符集切换,但对应用来说不可见。RTCP也采用这种编码方案。带有重要意义位的ISO8859-1字符表示如100001x10xxxxxx.。RTSP信息可通过任何低层传输协议携带。请求包括方法、方法作用于其上的对象和进一步描述方法的参数。方法也可设计为在服务器端只需要少量或不需要状态维护。当信息体包含在信息中,信息体长度有如下因素决定:不管实体头段是否出现在信息中,不包括信息体的的响应信息总以头段后第一和空行结束。如出现内容长度头段,其值以字节计,表示信息体长度。如未出现头