具体实施方式
示例性操作环境
图1示例说明可以实现本发明的合适的计算***环境100的例子。计算***环境100仅是合适的计算环境的一个例子以及不打算提出有关本发明的使用或功能性的范围的任何限制。也不应当将计算环境100解释为对于在示例性操作环境100示出的部件的任何一个或组合有任何依赖性或要求。
本发明用多个其他通用或专用计算***环境或配置来操作。适合于与本发明一起使用的众知的计算***、环境和/或结构的例子包括,但不限于:个人计算机,服务器计算机、手持或膝上型设备、图形输入板设备、微处理器***、基于微处理器的***、机顶盒、可编程消费者电子设备、网络PCs、小型计算机、大型计算机、包括任何上述***或设备的分布式计算环境等等。
在由计算机执行的计算机可执行指令,诸如程序模块的一般环境中,描述本发明。通常,程序模块包括例程、程序、对象、部件、数据结构等等,它们执行特定的任务或实现特定的抽象数据类型。本发明也可以在分布式计算环境中实现,其中,由通过通信网络链接的远程处理设备执行任务。在分布式计算环境中,程序模块加载在包括存储器件的本地和/或远程计算机存储介质中。
参考图1,用于实现本发明的示例性***包括以计算机110的形式的通用计算设备。计算机110的部件可以包括但不限于处理单元120、***存储器130和将包括***存储器的各种***部件连接到处理单元120的***总线121。***总线121可以是包括存储器总线或存储器控制器、***总线和使用各种总线体系结构的任何一个的局部总线的几种总线结构的任何一个。举例来说,但不是限制,这种体系结构包括工业标准体系结构(ISA)总线、微通道体系结构(MCA)总线、增强ISA(EISA)总线、视频电子技术标准协会(VESA)总线以及也称为Mezzanine总线的***部件互连(PCI)总线。
计算机110通常包括各种计算机可读介质。计算机可读介质能是能由计算机110存取的任何可用介质,包括易失和非易失介质,以及可移动和不可移动介质。举例来说,但不是限制,计算机可读介质可以包括计算机存储介质和通信介质。计算机存储介质包括以任何方法或技术实现的易失和非易失、可移动和不可移动介质,用于存储诸如计算机可读指令、数据结构、程序模块和其他数据的信息。计算机存储介质包括但不限于RAM、ROM、EEPROM、闪存或其他存储技术,CD-ROM、数字万用盘(DVD)或其他光盘存储器、磁带盒、磁带、磁盘存储器或其他磁性存储器件,或能用来存储所需信息并能由计算机110存取的任何其他介质。通信介质通常具体化为以调制数据信号,诸如载波或其他传输机制的计算机可读指令、数据结构、程序模块或其他数据,并包括任何信息递送介质。术语“调制数据信号”是指具有在信号中编码的方式设置或改变的一个或多个特性的信号。举例来说,但不是限制,通信介质包括有线介质,诸如有线网络或直接导线连接,以及无线介质,诸如声波、RF、红外和其他无线介质。上述的任何的组合应当包括在计算机可读介质的范围内。
***存储器130包括以易失和/或非易失存储器,诸如只读存储器(ROM)131和随机存取存储器(RAM)132形式的计算机存储介质。基本输入/输出***133(BIOS),包含诸如在启动期间,有助于在计算机110内的元件间传送信息的基本例程,通常存储在ROM131中。RAM132通常包含立即由处理单元120存取和/或当前正由处理单元120操作的数据和/或程序模块。举例来说,但不是限制,图1示例说明操作***134、应用程序135、其他程序模块136和程序数据137。
计算机110也可以包括其他可移动/不可移动、易失/不可易失计算机存储介质。仅举例来说,图1示例说明读取或写入不可移动、非易失磁性介质的硬盘驱动器141、读取或写入可移动、不可易失磁盘152的磁盘驱动器151,以及读取或写入可移动、不可易失光盘156,诸如CD ROM或其他光学介质的光盘驱动器155。能用在示例性操作环境中的其他可移动/不可移动、易失/不可易失计算机存储介质包括但不限于磁带盒、闪存卡、数字多功能盘、数字视频带、固态RAM、固态ROM等等。硬盘驱动器141通常通过不可移动存储器接口,诸如接口140连接到***总线121,而磁盘驱动器151和光盘驱动器155一般通过可移动存储器接口,诸如接口150,连接到***总线121。
如上所述以及图1所示的驱动器和它们相关的计算机存储介质为计算机110提供计算机可读指令、数据结构、程序模块和其他数据的存储。在图1中,例如,硬盘驱动器141示例为存储操作***144、应用程序145、其他程序模块146和程序数据147。注意这些部件能与操作***134、应用程序135、其他程序模块136和程序数据137相同或不同。操作***144、应用程序145、其他程序模块146和程序数据147在此给予不同的编号以示例说明至少,它们是不同拷贝。用户可以通过输入设备,诸如图形输入板,或电子数字化仪164、麦克风163、键盘162和意指鼠标、跟踪球或触控板的定位设备161,将命令和信息输入到计算机110中。在图1中未示出的其他输入设备可以包括操纵杆、游戏垫、卫星盘、扫描仪等等。这些和其他输入设备通常通过连接到***总线的用户输入接口160,连接到处理单元120,但也可以由其他接口和总线结构,诸如并行端口、游戏端口或通用串行总线(USB)口连接。监视器191或其他类型的显示设备也可以经接口,诸如视频接口190连接到***总线121。监视器191也可以与触摸屏面板等等集成。注意监视器和/或触摸屏面板能物理地连接到包含计算设备110的外壳,诸如在图形输入板型个人计算机中。另外,计算机,诸如计算设备110也可以包括其他***输出设备,诸如扬声器195和打印机196,它们可以通过输出***接口194等等连接。
计算机110可以使用到一个或多个远程计算机,诸如远程计算机180的逻辑连接,在连网环境中操作。远程计算机180可以是个人计算机、服务器、路由器、网络PC、对等设备或其他公用网络节点,并通常包括相对于计算机110所述的许多或全部元件,尽管在图1中仅示例说明存储器存储设备181。图1中所述的逻辑连接包括局域网(LAN)171和广域网(WAN)173,但也可以包括其他网络。这些连网环境在办公室、企业范围计算机网络、内联网和互联网中是很普遍的。例如,在本发明中,计算机***110可以包括从其迁移数据的源机器,而远程计算机180可以包括目的机器。然而注意,源和目的机器不需要由网络或任何其他装置连接,而相反,可以通过由源平台写入和由一个或多个目的平台读取的任何介质迁移数据。
当用在LAN连网环境中时,计算机110通过网络接口或适配器170,连接到LAN171。当用在WAN连网环境中时,计算机110通常包括调制解调器172或用于在诸如互联网的WAN173上建立通信的其他装置。可以为内部或外部的调制解调器172可以经用户输入接口160或其他适当的机构,连接到***总线121。在连网环境中,相对于计算机110画出的程序模块或其一部分可以存储在远程存储器存储设备中。举例来说,但不是限制,图1示例说明驻留在存储器设备181上的远程应用程序185。将意识到所示的网络连接是示例性的,可以使用能在计算机之间建立通信链路的其他装置。
网络服务应用协议和SOAP处理模型
在分布式编程模型中,基本的编程原语是轻便端口(lightweight port),包括能用来存储状态和产生通信的无序消息集合。通过引用存储项,以及端口支持(至少)两个原语操作:Post()和Get()。登记项,诸如类范例缓存该引用并立即返回。如果没有由远程服务能登记具有该关键字的项,基于所提供的关键字检索项能阻止。尽管由服务直接使用端口,但它们通常在将特定消息类型与集合中的每个端口关联的端口集合的环境内使用。根据所需的灵活度,用固定或动态的支持消息类型集,创建端口集合,但从程序员的视点看,端口集合简单的是打字端口。
与本发明一致,使用严格的端口通信,服务码能实现关键部件以及复杂的I/O协议以及产生非常同时的处理模型。为此,本发明部分针对用于与网络服务通信的协议(网络服务应用协议或WSAP),其中,客户机消费者请求服务提供者为该客户机执行一些服务,以及为客户机提供适当的响应。然而,如将理解到,通用网络服务模型不限于服务器为客户机运行软件,而是应用于客户机希望访问的任何资源,诸如由WSAP支持的统一服务模型能用来模拟文件、设备、服务和人。例如,可以某种程度上组件化硬件,以及在许多方面,实际上,将与面向软件的网络服务不可区分,因为用户可以选择硬件部件集以及将它们互连以执行计算任务。只要每个设备服从通信协议,(以及适当的带宽量可用),实际上,任何授权的设备将能与另一设备通信来使用它的资源。
图2表示包括经在SOAP(简单对象访问协议)包中传送的WSAP消息,与网络服务204通信的网络客户机码202(例如,可以是图1的计算机***110)的体系结构200。用命名端口(例如URI)描述服务的身份,而通常由XML模式来描述服务的状态。注意,服务可以是本地(在与客户机码相同的机器内)或可以是远程资源,诸如服务器或硬件设备。通常,如下所述,WSAP语义上定义网络服务做什么,而SOAP处理模型定义如何组成并行或顺序运行的多个网络服务,以及可以根据本发明使用来经基本上与外部网络服务相同的方式,例如经存储器内非XML串行化数据,组成对计算设备的内部服务。
关于其他网络服务,WSAP可能的服务通过响应订约请求,提供订约来操作,如在图2中所示,通过网络服务订约请求206和订约提供208。注意,在WSAP中,为获得订约,将端口展现给对应于LOOKUP操作的客户机,如下所述。也如下所述,向捆绑列表信息提供响应208,例如,作为对应于“示例”订约的关键字/值对的数组的标识符/端口,如下所述。不要求服务来实现不是LOOKUP操作的WSAP操作,,尽管当交互作用的语义与WSAP操作兼容时,WSAP服务应当实现WSAP操作。在提供服务中,服务发起人可以使用WSAP动词和表示,映射任何交互作用或服务功能性。并非所有WSAP动词必须用于特定的服务,而相反,根据情况,可以使用子集。
根据本发明的一方面,WSAP是用在借助能根据服务的行为使用的身份、状态和操作集,定义网络服务的分布式计算环境中的基于SOAP的协议。这有效地允许服务和它们的状态以一致和可观察方式操作。在WSAP中,行为网络服务是具有身份和行为的过程的抽象概念。该概念在能应用于许多不同应用模型和名字空间方面是抽象的。WSAP定义一种这样的应用模型,它已经设计成扩大到整个Internet,但许多其他的应用模型也是可能的。
WSAP中的身份的概念与由传统的网络模型中的URI识别的资源的概念类似,即具有身份的任何事。身份的目的是允许服务将其自己与可能存在于相同名字空间中的其他服务区分开来。如在此所述,WSAP网络服务的范围可以是Internet,表示DNS或IP是用于URI“授权”部件的命名授权,尽管在更有限的范围内,诸如在设备或有限网络内,另一命名授权(naming authority)也是可行的。
每个WSAP网络服务具有唯一身份,诸如与在图3中示例的URI。关于任何其他URI(诸如网络上),仅基于URI,不能获得语义知识,以及类似地,不能从它们的URIs推导两个WSAP网络服务之间的关系(如牵制关系)。在WSAP中,URIs可以是相对或绝对的。如果URI是相对的,那么由XML基础(XML base)确定其基础。WSAP对URI的长度没有任何限制,由此任何WSAP接收机需要能处理其公布的任何URI的长度;WSAP实现应当能处理至少两个千字节长度的URIs。
服务间的交互作用(能视为协议)是服务的行为,并能形式上描述为行为类型订约是使用行为类型的服务的描述。能用各种方式执行服务,只要符合它要求实现的订约。注意在WSAP中,订约是象基本上任何其他事的服务,由此由端口(例如URIs)识别订约以及能根据其订约,如任何其他服务那样操作。
行为的概念基于根据它生成和接收的消息类型的序列,服务与其环境如何交互作用。行为允许服务将其特定的行为与可能存在于相同名字空间中的其他服务的行为区分开来,以及行为相对于为定义服务的特定名字空间定义的可能行为集。换句话说,行为是由该服务展现的分布式状态机。因此,通过包括那些资源或服务与其他服务的交互作用,行为增加用于识别资源的当前网络模型。两个服务需要具有兼容的行为以便通信,即,它们必须达成和解。如果服务的行为不由另一服务已知,这暗指两个服务不能交互作用,其类似于资源的网络模型,其中因为用于执行该操作的机制对那个URI的支持器是未知的,因此,URI不能被解除参考。
从WSAP服务视点看,任何数据,不管是元数据还是数据,均表示为服务。即,不是将相同的数据集合(诸如文件)展现为能读取或执行的单一实体,将文件展现为具有不同订约的不同服务。这在图3中示出,其通过展现为具有不同行为的服务集的传统的文件数据302,示例说明身份和行为的唯一性的概念,以及每个服务具有其自己的URI。也如图3所示,在对应于文件的行为的服务中,包括读取服务304、执行服务306、元数据操作服务308和用于读取该文件与其他服务310的关系的目录的服务。实质上,关于文件的任何其他行为(例如写入)也能是服务,以及在图3中隐含表示。
将文件展现为服务集,每个具有其自己的URI,与传统模型比这提供显著的好处,在传统模型中文件通过打开后返回的句柄,经文件***访问。例如,通过本发明,只要到介质服务的URI是已知的,经适当的服务,执行对文件的操作,消除继续通过文件***用文件数据执行一些操作的需要。这对分布式计算环境特别有利,其中例如,文件***可以在一些遥远的服务器上和/或可以是经本发明能避免的瓶颈。
WSAP的主要目的是提供应用层协议框架,它解决WSAP网络服务是什么以及如何识别它;WSAP网络服务的行为是什么和它如何与其他WSAP网络服务通信;以及WSAP网络服务一般如何与其他WSAP服务以及其他资源关联。由WSAP提供的框架,经消息操作和交换模式集,意图在身份和行为方面约束行为网络服务的概念,但它不在结构或复杂性方面约束它。WSAP网络服务能用在许多不同的应用环境中。例如,除如图3的例子中所示,作为服务的文件的概念外,身份和行为的唯一性的其他简明例子是可行的,诸如通过向设备的不同行为,或向简单聊天服务的不同行为分配端口。注意为了简单,在此的例子使用相对低级的实体和服务,然而,应理解到,该模型同样适合于更复杂的实体,诸如商业实体和它们的关系。
除服务身份和服务行为外,行为的网络服务具有服务状态,有时称为“服务价值”的概念。更具体地说,WSAP消息操作可以包含表示服务的部分或子部分的串行化状态的交换(而不是WSAP服务本身)。服务的串行化状态称为服务价值,与表示服务类型的行为相反。服务能具有由服务的行为允许的任何值,以及那一价值可以随时间改变。注意WSAP在服务上操作,以及采用表示服务的串行化状态的服务表示。服务可以具有零个或多个可能的表示,即,对服务来说,可以不具有任何表示。WSAP操作可以包含服务表示的交换,而不是服务本身的交换。服务表示可以随时间改变以及可以作为导致将生成的表示的条件的函数改变。应用通过表示的交换,而不是通过服务的交换交互作用。
图4示出服务价值403,其中,服务价值能是任何数据(例如文件的状态数据),诸如数据库数据、字母数字数据、房屋的图像或花的图像。从服务视点看,相同的服务值可以表示为具有不同交互方式的不同服务。如上所述,因为将不同行为模型化为分别的服务,影响诸如访问权限以及通信属性的行为的属性能产生不同服务。
在图4中,对相同服务价值的不同访问模型模型化为不同服务411-414,分别包括只读访问、读写访问、加密访问和谈判访问。注意相关服务间的同步能使用WSAP复制模型来执行,如下所述。
考虑图3和4,可以看出,文件***是包含多个数据的“视图”,即文件的实体的一个例子,包括元数据(诸如文件名、长度、所有者和存取许可)和数据(诸如文件内容)。另外,文件的视图由打开文件的实体的存取许可而定,以及实际上,只读文件的行为不同于读写文件的行为。同样地,文件***易于模型化为行为服务集。
只要经兼容订约连接服务,服务能通过生成和接受特定类型的消息序列,彼此交互。为此,WSAP用相关语义定义一起消息操作。每个消息操作包括能在两个通信方间交换的一组特定类型的消息。
根据本发明的另一方面,WSAP构建有关行为网络服务的定义,其中,根据消息操作和消息交换方的共享集,定义用于确定身份和行为的框架。由通常为应用程序的客户机代码202(图2),定义WSAP消息操作,其中操作包含使用由WSAP定义的一个消息交换模式的,交换特定类型的消息,如下面参考图5和6所述。也如下所述,端口通过通信提供同步,以及SOAP提供用于在服务间交换的消息的处理模型。
WSAP的目标是提供用于定义网络服务和它们的交互作用的公共应用层基础。注意将SOAP设计成支持多个应用模型,以及应用免于使用SOAP可扩展性模型的全部型谱。然而,WSAP的一个意图是定义通常用于各种分散应用的应用模型。WSAP的另一目标是允许高度互操作性,导致潜在增加整个***的有效性。
为实现这些目的和其他,WSAP基于一组公共消息操作,定义网络服务应用模型。注意,迄今还未知应用于网络服务的公共词汇的概念WSAP通过听起来熟悉的名称,诸如LOOKUP、QUERY、INSERT、UPDATE、DELETE、GET和DROP,定义操作的整个结构和语义,由此各个服务能由那些操作继承而来,同时保存对稍后捆绑的支持。通常,大写字母常常在此用于WSAP操作,以便将WSAP操作与传统的动词区分开来,但不要求操作使用大写字母,以及另外,其他或不同命名的WSAP操作集也是可行的,并且服务能根据需要定义它们自己的附加操作。
操作允许应用与其他服务通信。例如,LOOKUP以订约的形式,提供有关服务的信息,能使用GET和QUERY来检索服务的当前状态。CREATE和DROP操作能创建和删除服务等等,如下所述。大部分操作在特定类型的消息上是多形的,以致各个服务能使消息的结构适合于服务的形状。例如,由目录服务定义的INSERT请求消息的SOAP Body元素与由载入程序服务定义的INSERT请求消息不同,但它们遵循相同的基本语义。
WSAP消息操作能视为能组成为更复杂订约的小型订约。这允许应用将消息操作组合成适合于它们的特定需要的序列,因此,构建更复杂的服务。换句话说,能组成和/或排序WSAP操作本身以便定义用于服务的更复杂的行为。例如,服务可以定义为接受在UPDATE操作前的QUERY操作(QUERY和UPDATE操作描述如下)。注意,由此URI能表示WSAP操作序列,表示URI本身能表示单一行为或复杂的行为,尽管WSAP不要求,能使用订约来更有利于实现所需兼容性。
除网络的***中潜在的增值外,使用可能允许整个***的更高透明度的共享语义。因此,在整个***中,能配置诸如高速缓存和其他中介体处理服务的性能优化以便实现Internet广泛***所需的可缩放性。
更具体地说,WSAP操作具有允许中介体,诸如高速缓存服务、负载均衡器服务、数据压缩服务、复制服务、加密/解密服务等等处理消息的服务。限定WSAP操作的两个这种属性包括操作是否“安全”和/或“等幂”。当成功执行的结果与执行操作的次数无关时,操作是等幂的。如果其语义局限于只读访问施加到其上的资源,操作是安全的。注意,按定义,安全操作是等幂的,然而,逆过程不为真,由此只读操作是既安全且等幂。另外,这些限定公司应用于操作,而不是该操作的特定实现。
这些限定公司提供启动操作方和目标服务间的服务级期望。注意特定的安全或等幂操作实现可以具有与执行该操作有关的第二阶副作用。这种副作用的典型例子是登录、在动态内容的情况下,与生成只读数据有关的处理、状态管理更新等等。这种第二阶副作用不影响安全和等幂操作的概念。
因此,中介体服务能处理所交换的消息来增加通信价值。举例来说,考虑中介体,诸如高速缓存。在该例子中,客户机连接到提供数据存取的服务,并在响应中,客户机接收URI到高速缓存。为响应GET和/或QUERY请求,返回数据,超高速缓存不需要知道有关数据的内容的任何事,例如内部如何格式化、是否加密等等,但从请求操作类型知道处理消息将不改变高速缓存下,基础资源的状态。因此,高速缓存服务能安全地从其自己的高速缓冲存储器读取数据以满足任何GET和/或QUERY请求。如果接收到将改变状态的请求,例如WSAPINSERT、DELETEU或PDATE操作,高速缓存服务能将消息传递到适当的URI,或者,客户机能使用不同的URI来修改状态,在那样事件中,高速缓存服务将被通知其某个部分无效。
根据本发明的另一方面,WSAP操作基于两个消息交换模式,即单向和请求一响应,以及在最终响应到来之前,支持中介体响应。尽管WSAP消息潜在的能在允许多播的体系结构上传播,可能具有WSAP消息时,WSAP消息操作的语义是点对点通信。注意,WSAP以形式化方式,描述网络服务的行为,这是WSAP和其他协议的主要区别。
图5和6分别表示使用单向和请求-响应消息交换模式的WSAP操作。在任一情况下,发送者和接收者均命名WSAP服务(即,经URL)。注意这不同于客户机/服务器协议,诸如HTTP,其中,仅命名请求的目标资源。
在图5中表示单向消息交换模式,并包括通过零个或多个中介体,从初始发送者发送到最终接收者的消息。注意如果单向消息导致生成SOAP故障(如下所述),不将SOAP故障消息返回到初始发送者。
请求-响应消息交换模式如图6所示,并包括在通过零个或多个中介体,从初始发送者向最终接收者发送请求消息,然后是也通过零个或多个中介体从最终接收者发送到初始发送者的一个或多个中间响应。注意,没有对该消息交换模式强加时间约束,以及支持该消息交换模式的操作能用在同步和异步通信模型中。另外,注意如果请求消息导致生成SOAP故障,如下所述,将SOAP Fault消息返回到初始发送者,然而,如果响应消息导致生成SOAP故障,生成SOAP故障,但不将SOAP故障发送到响应者。
根据本发明的一方面,WSAP操作包括具有如SOAP Body内容的消息类型、这些消息类型的行为以及通过调用操作隐含的语义的集合。对SOAP消息,WSAP消息类型能由可扩展数且的SOAP特征,(通常表示为SOAP首部块)组成。这些特性的例子包括但不限于安全性、路由和可靠性。
下述C#类(用在如IRP数据结构的一些情形中)表示一个实现中的SOAP包:
msgSoapEnvelope
{
IPortCollection portHeader;
IPort portBody;
}
处理SOAP包包括消息生成、消息交换和消息解析。由SOAP处理组中的中介体使用PortHeader端口来交换能串行化或严格的内部首部结构。第二端口PortBody存储消息体。使用该容器内的端口允许SOAP包的同时和线程安全的操作。不要求严格的流水线模型或基于堆栈的模型(通常具有处理SOAP首部块和/或SOAP体间的交互作用的问题)。
SOAP处理模型的基于WSAP实现的好处在于它匹配用于在同时处理一个SOAP消息的SOAP中的内在支持。经对应于行为的端口,实现便于通过几个服务,同时处理消息。例如,感知SOAP的串行化器可以与其他服务操作同时地串行化或并行化指定SOAP消息的首部和主体。这允许依赖于SOAP包的部分的服务只要服务关心的头部可用,解开块。由于该并行解析设计,SOAP并行化本身不是原子的。为更好性能,转发和传输服务永远串行化SOAP包,只要两个通信方定位一起。
由于使用SOAP,使用SOAP故障结构,使用请求-响应MPE报告在执行WSAP操作的任何一个中的故障,以及由WSAP应用生成的SOAP故障需要包括其值反映带有S:Envelope/S:Body/S:Fault/S:Code/S:Value的值的SOAP故障的SOAPAction元素信息项。通常,每个故障有单独的动作。
根据本发明的一方面,能识别WSAP消息类型。不关心SOAP Body的特定类型,或不能看见SOAP Body的内容(例如如果已经加密过)的中介体和其他SOAP节点能使用SOAP Action元素信息项,例如,由WS-Addressing所具有的。WSAP操作定义唯一Action值。
不关心SOAP Body的特定类型的SOAP节点能使用SOAP Body的最外元素信息项的XML扩展名的类型。WSAP定义需要替换由应用定义的消息类型的抽象元素信息项集。
对SOAP故障,模型是类似的,但使用SOAP故障码提供增加的检查能力级,因为不关心SOAP故障的细节的中介体和其他SOAP能检查SOAP故障码。
除如上所述的操作外,展现状态允许能一致地应用于所有服务的更少传统操作,诸如高速缓存和复制以及统一公开/预约(公开/预约)模型。能使用此来构建能测试、监视和管理在分布式操作***节点和节点之间的服务的一般应用。
也能将会话模拟为WSAP中的服务,其中会话管理是指在根据呼叫者的值状态之间作出区分。作为会话管理的一个例子,HTTP Cookie通常用来根据独立HTTP操作上的用户,个性化网页。然而,Cookie的问题在于服务的状态以及可能的行为由Cookie的值而定,它与行为网络服务模型不一致。然而,因为WSAP将会话模拟为另一服务,而不是使用会话标识符或Cookie来识别会话,会话是具有状态和行为的服务,正如创建、操作和终止的任何其他服务。
除如上所述的服务交互作用外,服务能以不包含WSAP消息的实际交换的方式,彼此关联。这种关系的例子包括(但不限于)将服务集描述为属于相同安全组的安全性政策,以及描述特定方如何管理服务集的管理语句。在这种示例性的情况中,描述指一组服务,但描述不包含所涉及的服务间的任何实际的通信。然而,捕捉关系仍然很重要,即使未交换显式WSAP消息。
可以将这些关系模拟为行为类型以及将它们描述为订约的一部分。这些订约称为“图订约”,以便将这些关系订约与WSAP消息订约区分开来。使用与其他订约相同的描述语言,描述图订约。
转到共享语义的说明,通常,由其他服务创建服务。更具体地说,能使用CREATE操作创建服务,它通过拷贝现有的服务创建新服务。为此,新创建的服务具有创建服务的服务行为和服务价值,即接受CREATE操作的服务充当用于新创建的服务的价值的模板。CREATE请求可以包含用来初始化新创建的服务的另外的状态。这允许通过其他不变状态初始化服务。CREATE请求可以包含根据服务的形状,修改新创建的服务的拷贝状态的状态。将所提出的终点命名为CREATE请求的部分或使创建服务提供名称是可行的。注意继承服务可以展现为网络服务,而不直接创建为网络服务。
在WSAP中,支持CREATE操作的服务能创建特定行为的服务。任何服务可以支持CREATE操作,由此可以支持根据需要,创建许多行为。因为WSAP操作与显式服务关联,CREATE服务是用于创建新服务的目标服务的请求。CREATE本身不创建目标服务。
图7表示CREATE操作如何能导致创建一个或多个相关服务。在简单的服务创建中,CREATE操作在显式初始化之前的创建序列,创建单个服务。在图7中,客户机702通过处理这些操作的服务710,启动CREATE操作。一般而言,关于网络服务,CREATE请求包含用于将创建的服务类型的订约。创建服务包括为服务分配URI以及将该服务与指定行为关联。在已经创建服务后,另外的消息操作可以包含根据服务的结构改变服务值,和/或通过关系、存取控制或其他机制,将新服务与其他服务关联。
响应包含即时订约,它包含新创建的服务720的URI。在已经创建服务后,根据其行为和如果适当的话,与其他服务的关系操作。例如,服务能通过操作处理这些政策的服务,与安全性政策关联。
下述表阐明用于WSAP CREATE操作的属性:
用于CREATE的属性表 |
属性 |
值 |
MEP |
请求-响应 |
请求动作 |
http://abc/def/ghij/10/wsap/createrequest |
响应动作 |
http://abc/def/ghij/10/wsap/createrequest |
安全 |
否 |
等幂 |
否 |
下述数据结构包含样本CREAT操作的SOAP Body内容。该请求由服务定义,响应使用为空响应而定义的方便的类型:
<M:MyServiceCreateRequest xmlns:M=“http://www.example.org/myservice”><M:MyServiceInfo><M:Status>ok</M:Status><M:MaxEntries>100</M:MaxEntries></M:MyServiceInfo></M:MyServiceCreateRequest><W:DefaultCreateResponse xmlns:W=“http://abc/def/ghij/10/wsap.xsd”/> |
在更复杂的服务创建中,CREATE操作创建一组相关服务。例如,如果创建服务知道以它们总是一起存在的方式关联服务集,会出现复杂的服务创建。图8是示例说明两个服务的创建的序列图。在图8中,如在简单的服务创建情况下,客户机802通过处理这些操作的服务810(创建服务A)启动CREATE操作。操作请求包含用于将创建的服务类型的订约。创建服务A服务810相对于创建服务B(在图8中标记812),启动另一CREATE操作以便创建另一新服务824,服务B。
在已经创建服务A和服务B(822和824)后,创建服务B服务812向创建服务A服务810发送创建响应,810又向客户机802发送创建响应。由创建服务A服务810发送的创建响应包含即时订约,它包含两个新创建的服务822和824的URIs。注意在复杂的服务创建中,WSAP不提供固有保证,即在事务环境内创建服务。这些保证能通过增加具有事务支持的服务的行为来提供。
如上所述,WSAP服务的行为描述为订约。订约通常被串行化为XML文档,尽管不要求。订约本身是服务,同样地,订约由URI识别以及能根据其订约操作,正如任何其他服务那样。
服务可以具有另一服务的URI,但不是其订约,这是两个服务通信所需要的。为获得订约,WSAP协议要求每个服务支持允许服务向另一服务请求订约,从而确定服务的行为的LOOKUP操作:
用于LOOKUP的属性表 |
属性 |
值 |
MEP |
请求-响应 |
请求动作 |
http://abc/def/ghij/10/wsap/lookuprequest |
响应动作 |
http://abc/def/ghij/10/wsap/lookuprequest |
安全 |
否 |
等幂 |
否 |
下文表示样本LOOKUP操作的SOAP Body内容。由WSAP定义请求和响应:
<W:LookupRequest xmlns:W=″http://abc/def/ghij/10/wsap.xsd″/><W:LookupResponse xmlns:M=″http://abc/def/ghij/10/wsap.xsd″><W:Contract>http://www.example.org/myservice</W:Contract><W:BindingList>http://www.example.org/mybl</W:BindingList></W:LookupResponse> |
图9表示示例说明客户机902和服务920间的LOOKUP操作的样本序列。查找响应包含订约的URI,如上所述,它也是服务,尽管返回订约本身也是可行的。
因此,在一个实现中,LOOKUP将URI返回到包含订约/协议的串行化的文档。订约不仅定义消息的顺序,而且定义由在其上交换消息的具有URIS的端口所表示的交互作用点。另外,使用那个文档加上为关键字/值对的数组的BindingList来“例示”订约文档。这允许在运行时,由真值替换一般名称,以及允许在运行时,确定服务的实例间的关系,提供服务的实例间的反映能力。订约/捆绑列表从而允许管理分布式设定值中的依赖性,同时,在启动时,指定所需服务。
对服务状态检索,WSAP协议定义两个操作,名为GET和QUERY。尽管两个操作是安全和等幂的,GET和QUERY操作间的差别在于如下所述,QUERY请求包含结构化查询,而GET请求是用于服务的当前状态的快照的与应用无关的请求。因此,QUERY请求要求有关正查询的服务的特定的模式知识,而GET请求不需要。这种区别的结果在于QUERY请求包含不为服务的名称(结构化查询)的一部分的参数,而GET请求提供将服务识别为服务的名称的一部分的参数。
通过支持QUERY和GET,WSAP支持结构化标识符以及隐性标识符,以及允许这些解决方案间的映象。这是因为根据它们的用途的环境,对任何一个都有利。更具体地说,在命名服务中,在使用结构化名称,诸如查询和语义隐性名称,诸如URIs间存在紧张关系。例如,考虑识别为能提供人名的结构化表示的“http://example.com/people”的示例***。至少用三种不同方式,引用特定人,即作为结构化查询、作为在URI查询构件中编码的非结构化查询,或作为URI路径构件的一部分的隐性标识符。针对服务发出的结构化查询需要有关服务的结构的知识以便引用任何特定人,如在相对于示例***“http://example.com/people”发出的结构化查询的下述例子中所示。
<Query><Name><First>Santa</First><Last>Claus</Last></Name></Query> |
相反,作为URI查询构件的非隐性部分编码的非结构化查询通常使用URIHTML形式编码。该模型要求有关名称-值对的集合的知识,但不要求有关特定服务的结构化知识,以便组成编码这些名称-值对的URI。下述例子表示在URI查询构件中,编码为名称-值对的非结构化查询:
http://example.com/people?first=santa&last=claus |
作为URI路径构件的一部分的隐性标识符不透露,实际解可以不包含查询。客户机需要了解的唯一的事情是如何解析标识符,在这种情况下,通过使用HTTP。下述例子表示那种隐性标识符,它不表示查询的任何部分。
http://example.com/people/12345678 |
查询解决方案的好处在于能完全分类型查询参数。然而,结果是结构化查询变成用于该人的标识符的一部分。这表示想打听那个人的任何实体需要使用和理解特定的结构化名称。识别其他事物的结构化名称将具有也要求特定知识以便使用的不同的形状。在一些情况下,这工作良好,特别是当用户期望在该数据上操作时。然而,因为需要特定的知识,可缩放性会快速变成问题,因为难以配置在具有有关名称的那个特定形状的特定知识的组之外的名称的概念。
标识符间的另一重要差别是存在的数据隐藏的级。更具体地说,查询解决方案要求查询的结构的知识,而非结构化编码查询和隐性解决方案逐渐提供更少信息。如果存在能变成公开的某些关键字,特别是如果有助于降低必须映射的URIs的数量,能使用非结构化编码查询。这些应用的典型例子是公众搜索引擎,诸如Google(tm)(“http://www.***.com/search?h1=en&ie=UTF-8&oe=UTF-8&q=msft”)以及典型的股票指数服务(“http://moneycentral.msn.com/scripts/webquote.dll?iPage=qd&Symbol=msft”)。
非结构化编码查询解决方案是今天Web上最通用类型的标识符,但非常难以编码URI中的结构化数据。此外,编码成URI的一部分的数据对体系结构来说本来是公开的,使得它更难以处理用于作为标识符的一部分的任何数据的与安全性有关的问题。隐性标识符解决方案不支持查询界面,除非存在用于将查询映射到那个标识符的模型。如果查询的结构仅对服务的一部分***知道(例如,由于隐私或其他原因),这能通过使用非结构化编码查询方案或隐性标识符方案,不展现或展现结构化数据的受限部分来完成。
因此,能使用GET操作来检索服务的串行化值状态,并具有下述属性:
用于GET的属性表 |
属性 |
值 |
MEP |
请求-响应 |
请求动作 |
http://abc/def/ghij/10/wsap/getrequest |
响应动作 |
http://abc/def/ghij/10/wsap/getrequest |
安全 |
是 |
等幂 |
是 |
下述表包含样本GET操作的SOAP Body内容。由WSAP定义请求,由服务定义响应:
<W:GetRequest xmlns:M=″http://abc/def/ghii/10/wsap.xsd″/><M:MyServiceGetResponse xmlns:M=″http://www.example.org/myservice″><M:MyServiceEntries><M:Entry>http://www.example.com/first/endpoint</M:Entry><M:Entry>http://www.example.com/second/endpoint</M:Entry><M:Entry>http://www.example.com/third/endpoint</M:Entry><M:Entry>http://www.example.com/fourth/endpoint</M:Entry></M:MyS erviceEntries></M:MyServiceGetResponse> |
在一些情况下,QUERY请求能映射到GET操作,例如,这种映射有效地为特定查询提供标识符。例如,当在许多不同环境中,出现相同查询时,或当需要URI引用以便引入高速缓存时,这提供有利方面。图10表示示例说明从QUERY映射到GET的样本序列。QUERY响应包含用于能针对A提供与QUERY相同的结果的服务B的URI。注意能通过任何服务进行映射,并不必与针对以QUERY为目标的服务有关。
因此,也能使用QUERY操作来查询服务的串行化值状态,并具有下述属性:
用于QUERY的属性表 |
属性 |
值 |
MEP |
请求-响应 |
请求动作 |
http://abc/def/ghij/10/wsap/queryrequest |
响应动作 |
http://abc/def/ghij/10/wsap/queryrequest |
安全 |
是 |
等幂 |
是 |
下述表包含样本QUERY操作的SOAP Body内容。请求和响应均由服务定义:
<M:MyServiceQueryRequest xmlns:M=″http://www.example.org/myservice″><M:Entry>http://www.example.com/eight/endpoint</M:Entry></M:MyServiceQueryRequest><M:MyServiceQueryResponse xmlns:M=″http://www.example.org/myservice″><M:MyServiceEntries/></M:MyServiceQueryResponse> |
注意,因为GET和QUERY操作是安全且等幂的,并且已知具有通过共享语义的可观察属性,各种中介体能提供消息交换的值。例如,高速缓存服务知道QUERY或GET请求不改变状态。因此,高速缓存能响应这些请求,无限地继续提供状态数据,除非以及直到检测到改变状态的操作为止。
除状态检索外,WSAP允许使用INSERT、UPDATE和DELETE操作更新服务的状态。这些操作仅适用于服务的值,它们不创建或终止服务。
由服务将WSAP服务的数据结构定义为其行为的函数。因此,INSERT、UPDATE和DELETE操作要求请求者具有有关其结构的知识以便影响服务的值,与QUERY类似。因此,抽象地定义INSERT、UPDATE和DELETE操作以便它们能适合于各个服务。
当使用INSERT操作修改服务值时,包括在INSERT请求中的值增加到服务值上。假定隔离观察服务,通过查看在INSERT操作前发出的GET操作和在INSERT操作后发出的GET操作间的差别,检测INSERT操作的结果,通常如图11的消息序列图中所示。在图11中,在***操作前,客户机1102从服务1120接收状态数据,以及在***操作后的下一请求之后,接收更新的状态数据。
能使用INSERT操作来将串行化值状态增加到服务上,如通过下述属性所述:
用于INSERT的属性表 |
属性 |
值 |
MEP |
请求-响应 |
响应动作 |
http://abc/def/ghij/10/wsap/insertrequest |
请求动作 |
http://abc/def/ghij/10/wsap/insertrequest |
安全 |
否 |
等幂 |
否 |
下述表包含样本INSERT操作的SOAP Body内容。由WSAP定义请求,由服务定义响应。例子不表示将***数据的任何排序,然而,应用可以定义它们的模式来适应排序约束:
<M:MyServiceInsertRequest xmlns:M=″http://www.example.org/myservice″><M:MyServiceEntries><M:Entry>http://www.example.com/fifth/endpoint</M:Entry><M:Entry>http://www.example.com/sixth/endpoint</M:Entry></M:MyServiceEntries></M:MyServiceInsertRequest><W:DefaultInsertResponse xmlns:M=″http://abc/def/ghij/10/wsap.xsd″/> |
通过那一服务定义服务的结构,而WSAP不要求以任何方式***该值。作为其结构的一部分,服务可以允许INSERT、UPDATE和DELETE操作来识别将执行操作的特定位置,例如,使用XPath表示。
关于INSERT,当使用DELETE操作修改服务值时,应用相同的一般观察特性,其中,删除在DELETE请求中识别的服务值的部分。假定正隔离观察服务,通过查看在DELETE操作前发出的GET操作和在DELETE操作后发出的GET操作间的差别,能检测DELETE操作的结果,如一般在图12中所示。
下述表表示用于DELETE操作的属性:
属性 |
值 |
MEP |
请求-响应 |
请求动作 |
http://abc/def/ghij/10/wsap/deleterequest |
响应动作 |
http://abc/def/ghij/10/wsap/deleterequest |
安全 |
否 |
等幂 |
否 |
通过服务定义DELETE请求,响应使用为空响应而定义的方便的类型:
<M:MyServiceDeleteRequest xmlns:M=“http://www.example.org/myservice”><M:MyServiceEntries><M:Entry>http://www.example.com/some/endpoint</M:Entry><M:Entry>http://www.example.com/another/endpoint</M:Entry></M:MyServiceEntries></M:MyServiceDeleteRequest><W:DefaultDeleteResponse xmlns:W=“http://abc/def/ghij/10/wsap.xsd”/> |
当使用UPDATE操作,修改服务值时,用包括UPDATE请求中的值,替换在UPDATE请求中识别的服务值部分。注意如果在事务上下文中看UPDATE操作与在INSERT前的DELETE类似。即,仅当如通过UPDATE操作所述那样,成功地修改现有的服务,UPDATE才成功。关于INSERT和DELETE,通过查看在UPDATEA操作后发出的GET操作和在UPDATE操作后发出的GET操作间的差别,能隔离地检测UPDATE操作的结果,如通常在图13中所示。
使用UPDATE操作来更新现有的值状态,以及具有下述属性:
用于UPDATE的属性表 |
属性 |
值 |
MEP |
请求-响应 |
请求动作 |
http://abc/def/ghij/10/wsap/updaterequest |
响应动作 |
http://abc/def/ghij/10/wsap/updaterequest |
安全 |
否 |
等幂 |
否 |
下述表包含样本UPDATE操作的SOAP Body内容。通过WSAP定义请求和响应动词,关于请求,SOAP包的主体包含服务定义的响应元素。
在该例子中,响应是为空响应而定义的方便的类型。WSAP不规定那样的机制,通过该机制,识别现有状态,相反,留下直到该应用。下述表描述UPDATE请求和响应的示例性内容:
<M:MyServiceUpdateRequest xmlns:M=″http://www.example.org/myservice″><M:Replace>http://www.example.com/first/endpoint</M:Replace><M:With>http://www.example.com/eight/endpoint</M:With></M:MyServiceUpdateRequest><W:DefaultUpdateResponse xmlns:W=″http://abc/def/ghij/10/wsap.xsd″/> |
方便WSAP的另一操作包含复制,它提供保持在分布式服务上同步的状态的清楚、透明方式。为此,WSAP提供允许服务与另一服务同步的复制模型。为使两个服务的状态保持同步,复制服务与在被复制服务上执行的复制服务上相同的一个或多个操作。
通常,REPLICATE、SUBSCRIBE、CANCELREPLICATE和UNSUBSCRIBE操作用户列表的状态。由于WSAP展现状态,用户列表可以保持在另一WSAP服务(例如SubscribeHelper)中。在接收SUBSCRIBE、REPLICATE、CANCELREPLICATE和UNSUBSCRIBE请求之后,如果适当的话,主WSAP服务发送Insert/Delete请求。在主服务上的LOOKUP响应中,在捆绑中,识别允许第三方捕捉服务的整个状态的助手。如果用URI表示,包括用户列表的该整个状态,是可见的。注意通过分开有关它们自己的状态的预约,第三方可以通知服务的用户走开以及用不同URI再现。
通常如图14所示,如果在复制服务1430上执行INSERT操作,基于来自用户1450的先前的REPLICATE请求,复制服务1430将在复制服务1440上执行INSERT操作。注意WSAP复制模型的语义不同WSAP通知模型(如下所述),它不要服务在接收NOTIFY消息上执行任何操作。
能使用REPLICATE操作来复制服务或部分服务。复制的行为由包括在请求中的订约来描述。下述表阐述用于REPLICATE操作的属性:
用于REPLICATE的属性表 |
属性 |
值 |
MEP |
请求-响应 |
请求动作 |
http://abc/def/ghij/10/wsap/replicaterequest |
响应动作 |
http://abc/def/ghij/10/wsap/replicaterequest |
安全 |
否 |
等幂 |
是 |
所阐述的下述表包含样本REPLICATE操作的SOAP Body内容。由WSAP定义请求,由服务定义响应。在该例子中,响应是为空响应而定义的方便类型:
<W:ReplicateRequest xmlns:W=″http://abc/def/ghij/10/wsap.xsd″><W:Contact>http://www.example.com/contracts/fullreplication</W:Contract></M:ReplicateRequest><W:DefaultReplicateResponse xmlns:W=″http://abc/def/ghij/10/wsap.xsd″/> |
通过发出REPLICATE操作启动复制,该操作包含描述拟使用的复制模型的订约。例如,复制服务可以通过INSERT操作,支持仅复制状态添加的复制模型。如果如在该例子中,在INSERT操作中,仅感兴趣复制服务,这可以通过引用REPLICATE操作中的复制订约来表示。如果接受REPLICATE请求,那么复制服务将其当前的状态作为针对复制服务的一组INSERT操作传送。
注意如在图14中,预订服务1450可以不同于复制服务1440。另外,复制服务可以已经存在以及具有某一状态。根据复制订约,当复制开始时,该状态可以或可以不被覆盖。在复制订约仅允许INSERT操作的上述例子中,因此,复制状态将添加到复制服务的现有状态。
复制订约在某些情况下,可以通过本身终止,复制可以受截止日期限制,或它可以继续无限地复制该状态。在一种实现中,届满可以视为订约的一部分,然而,它可以另外被提供为值参数。
使用CANCELREPLICATION操作,也可以明白地终止复制。用于CANCELREPLICATION操作的样本序列图在图5示出。如能看出,在复制服务1530处接收来自客户机1502的初始***请求并复制到复制服务1540。如果非用户(unsubscriber)服务1552请求CANCELREPLICATION操作,明确地终止所建立的复制。在图15的例子中,复制服务1530不将来自客户机1502的另外的***请求复制到复制服务1540。
用于CANCELREPLICATION的属性表 |
属性 |
值 |
MEP |
请求-响应 |
请求动作 |
http://abc/def/ghij/10/wsap/cancelreplicaterequest |
响应动作 |
http://abc/def/ghij/10/wsap/cancelreplicaterequest |
安全 |
否 |
等幂 |
否 |
下述表包含样本CANCELREPLICATION操作的SOAP Body内容。响应使用为空响应而定义的方便类型。
<W:CancelReplicateRequest xmlns:W=″http://abc/def/ghij/10/wsap.xsd″/><W:DefaultCancelReplicateResponsexmlns:W=″http://abc/def/ghij/10/wsap.xsd″/> |
除复制模型外,WSAP定义基于NOTIFY操作的简单的事件通知模型,它报告状态改变已经发生,但不揭示状态改变发生的环境。注意事件通知模型的语义不同于复制模型,其中,复制服务作为从复制服务发送的消息的结果,改变状态。在通知模型中,在接收NOTIFY消息后,不要求用户执行任何操作。因此,用户所执行的任何动作仅基于其自己的语义,而不是事件通知源的语义。注意预订NOTIFY操作,因此可以是过期的,其可以是经值参数设置的订约的一部分。
NOTIFY操作是WSAP通知模型的一部分,能用来发出事件通知,以及具有下述属性:
用于NOTIFY的属性表 |
属性 |
值 |
MEP |
单向 |
请求动作 |
http://abc/def/ghij/10/wsap/notify |
下述表包含样本NOTIFY操作的SOAP Body内容:
<M:MyNotification xmlns:M=″http://www.example.org/myservice″><M:CurrentEntries>6</M:CurrentEntries></M:MyNotification> |
图16表示与NOTIFY有关的SUBSCRIBE操作,其中,用户1650向事件源1670发出请求。请求包括识别在查看状态变化中用户感兴趣的事件通知源的部分的查询。如果接受SUBSCRIBE操作,事件通知源1670启动表示源的当前状态的NOTIFY操作。在该初始化NOTIFY操作后,只要事件通知源的状态适当地改变事件通知源发出新NOTIFY操作。因为描述事件通知源的行为的订约与应用语义无关,其完全由WSAP定义。
由此使用SUBSCRIBE操作来订约服务的状态的变化,以及具有下述属性:
用于SUBSCRIBE的属性表 |
属性 |
值 |
MEP |
请求-响应 |
请求动作 |
http://abc/def/ghij/10/wsap/subscriberequest |
响应动作 |
http://abc/def/ghij/10/wsap/subscriberequest |
安全 |
否 |
等幂 |
否 |
下述表包含样本SUBSCRIBE操作的SOAP Body内容。由WSAP定义请求,以及由服务定义响应。在该例子中,响应是为空响应而定义的方便类型:
<M:MyServiceCurrentEntriesSubscribeRequestxmlns:M=″http://www.example.org/myservice″/><W:DefaultSubscribeResponsexmlns:W=″http://magnet/contracts/2003/10/wsap.xsd″/> |
通过截止时间可以限制预定,这与复制模型类似。类似地,使用UNSUBSCRIBE操作,可以在任何时间终止预约,如图17所示,其中非用户1752将UNSUBSCRIBE操作发送到事件源以便取消另外的通知。
取消预约的UNSUBSCRIBE操作具有下述属性:
用于UNSUBSCRIBE的属性表 |
属性 |
值 |
MEP |
请求-响应 |
请求动作 |
http://abc/def/ghij/10/wsap/unsubscriberequest |
响应动作 |
http://abc/def/ghij/10/wsap/unsubscriberequest |
安全 |
否 |
等幂 |
否 |
下述表包含样本UNSUBSCRIBE操作的SOAP Body内容。由WSAP定义请求,由服务定义响应,在该例子中,响应是为空响应而定义的方便类型。
<W:UnsubscribeRequest xmlns:W=″http://magnet/contracts/2003/10/wsap.xsd″/><W:DefaultUnsubscribeResponsexmlns:W=″http://magnet/contracts/2003/10/wsap.xsd″/> |
注意,WSAP事件通知模型是传统的进栈模型,其中事件通知从源压入收汇处。然而,通过在消息路径中使用缓冲中介体,可以将进栈模型转换成出栈模型,其提供用于事件通知收信方的离线支持。
转到服务终止的描述,当终止WSAP服务时,不再能发送或接收任何类型的消息。服务可以通过将服务的行为描述成服务能发送或接收的有限消息集来终止。当服务覆行其订约时,它终止,并能恢复它所消耗的任何资源。
另外,服务的行为可以定义迫使服务终止的显式交互作用。为此,WSAP定义DROP操作,由此,可以显式地终止将DROP接受为其订约的一部分的服务。如图18所示,在从服务,诸如客户机1802接收DROP操作后,目标的服务1820简单地停止发送或接收任何未来的消息。与CREATE操作类似,DROP能简单的,如图18;或复杂的,如参考图20所示。
DROP操作具有下述属性:
用于DROP的属性表 |
属性 |
值 |
MEP |
请求-响应 |
请求动作 |
http://abc/def/ghij/10/wsap/droprequest |
响应动作 |
http://abc/def/ghij/10/wsap/droprequest |
安全 |
否 |
等幂 |
否 |
下述表包含样本DROP操作的SOAP Body内容。由WSAP定义请求,响应使用为空响应而定义的方便类型:
<W:DropRequest xmlns:M=″http://magnet/contracts/2003/10/wsap.xsd″/><W:DefaultDropResponse xmlns:W=″http://magnet/contracts/2003/10/wsap.xsd″/> |
注意,服务的行为允许发送或接收无限量的消息,以及不允许能终止它的显式操作是可行的,在任一事件中,不能以适度的方式终止服务。另外,注意在所述的WSAP操作数和已经过时钟时间的服务的寿命间,没有内在关系。建议(但不要求)在终止服务后,不再循环使用服务标识符,以避免过时引用被应用于相同名称的新服务的旧服务。
在一些情况下,目标服务可以执行一些另外的清除,诸如未从目标服务登记或发送出最终事件通知。这些清除在结束DROP操作前执行,如由图19中的DELETE请求和NOTIFY操作所示。
在复杂的服务终止中,如图20所示,根据设定值,终止多个相关服务。如果服务间的关系是使得它们不能单独地存在,会发生这种情况。在复杂的服务终止的情况下,WSAP不提供固有地保证,在事务环境中终止所有服务。这种保证能通过增加具有事务支持的服务的行为来提供。
从上述命令能看出,WSAP允许服务重启和动态地负载平衡,因为它允许捕捉和重新创建不同站点的状态。这能用来实现事务、负载平衡和/或当前版本更新以保持可用时间最大。举例来说,考虑具有URI A类型T的服务。经WSAP命令,另一服务能从A(例如经GET请求)获得数据,查看A(例如经LOOKUP请求)以获得其依赖性,以及Drop A。然后,通过创建具有URI B的类型T的服务,以及在B上执行替换(例如DELETE和INSERT),结果是从丢弃A复制的完全相同的状态行为。
如能从上述详细描述看出,提供一种方法和***以及机制,通过这些客户机(服务)和其他网络服务能以有效和安全,而且可观察和重使用的方式与网络服务通信,包括组成服务的实体,以便中介体可以将值增加到通信上。由此,方法和***提供当前计算所需的显著的优点以及好处。
尽管本发明能进行各种改进和替代的结构,某些所示的实施例在图中示出并且如上详细地描述。然而,应理解到不打算将本发明限制到所公开的特定的形式,而相反,本发明意图覆盖落在本发明的精神和范围内的所有改进、替代结构和等效。