在分布式网络体系结构中建模和动态部署服务的系统和方法

技术领域

本发明涉及分布式网络体系结构的领域，更具体地说，涉及一种用于在分布式网络体系结构，特别是在作为面向服务的体系结构的一部分的服务容器中，建模和动态部署服务的系统和方法，其中，所述面向服务的体系结构由以下部分构成：资源提供者、服务消费者、和向服务消费者提供服务的服务容器(即，主机环境)。

背景技术

当今IT环境的形成是由于需要提供在各种系统和应用之间的互操作性的手段。大多数所述系统和应用潜在地保持状态信息。由于系统和应用的状态化(stateful)特性，可将系统和应用等看作资源。为了提供对这种资源的状态的同种(homogeneous)访问，在面向服务的体系结构资源中，可通过与单独的资源的状态有关的功能接口将它们的状态分别暴露为服务(例如，Web服务)。

如果通过将资源的状态和功能性暴露为服务(即，通过功能接口)来提供对任意资源(即，物理或逻辑系统或应用)的访问，则必须使用任意编程语言(例如，Java，Net等)来开发封装各个资源的服务接口和实现(例如，Web服务、网格服务、CORBA等)。

当今随着新服务的开发和部署所遇到的问题在于现有技术应用开发和部署的静态特性。当前的开发和部署处理非常刚性，不允许在运行时期间修改现有的服务。如果要开发新的服务或者要修改现有的服务，则整个应用生存周期不得不重新开始，并且必须将新的特征添加到应用的源代码中，随后该源代码通常必须被编译、进一步描述、封装并传送到目标主机环境中，目标主机环境随后提供服务的功能性以供使用(取决于使用的编程语言或方法，在可使用服务之前可能要执行更多步骤。以下将更详细描述。)此外，如果将现有的服务组合为较高层的复合服务，则开发者必须提供组合两个现有服务的功能性的代码。总是在建立时期间(应用或服务没有激活或执行)，而不是在运行时期间来完成所述开发和组合现有的服务。

现有技术

为了更详细地解释当前如何在主机环境中开发并部署新的服务，图1示出在J2EE(即，Java 2企业版平台)的情况下如何完成开发和部署的示意性表示的示例。所示内容在建立时(以静态方式开发应用或服务)和运行时(完成的服务在主机环境中可用并可由服务消费者访问)之间进行区分。如果将开发和部署新的服务，则服务或应用开发者必须执行多个预定的活动。首先，必须开发服务(这包括服务的功能接口的规定以及服务逻辑的功能实现)。其次，必须将完成的服务编译为Java字节码。然后，必须通过以所谓的部署描述符的格式添加附加的信息来进一步描述新的代码，所述部署描述符规定应用服务的附加行为特性(例如，事务行为或安全设置)。在用一个或许多部署描述符描述了代码之后，必须将描述符和代码封装在一起，成为例如.jar或.ear文件(表示J2EE可执行)。接着，必须将所述可执行内容传送到将来的主机环境内的预定位置(这通常通过例如FTP的各种文件传送来完成)。下面，开发者或部署者将必须创建需要的数据库表，并将应用的状态化部分映射到各个表。最后，可使用各种方式将可执行内容安装到主机环境(将其装入目录并重新启动服务器，或调用安装客户机或管理接口)。通常，这意味着将必须停止主机环境(即，J2EE应用服务器)，必须安装可执行内容，并且必须随后重新启动服务器。只有在成功重新启动之后，才最终可由服务消费者使用新的服务(即，可创建新的状态化服务实例，并可调用对于这些实例的操作)。顺便说明，所描述的静态处理不仅对状态化服务有效，而且对普通的服务和应用开发及部署也是有效的。

如果将几个服务组合为较高层的复合服务，则必须以与单个服务完全相同的方式来开发新的复合服务。对于每个新的服务，需要所有的开发步骤(在建立时期间)，这同样使得现有服务的组合非常刚性和难以处理。

现有技术方法的问题如下：静态开发和部署处理使得动态服务开发以及将现有服务复合为更加复杂的复合服务非常刚性和难以处理。此外，不能在运行时期间动态配置服务(即，它们之后的应用实现)(例如，不能在运行时期间调整事务行为或安全特征，但是需要在建立时期间完成所述调整，并且需要随后重新配置所述服务)。同样地，对于服务的各种修改强制重新开发已修改的代码。此外，如果将任何种类的资源表示为服务，则它们需要实现另外的协议层，以便将它们的状态信息和功能性暴露到面向服务的领域。

发明目的

本发明的目的是提供一种用于在网络体系结构中开发和部署服务的系统和方法，其避免现有技术的缺点。

发明内容

本发明描述一种用于在分布式网络体系结构、特别是在面向服务的体系结构内建模和动态部署服务的新的系统和方法。作为分布式网络体系结构的一部分的服务容器暴露它的功能性作为服务。它提供用于部署服务描述的注册服务。在以任何声明性描述语言(即，(状态化)服务，例如，状态化Web服务的描述)创建新的服务描述之后，描述提供者在服务容器调用注册服务，所述服务容器允许在运行时期间注册(即，部署)所述新的服务描述，而不需要重新启动服务容器。服务容器负责分析并检查提交的新的服务描述的有效性，存储所述服务描述，并使得它对于感兴趣的服务消费者可用，以进行实例化。如果新的服务已成功注册，则由服务容器自动创建用于访问所述新服务的新的服务接口。感兴趣的服务消费者可以就被主机管理的可用服务查询主机环境，并随后实例化一个新的服务。服务消费者随后可以对给定的服务实例调用任何暴露的服务操作，其通常遵循请求响应模式。

附图的简要说明

在以下的详细书面描述中，本发明的上述以及另外的目的、特征和优点将变得清楚。在所附权利要求中阐述本发明的新颖特征。然而，通过参照下面的附图阅读示例性实施例的详细描述，将最佳地理解本发明本身，以及本发明的使用的优选模式、另外的目的以及优点，在附图中：

图1示出现有技术中的Web服务开发和部署处理；

图2示出根据本发明的新的部署方法；

图3示出在实现根据图2的本发明的部署方法所需的分布式网络体系结构中涉及的当事方；

图4示出根据图3的用于实现本发明的部署方法的分布式网络体系结构的涉及的当事方的组件；

图5示出根据权利要求3的涉及的当事方的组件的相互作用示图；

图6A到图6G示出根据本发明，当向服务容器注册任何种类的服务的资源的新的表示时的活动；

图7A到图7L示出在使用Web服务容器的Web服务体系结构中用于服务的动态部署的本发明的系统和方法的优选实施例。

关于图2，示出了在面向服务的体系结构中的服务的开发和动态部署的本发明的方法的示意性表示，所述面向服务的体系结构至少包括：描述提供者3、主机环境4(服务容器)、以及服务消费者2。在创建了任何声明性描述语言的服务描述8(即，以状态化Web服务为例的(状态化)服务的描述)之后，描述提供者3调用对主机环境4的操作，其允许注册10(即，部署)可表示任何种类的资源(例如，状态化资源)的新的服务描述。向主机环境4注册新的服务描述，这一操作可在运行时期间发生，而不需要重新启动主机环境以便注册或实例化新的服务，其后，主机环境4(例如，应用服务器或服务容器等)负责分析和检查提交的服务描述的有效性，以存储描述的服务并且使得它可用于感兴趣的服务消费者2来进行实例化。感兴趣的服务消费者2可向主机环境4查询被主机处理的可用服务，并随后实例化任何现有的服务的新的服务实例。如果已创建服务实例，则可通过与基础服务相应的服务接口12(例如，Web服务接口)对其进行访问，通过主机环境4自动暴露基础服务(由于主机环境也暴露其操作作为服务，所以也可将其称为主机服务)。服务消费者2随后可调用对于给定的服务实例(在得自描述的服务类型的服务接口之后)的任何暴露的服务操作，其通常遵循请求响应模式。

图3示出在实现根据图2的本发明的部署方法所需的分布式网络体系结构中涉及的当事方。

服务容器4(即，主机环境)优选的是状态化服务容器，其提供受管理的运行时环境并提供透明事务处理、持久保存、消息传送子系统和工作流引擎，其控制服务实例的工作流驱动的操作的执行。所述服务容器可在任何种类的数据处理单元上运行，所述数据处理单元诸如具有处理器、工作存储器、辅助存储器、以及在理想状况下具有网络(有线或无线)接入的普通PC、专用服务器等。

资源提供者13提供物理或逻辑资源，它们应该经由服务容器4提供给潜在服务消费者2。

描述提供者3向服务容器4提供专用服务(可能表示状态化物理资源)的描述。

服务消费者2对使用由服务容器4提供并位于其中的一个或多个服务感兴趣。

所有这些涉及的当事方可经由网络连接，并且在这一基础结构之内通信并交换信息。

本发明详细描述资源提供者13可以如何将任何种类的(状态化)资源提供给服务消费者2。为了完成这一目的，描述提供者5(可以是资源提供者本身)必须创建表示其选择的资源的服务描述。在描述其资源(源代码)的这种表示之后，他能够向服务容器4注册所述描述。其中，感兴趣的服务消费者2会创建服务描述(＝资源的类型)的单独的实例并经由选择的协议(通过服务容器的供应而定义，至少应提供通过SOAP的Web服务)与它相互作用。

图4示出所涉及的当事方的组件。

服务容器4至少具有下述组件：

服务描述数据存储器22，包含已经向服务容器4注册的服务描述。

服务实例数据存储器23，包含属于服务存储器22中的服务描述的所有实例。

接口80，包括下面一组子接口40、43，需要它们来实现本发明：

注册服务接口40，其允许描述提供者注册表示任何种类的资源的新服务的服务描述，以及

服务接口43，当服务描述的注册已经成功时其被自动创建。

优选的是，将下述进一步的子接口包括在服务容器中：

信息检索接口41，其可用于对所述容器进行查询，以查询部署的服务和服务实例，以及

实例化服务接口42，其允许服务消费者对由所述容器提供的服务描述进行实例化。

可另外将下述进一步的接口包括在服务容器中：

删除服务实例接口，其允许服务消费者明确地删除不再使用的实例，

用于每个先前向容器注册的服务的接口。使用这一接口以及指向符合这一接口的单独的实例的唯一句柄(handle)，服务消费者可访问并操作实例，以及

撤销(Deregister)描述接口，其用于撤销不再使用的服务描述。

资源提供者13提供对物理和逻辑资源14的访问，所述资源14例如：CPU(计算周期)、存储器(用于数据存储的物理装置)、网络(具有各种质量的服务，即，关于带宽、吞吐量等的网络资源)、软件服务(即，数据库或Web服务器)、计费服务、计量服务(这种服务以时间级、负载级、吞吐量级等为任何服务消费者计量资源的使用，并将这一计量信息提供给实体服务消费者)、记帐服务(这种服务使用经由计费和计量而收集的数据来创建用于资源的使用即付费的帐单)。资源提供者13可提供通过诸如CIM、SNMP、SSH、远程登陆等各种方式对它的资源的访问。

可以由同一个当事方充当资源提供者13的角色和描述提供者3的角色。描述提供者以及资源提供者这两者也可在服务消费者角色方面起到作用。

描述提供者3负责创建服务的描述并向服务容器注册创建的描述，所述服务容器可优选的是状态化服务容器。为了创建服务描述，服务提供者3遵守规定某种声明性描述语言(即，基于XML)的句法和语义的语法。使用所述语法，以便规定反映资源的服务的描述。为了向服务容器4注册所述描述，需要指向容器的注册器接口的端点引用。此外，描述提供者需要具有由将被描述的服务表示的资源的某种信息或某些概念。这也可包括协议专用信息(以便在后台直接访问物理资源)。

服务消费者2仅需要知道如何寻址服务容器接口43(即，需要指向容器接口的端点的端点引用/URL)。可通过查询状态化服务提供者的接口动态地获得服务消费者所需的所有其它信息。

服务消费者2可具有高速缓存或存储器，以便持久地保存引用服务和服务实例等的句柄。然而，这仅是优选的情况，所述高速缓存或存储器并不是必须强制设置的。还可使用状态化服务容器的信息检索接口动态地获得所有所述信息。

图5示出根据权利要求4的涉及的当事方的组件的相互作用示图。

图5给出所有的组件如何相互作用的概述，示出新的服务描述的动态部署或注册，并演示例如状态化服务实例的服务实例的后续实例化，以及与它们的相互作用。

首先，必须由资源提供者提供某种资源(0)。可以各种方式(即，经由SNMP、CIM、SSH、远程访问等)提供对这些资源的实际访问。

此后，描述提供者创建并注册反映实际资源的服务描述(1)。

一旦在服务容器(优选的是状态化Web服务容器)中存在可用的服务，则服务消费者可检索关于注册的服务和实例的信息(2；如果有的话)。

在服务描述已经被注册之后，可由感兴趣的服务消费者对它们进行实例化(3)。

经由分别注册的服务描述的自动暴露的服务接口，服务消费者可随后与服务实例相互作用。因此，服务消费者可调用对服务实例的操作，并因此改变服务实例的状态(4)。

如果不再使用服务实例，则服务消费者可选择删除所述实例(5)。

可从状态化服务容器撤销不具有相应服务实例并且不再使用的服务描述(6)。

图6A至图6G示出根据本发明当向服务容器注册任何种类服务的资源的新的表示时的相互作用。

当向服务容器注册任何种类服务的资源的新的表示时发生以下活动(见图6A)：

描述提供者3使用某种声明性描述语言的方式定义并声明它的选择的服务描述(即，符合某种将被虚拟化的物理或逻辑资源)。可自动(使用模板)或手动完成新的服务的描述。

描述提供者3调用服务容器4的某种注册(服务描述)操作，并由此注册服务描述。服务容器4利用服务存储器分析、验证并注册表示新的类型的资源(例如，状态化资源)的服务描述。在成功注册之后，提供服务描述以便进行实例化。

如果注册操作成功，则服务容器4将唯一ID，描述句柄(引用注册的服务)返回到描述提供者3。

为了检索关于注册的服务、它们的描述和接口以及现有的服务实例的信息，提供以下方法：

检索服务信息(见图6B)：

在第一步骤10，服务消费者2可检索描述句柄(对已经向服务容器4注册的服务描述的唯一引用)的列表。

具有这种描述句柄，服务消费者2可检索与描述句柄相应的服务描述20。

此外，服务消费者2还可通过提交描述句柄作为参数来获得由注册的服务自动暴露的服务接口(即，Web服务器情况下的WSDL)30。

此外，服务消费者2还可检索实例句柄的列表，所述实例句柄引用属于由提交的描述句柄描述的服务的所有服务实例40。

在一个服务可由服务消费者2使用之前，其需要被实例化。

实例化服务(见图6C)

为了实例化注册的服务，服务消费者2调用实例化服务(...)操作，并传递描述句柄(其将成为服务示例的类型)以及可选数据(用于实例化)作为参数10。可选数据可包括用于服务实例初始化的状态信息，对于相应实体的所需服务质量要求等。

服务容器2创建新的服务实例并向服务实例存储器注册所述新的实例。服务实例符合由服务规定的接口。

可选择性地提交的数据也持久地存在于服务实例存储器中。

如果实例化成功，则服务消费者2获得唯一实例句柄，所述实例句柄引用新创建的服务实例。

可经由基础服务的服务接口访问现有的服务实例。可以预见服务消费者2和服务实例之间的各种相互作用，即，操作调用、通知产生和接收、对外部工作流活动的调用、以及服务质量特性的动态变更或设置。以下描述典型相互作用的方案：

使用服务实例1(见图6D)

如果服务消费者2已经保留对于期望的服务实例的引用，则他可向服务容器4提交这一实例句柄。

作为提交的实例句柄的结果，服务消费者2接收相应的描述句柄，其引用服务实例的服务10。

在服务消费者2可与服务实例相互作用之前，必须通过提交服务实例所符合的服务的描述句柄来获得服务接口(20；服务接口例如可以用WSDL描述)。

在服务消费者2获得服务接口之后，可使用经由接口暴露的任何操作来与服务实例30相互作用。当操作被调用时，必须传递实例句柄连同可能的其它参数。

服务容器4在服务接口截取操作调用，并将其路由到正确的服务实例(由提交的实例句柄指示)40。

如果所调用的操作是复杂的工作流驱动的操作(通过工作流执行引擎截取和管理)，则外部活动提供者可提供一个或多个包含在工作流操作中的活动60。按照由工作流操作定义规定的顺序调用这些活动。

该操作潜在地更新服务实例的状态。

经由服务容器将潜在返回值返回到服务消费者2。

修改服务描述(见图6E)

为了修改现有服务，描述提供者调用修改操作并提交描述句柄连同期望的对描述的修改作为参数10。

服务容器4随后修改服务并更新服务数据存储器20。

此外，向主题注册处(topic registry)添加可能的主题，或将可能的主题从主题注册处中去除，因此，修改可持久地存在于主题存储器中。

可删除不使用的服务实例：

删除服务实例(见图6F)：

如果不再需要一个现有的服务实例，则服务消费者2可调用删除操作，并传递指向将被删除的服务实例的期望的实例句柄10。

容器随后从服务实例数据存储器删除所述实例20。

下面，服务消费者2接收指示删除操作是否成功的状态码。

在符合这一类型的所有服务实例被禁止存在之后，可动态撤销不再需要的服务描述。

撤销服务描述(见图6G)：

如果不再需要现有的服务，则服务消费者2可调用撤销操作，并传递指向将被撤销的服务描述的期望的描述句柄10。

服务容器4随后从服务存储器撤销所述描述20。

下面，服务消费者2接收指示撤销操作是否成功的状态码30。

图7A至图7L示出用于在使用Web服务容器的Web服务体系结构中的服务的动态部署的本发明的系统和方法的优选实施例。

Web服务容器表示Web服务的主机环境，用于服务实现的生存周期管理、方法调用的并发管理、持久保存和事务服务。完成这些服务，其还可支持基于主题的管理和安全性。

在该优选的实现中，以声明性描述语言在Web服务容器中部署服务，其中，所述声明性描述语言通过使用实体类型描述来建立模型。

通过声明性描述语言来描述实体类型，并且实体类型提出任何可以构想的资源类型的面向服务的表示。当以抽象方式完成资源的面向服务的表示时，可将实体类型映射到面向服务的体系结构(即，状态化Web服务)的任何可构想的实现。

图7A示出资源类型、相应的实体类型和一种向潜在服务客户暴露实体类型的可能性之间的关系。实体类型提供资源类型的抽象的面向服务的表示，并定义在面向服务的领域如何暴露特定资源类型。这种资源和实体的分离允许对于哪个资源类型的属性以及哪个状态信息将可用的精细级别进行定义。主机环境，例如，状态化Web服务容器随后将使用Web服务标准自动地暴露抽象的服务表示。

这种资源建模的方法兼备几个优点。第一，所述方法将实际资源类型从用于产生资源的抽象的服务表示的实体和它们的状态分离。第二，所述方法使得可以使用除Web服务之外的服务实现来暴露资源的状态。第三，由于可使用自动暴露的服务接口访问全部的各种资源，所述方法提供各种资源的统一视图。

可以以使用声明性描述语言语法的声明性方式描述逻辑或物理资源。产生的实体类型描述以抽象和面向服务的方式表示资源类型(见图7B中这种描述的示例)。由于实体类型描述仅定义资源类型的抽象的面向服务的表示，所以必须将它传送到Web服务容器，其自动将实体类型绑定到相应的Web服务接口，并提供生存时间管理操作，以便注册新的实体类型描述和撤销现有的实体类型描述。遵循此推理思路，任何实体类型描述具有单独的生命。

首先，在可通过Web服务接口表示或暴露资源类型之前，必须规定各个资源类型的实体类型描述。这通过使用<entity-type>元素、它的子元素和属性来完成。通常，实体类型描述包括：名称、组、几个操作以及与其它实体类型的关系。当从将被表示的资源类型得到这种实体类型描述，并且决定暴露哪个状态信息之后，可向Web服务容器注册创建的实体类型描述。作为注册的结果，Web服务容器将使得实体类型的服务接口对于潜在的服务消费者可用，并暴露每个注册的新的实体类型的单独的Web服务接口。此外，每个注册的实体类型描述被分配通用的唯一标识符，其允许用于进一步的引用和实例化。这种关于每个部署的资源的服务视角利用SOA的优点，即，跨边界并独立于平台的互操作性，因此，以标准化的方式提供表示的资源类型的统一服务视图。

一旦实体类型被注册到Web服务容器，所述实体类型就经由Web服务容器的生存时间相应管理操作被提供以进行实例化。

在最简单的情况下，Web服务容器仅实例化期望的实体类型，而没有进一步的参数或隐含的假设。这产生经由正被主机环境创建的实体类型的Web服务接口访问的新的实体实例。如果不再需要这种实体实例，则必须使用所述容器的销毁接口明确地删除所述实体实例。在明确的实体实例删除不适合的情况下(例如，因为它的易出差错、不可靠的网络连接或仅是因为它被忽略了)，Web服务容器也向实例化提供如OGSA中公知的软状态管理语义。因此，可要求容器以给定的生存时间来实例化实体类型。这可通过以下操作来完成：规定实例必须存活到的将来的日期和时间，或者简单地声明允许实例生存的持续期的毫秒数量。在需要实例的时间期限长于当它被实例化时规定的时间期限的情况下，Web服务容器还提供保持存活(keepAlive)操作，其允许对于专用的实体示例定义新的生存时间。这样做的优点在于容器掌管实例销毁，服务消费者可简单地不考虑不再使用的实例。

当已经创建实体实例并且还向其分配了通用唯一身份之后，可经由实体实例的基础实体类型的Web服务接口访问所述实体实例。这使得可以与实体实例相互作用，并由此检索状态信息，执行作用于实体实例的内部状态的操作或调用其它外部服务操作。

图7C示出实际资源、实体实例和相应的Web服务接口的可行设置。Web服务容器4管理两种Web服务(例如，状态化的)，其中的每一个符合一种不同的实体类型，并且通过它们各自的Web服务接口被暴露。作为Web服务接口1的基础的实体类型提供资源类型RT1的面向服务的表示。定义Web服务接口2的实体类型2表示资源类型RT2。RT1表示现有的物理或逻辑资源类型，可使用某种特定资源协议(由虚线箭头指示)远程管理所述资源类型的资源实例(R1a、R1b、R1c和R1d)，与之相比，RT2表示纯概念上的资源类型，直接在Web服务容器内管理所述资源类型的资源实例(R2a和R2b)，并使得它们持久保存。已经由状态化Web服务容器的厂商接口(未示出)创建了几个实体实例。在实体类型1的情况下，这些实例(实体实例1a、实体实例1b和实体实例1c)充当对于位于外部的资源的代理。在这一点上意识到以下内容很重要：实体实例不能必然地与表示由实体类型表示的资源类型的实例的单个的实际资源关联。所谓的虚拟化的技术允许聚集几个实际资源，以便满足需求多的服务实例的需要(由包括R1a、R1b和R1c的合成资源服务于实体实例1a)或允许由同一个实际资源来处理几个实体实例(实体实例1b和实体实例1c均作用于R1d)。关于实体类型2和它的实体实例，可以看出，由于实际资源与实体实例相配合，所以可在没有任何特定资源协议的情况下直接管理资源状态。在这种情况下，当创建新的实体实例时，实际资源的供应仅涉及数据库表的创建或类似处理，以便使得所述资源状态持久保存。每当表示外部逻辑或物理资源时，各个资源的实际供应就会复杂得多，并涉及诸如安装、硬件重新引导或改变网络设置的处理。

实体操作会以双重方式出现并被描述。一方面，它可定义如传统编程方式中公知的简单的程序操作。

这些简单的普通操作可通过普遍的编程构成、操作符、参数和返回语句来定义。另一方面，也可对于每个实体类型规定所谓的工作流驱动的操作。与简单操作不同，这些更加复杂的声明性编程构成遵循如从各种工作流方法中可知的更加综合的语义。它们特别适合定义、管理和监控任何类型的控制流，所述控制流掌管如何对一组给定的单个活动进行串行、并行或同步。关于这些不同种类的实体类型操作的暴露，外部Web服务消费者无法在两种操作类型之间进行区分。虽然Web服务接口不能暴露它们之间的差别并使得它们的固有区别对于它的客户而言透明，但是这些操作的实现很好地实现了所述差别。因此，语言处理器将以两种不同的操作模式来执行带有不同语义的操作。

图7D描述Web服务体系结构的组件。

第一个并且是最突出的组件表示Web服务容器4，其优选的是状态化Web服务容器。尽管如此，初看起来，人们不会把主机环境本身看作是代表单独角色，会这样认为是由于容器与多个责任关联。具体说来，其负责向外部提供一组Web服务接口，这允许潜在描述提供者注册或撤销新的实体类型的描述。此外，它必须暴露使得服务消费者2能够以各种方式创建、管理、组合和销毁实体实例的接口。为了允许服务消费者2实例化并使用注册的实体类型，容器必须还提供查询接口，其允许检索关于注册的描述和现有的实体实例(例如，用于引用的唯一句柄)的信息。此外，Web服务容器4必须提供实体实例的受管理的运行时环境，并负责它们的Web服务接口的自动暴露，所述Web服务接口符合相应的实体类型描述。此外，容器4负责持久地存储注册的实体类型以及实例状态。在实体实例表示外部资源的情况下，容器额外需要确保资源的状态在实体实例内得到反映，并且可以被感兴趣的服务消费者访问。

资源提供者13

资源提供者组件13的责任在于提供稍后可由实体类型描述进行描述的任何种类的资源。由资源提供者13提供的资源需要可通过特定资源协议被访问。

描述提供者3

描述提供者3负责通过用声明性语言描述新的实体类型来创建所述新的实体类型。此外，描述提供者3还负责经由它的专用注册接口向Web服务容器注册新规定的描述。作为所述体系结构的结果，将实体类型的提供者从如传统方法中可知的单调和易出差错的部署处理中解脱出来。

描述提供者不必执行编码、编译、描述、打包和最终将可执行内容传送到主机环境中的预定义位置，描述提供者仅需要调用对Web服务容器自身的接口的专用注册操作，并传递描述作为调用参数。

服务消费者2

一旦描述提供者3注册了新的实体类型描述，基于所述实体类型的新的实体实例就可被实例化。这种新的实体实例的创建是服务消费者2的责任。为了实例化实体类型，服务消费者2必须首先查询Web服务容器的信息检索接口并获得引用期望的实体类型描述的句柄。在实例化之后，服务消费者2获得唯一实例标识符并可随后经由它的Web服务接口与实体实例相互作用，所述Web服务接口从实体类型获得并符合所述实体类型。使用基础实体类型的Web服务接口，服务消费者可调用任何暴露的实例操作，并因此改变实体类型的固有状态。除非已使用容器的软状态管理接口创建实体实例，否则服务消费者2最终也将必须删除不再使用的现有实体实例。

外部消息传送源和归宿(sink)15

由于状态化Web服务容器不仅支持在生存于主机环境之内的实体实例间发送和接收异步消息，而且支持在Web服务容器4和外部当事方之间发送和接收异步消息，所以分别存在外部消息传送源和外部消息传送归宿的角色。在外部消息传送源的情况下，任意组件能够通过容器的消息传送协调(broker)接口创建新的消息传送目的地。作为现有消息传送目的地的结果，允许外部消息传送源为了公开向任何现有的消息传送主题或队列进行注册。每当在这种注册的消息传送源的一部分上发生特定事件时，将经由容器的消息传送协调接口向各个目的地公开指示发生的事件的新的消息。关于外部消息传送归宿角色，允许外部系统组件创建新的目的地，或预定感兴趣的任何现有目的地。这将导致：每当向相应的消息传送目的地公开消息时，外部消息传送归宿将得到通知。

外部服务提供者16

正如状态化Web服务主机所暗示的，Web服务容器4遵循面向服务的体系结构的要求提供其服务。因为生存于主机环境内的实体实例也可如同生存于SOA内的服务那样作用，所以它们可包括在实体本身内不能实现但是可由另一服务提供的功能性。这种封装的功能性可由生存于相同容器中的另一实体实例提供，或者可由实现期望的功能的外部服务提供者提供。这两种方法中的前者仅关注由生存于相同容器内的实体实例提供的功能性，并且可使用先前建立的关系进行寻址，后者包括外部服务的调用。可通过实体实例的简单操作以及工作流驱动操作两者来发起由外部服务提供者提供的这些服务。

Web服务容器组件4

在已经描述涉及可动态部署的状态化Web服务容器的一般体系结构的各个组件之后，现在，这一部分将更近地关注负责实现实体的主机环境的性能的各个组件。顺便说明，很重要的一点在于注意：以下的将状态化Web服务容器分解为单个的组件必须被看作既不是规定性的也不是特定的实现。这样，如下所述的组件表示在应用的体系结构中如何反映容器的责任的一种可行方式。这并不意味着任何所述部分(除了容器的接口)需要由状态化Web服务容器的实际实现中的具体对应部分来表示，而仅是用于更详细地说明主机环境的责任，以使得这些解释更加确实。

图7E示出所述各个部分以及它们之间的关系的示意性示例。

容器接口20(20a-20d)

如先前所述，通过良好定义的Web服务接口20以面向服务的方式暴露容器的功能性。将所述接口组成多个端口类型(20a-20d)，其向服务消费者提供具体操作的集合。在图7E中示出容器的Web服务接口的端口类型和各个操作的概述。应注意到，在这里，仅是简要描述了所述操作。将在对图7F至图7L的描述中给出如何与这些操作相互作用，将传递哪些参数和期待什么返回值的深入说明。

当然，由状态化Web服务容器的端口类型暴露的功能性必须通过所提供的服务的内部实现来实现。在图7E中，由各个管理器组件示意性地表示了这一点。它们表示体系结构内的部分，这些部分等同地负责与持久保存层(即，数据存储器)以及服务运行时环境相互作用。

服务接口21(21a/b)

任意实体类型的Web服务接口21很大程度上依赖于基础实体类型描述。如先前所示，实体类型描述允许定义是否将具体操作暴露为Web服务操作。只要存在至少一个属于给定实体类型的实体实例，就可通过实体类型的Web服务接口21访问声明将暴露的所有操作的集合。然而，除了声明的实体实例操作之外，还将缺省地暴露另两个实例操作。一方面，将暴露获取实体类型(getEntityType)操作，其将返回查询的实体实例的基础实体类型；另一方面，将暴露获取关系(getRelationships)操作，其将通知服务消费者关于相应的实体实例参与的所有关系。

可在图7A中找到实体类型描述以及它的相应外部Web服务接口的具体示例。

运行时环境60

在已注册并实例化新的实体类型描述之后，实体实例将生存于Web服务容器的服务运行时环境60。实体实例存在于运行时环境内，并且直到它被删除，可通过与基础实体类型相应的Web服务接口21使用所述实体实例。因为实体实例以依赖内容的角色在包含关系中起作用，或者因为实体实例以给定的生存时间进行实例化，而所述时间已经过去，所以可通过调用对容器的Web服务接口的删除实例(deleteInstance)操作的外部服务消费者、通过使用专用操作符的实体实例、通过运行时环境60本身来启动实体实例的删除。因为实体实例潜在是状态化的，所以运行时环境60也负责确定与实体实例或它们之间的关系有关的所有数据自动成为对于各个数据存储器而言是持久保存的。此外，运行时环境60紧密地与事务管理器相互操作，以便保证在必要的情况下，调用的操作在正确的事务上下文中被执行。此外，运行时环境60负责将新的实体实例和关系与通用的唯一引用关联，并且负责在创建所述实例之后立即调用对实体实例的正确的回调(call-back)操作(其被声明并映射到on-init元素)。与此类似，运行时环境60也确保发起各个如在实体类型描述中声明的on-delete回调操作。同样，声明和启动的定时器的超时也将导致正确的实体实例操作的调用。此外，运行时环境60与容器的消息传送子系统相互操作，并由此负责将异步通知传送到已经预订各个目的地的所有消耗消息的实体实例，并负责调用对它们的正确操作。

语言处理器25和工作流引擎26

由于在任何声明性语言中规定了通过注册操作提交到Web服务容器的声明性服务描述，所以容器需要具有语言处理单元，其能够解释提交的实体类型描述。首先，语言处理器负责分析、检验并验证提交的描述。在示例之后，语言处理器25执行并管理对各个实体实例的操作调用。这种实体实例操作的调用必须在简单操作模式或工组流驱动的操作模式下执行。在工作流驱动的操作的情况下，将由工作流引擎26执行所述操作，所述工作引擎是语言处理器25的子系统。

工作流引擎26保证与事务管理器的无缝互操作，以处理长时间运行的事务，并且通过允许和管理补偿活动，使得能够消除先前终止的子任务的效果。

事务管理器27

事务管理器27负责处理和管理协调以及事务上下文的创建、执行和销毁。这涉及当调用事务操作时新的事务上下文的创建，以及运行事务和现有的上下文的管理。在简单操作的情况下，总是认为在ACID特性下执行事务。

然而，在工作流驱动的操作的情况下，假设使用如在Web服务商业事务构架26中定义的状态模型来执行事务。因为在通常当各个Web服务相互作用时发生的长时间运行的事务中，分布式事务的原子性和隔离不能有效地满足，所以这一模型弱化了严格的ACID要求，而仅要求如在工作流驱动的操作的情况下使用的长时间运行的事务必须保证一致性和持续性。此外，这些事务考虑到工作流可定义补偿活动，在决定最终结果的总的工作流的某些其它任务失败的情况下，则其可反转先前成功终止的活动的效果。

访问控制器28

访问控制器负责保证只有在访问控制列表中规定了其实体类型的实体实例被实际上授予对于对目标实体实例的各个操作的访问。除此之外，访问控制器还负责管理实体类型的组，其共同访问对特定实体类型的给定实例的一组预定操作。

消息传送子系统29

为了能够实现实体实例和外部消息传送客户间的容器协调的异步通知，Web服务容器还提供作为它的相应消息传送子系统29的一部分的消息协调器(未示出)，所述消息传送子系统29以传统消息传送子系统的特征为基础，并经由消息传送端口类型而暴露它的外部协调器接口。通过其内部消息协调器，消息传送子系统29充当外部和内部消息传送客户(消息提供者和消费者等)之间的桥，并保证当与它有关的消息被公开时，如果存在消息传送消费者，则持久地存储目的地、预订、注册以及公开的消息。为了保证与新近的Web服务标准兼容，可扩展消息协调器的Web服务接口，以符合最近公布的Web服务通知规范17。然而，这带来的缺点在于类型队列的消息传送目的地不再被支持。

数据存储器30

为了寻址Web服务容器的状态化属性，容器必须提供一组数据存储器30，其负责使得所有各种信息能够持久保存。以下给出各个数据存储器的简要描述：

实体类型数据存储器30a

实体类型数据存储器负责保留所有先前注册的实体类型描述，直到它们被撤销或修改。必须在实体类型数据存储器30a以及与各个实体类型相应的实体实例之内均反映出对实体类型的修改。如果修改了带有生存实体实例的实体类型，则必须也在实体实例存储器或基础具体资源中反映出所述改变(在实际资源被建模的情况下)。将已经向容器成功注册并在实体类型存储器内持久保存的实体类型处理成可用于随后的实例化。

实体实例存储器30b

如果从先前注册的实体类型创建了新的实体实例，则实体实例数据存储器30b负责保存与这一单独的实体实例有关的所有状态数据。

目的地数据存储器30c

目的地数据存储30c包括与异步容器协调的消息传送有关的所有信息。其包括消息传送目的地(即，主题和队列)、对现有的消息传送目的地的预订以及注册。在预订的消息消费者暂时不在的情况下，目的地存储器还负责将消息存储到这种消息传送归宿，以便允许消息协调器在相应的客户再次出现之后发送所错过的消息。

协议注册处30d

由于Web服务容器关于特定资源协议必须尽可能地灵活和可扩展，因此所述体系结构提供向主机环境动态地注册对新的特定资源协议的支持的可能性。这使得语言处理器也可处理先前不知道的新的协议。为了存储新注册的协议，容器提供协议注册处，其连同专用协议注册接口操作2一起使用。

图7F示出注册实体类型描述的相互作用。

为了注册新的实体类型描述，首先，描述提供者规定新的实体类型描述，其描述他选择的任何种类的资源的行为(即，符合某种物理或逻辑资源)。通过从头指定新的描述，可自动(通过使用来自模板或部分存储库的模板)或手动完成新的实体类型的描述。在声明新的实体类型之后，描述提供者可调用Web服务容器的注册端口类型的注册实体类型(registerEntityType)操作，由此要求主机环境注册发送的实体类型描述。接着，容器分析、验证并向实体类型存储器注册表示状态化资源的新的类型的描述。在成功注册之后，提供新的实体类型以进行实例化。如果描述还包括新的目的地的声明，则将它们存储到容器的协调器的目的地存储器。作为成功注册的结果，Web服务容器将通用的唯一描述句柄(引用注册的实体类型)返回到描述提供者。在失败的情况下，容器就将返回错误码。

图7G示出用于修改现有的实体类型的相互作用。

如图7E所示，Web服务容器的注册端口类型还允许在运行时期间修改现有的实体类型。为了扩展或最小化实体类型的接口，描述提供者可选择调用修改实体类型(modifyEntityType)操作，传递指向各个实体类型描述的描述句柄和修改的实体类型描述作为参数。结果，Web服务容器修改现有的实体类型和相应的实体实例以适宜于提交的修改，并将所述改变存储到有关的数据存储器。结果，容器将返回指示修改是否已成功采用的状态码。

图7H示出用于现有的实体类型的撤销的相互作用。

如果不再需要一个现有的实体类型(即，没有留有属于所述实体类型的实体实例)，则描述提供者可选择调用撤销实体类型(deregieterEntityType)操作，并传递指向将撤销的期望的实体类型描述的描述句柄。Web服务容器随后将从实体类型存储器撤销所述描述。接着，描述提供者将接收指示撤销操作是否成功的状态码。

实例化和销毁

在向容器注册实体类型之后，可实例化并使用它们。可经由Web服务容器的实例化端口类型来完成新的实例的实例化和修改。将在下面的部分描述属于所述端口类型的操作。

图7I示出用于实例化实体类型的相互作用。

为了实例化注册的实体类型，服务消费者可调用Web服务容器的实例化实体类型(instantiateEntityType)操作之一，并传递引用将被实例化的实体类型的描述句柄作为参数。如果以给定的生存时间创建实例，则Web服务容器还应负责在指出的时间过去之后销毁实体实例。为了上述原因和管理每个单独的实例的生存时间，生存时间数据必须连同实体实例的初始化数据(如在基础实体类型描述中声明的)被持久保存。如果实例化处理成功，则Web服务容器将所述新的实体实例与将被返回到服务消费者的通用的唯一实例句柄关联。如果实例化失败，则将通过将错误码返回到服务消费者来指示这一情况。在以给定的生存时间创建新的实体实例，而需要相应实例的时间长于先前设置的时间的情况下，服务消费者可选择(重复地)调用保持存活操作，并指示其生存时间将被延长的目标实例。可选地，服务消费者还可规定新的生存时间，在所述生存时间之后将去除所述实体。

图7J示出用于删除实体实例的相互作用。

如果在某个时间点，不再需要一个现有的实体实例，则可使用实例化端口类型的删除实体类型操作明确地将其删除。当由服务消费者调用所述操作时，必须传递引用将被删除的实体实例的实例句柄作为参数。如果服务消费者被授权执行所述操作，则Web服务容器将调用实体实例的on-delete回调操作，并随后从主机环境的实体实例存储器去除相应实例。结果，服务消费者将接收指示删除操作是否成功的状态码。

服务使用和相互作用

一旦注册的实体类型已被实例化过第一次，并且只要存在至少一个与给定的实体类型相应的实体实例，就可通过各个实体实例的基础实体类型的Web服务接口访问所述各个实体实例。在主机环境内的服务特定接口的单独的端点上可访问所述服务特定接口。除了服务特定操作之外，每个单独的Web服务接口提供至少两个另外的操作。第一、返回给定的实体实例的实体类型的操作；第二、返回相应实体实例参与的所有关系(隐含的以及明确的)的操作。

图7K示出简单实例操作的调用。

为了说明专用实体实例如何与服务消费者相互作用，这一部分提供服务消费者调用对实体实例的简单操作的示例。在服务消费者可与给定的实例相互作用之前，首先，消费者必须获得引用期望的实体实例的实例句柄和在其中可访问基础实体类型的Web服务接口的端点引用。如将在下一部分所述的，为了这一目的，容器提供专门的自省端口类型，其允许感兴趣的服务消费者收集需要的信息。一旦服务消费者获得了需要的信息，它就可自由地通过相应Web服务接口访问任何一个暴露的实体实例的操作。通过寻址Web服务端点和发起期望的操作并提供实例句柄以及另外的必需参数，可完成上述处理。结果，容器管理的Web服务端点将截取调用，并将操作调用路由到期望的实体实例。作为调用的操作的结果，相应实体实例可改变它的内部状态，并将调用的结果返回到实体消费者。

图7L示出工作流驱动的操作调用。与发起简单实例操作类似，服务消费者也可选择调用在给定的实体实例上定义的工作流驱动的操作。如同在简单操作的情况下一样，当调用所述操作时，服务消费者也必须提供实例句柄以及可能的参数。当最终对目标实体实例执行操作时，所述操作执行如在相应实体类型描述中规定的活动。这也可包括在长时间运行的事务上下文下执行的外部工作流。如同简单操作一样，工作流驱动的操作最终也可将结果返回到服务消费者。不过在大多数情况下，由于使用异步通知来通知服务消费者关于结果的信息不需要阻止服务消费者的一部分，所以这种处理更加切合实际。

可以按硬件、软件或者硬件及软件的组合来实现本发明。可以按在一个计算机系统中的集中式方式或不同的部件遍布在几个互相连接的计算机系统中的分布式方式来实现根据本发明的工具。适于实现这里描述的方法的任何种类的计算机系统或其它装置都是适合的。典型的硬件和软件的组合可以是带有计算机程序的通用计算机系统，当加载并执行所述计算机程序时，其控制计算机系统，从而可实现这里描述的方法。

本发明还可被嵌入计算机程序产品中，其包括能够实现这里描述的方法的所有特点，当将所述产品加载到计算机系统中时，其能够实现这些方法。

此上下文中的计算机程序装置或计算机程序表示以任何语言、代码或符号的一组指令的表示，所述指令是用来使具有信息处理能力的系统直接执行特定功能，或在以下操作中的任一个或两者之后执行特定功能：

a)转换为另一语言、代码或符号；

以不同的材料形式来再现

定义

服务的动态部署

支持动态部署的系统提供这样一种机制：其获得由开发者或应用提供的源代码，并动态地将其安装在目标服务容器(即，主机环境)中，而不需要进一步的用户交互，也不需要重新启动应用服务器。因此，应用对它的用户或服务消费者可用。

实体类型：

实体类型通过声明性描述语言来描述，并提供任何可以构想的资源类型的面向服务的表示。当以抽象方式完成资源的面向服务的表示时，可将实体类型映射到面向服务的体系结构(即，状态化Web服务)的任何可以构想的实现。

实体实例：

实体实例表示抽象的面向服务的实例，并且可与给定的具体资源实例关联。任何实体实例具有基础实体类型，具有身份(由主机环境分配给实例)，遵循生存周期，并且将具体值分配给由实体类型定义的属性。

资源类型：

任何实际的资源实例(物理的或逻辑的)具有基础资源类型，其捕获相应资源的重要特性，即，它提供的功能性(例如，文档的文本处理、复制、剪切、粘贴)，它包括的属性(即，处理的文档的名称，当文档已经存储之后，剪贴板的内容)，以及它允许这些属性的可能状态。

资源实例：

必须将具体的资源实例看作符合资源类型的实例。其具有良好定义的身份并保存状态信息，即，其为资源的每一个属性定义一个值。

服务容器

服务容器(即，主机环境)优选的是状态化服务容器，其提供受管理的运行时环境并提供透明的事务处理、持久保存、信息接发子系统和工作流引擎，所述工作流引擎控制服务实例的工作流驱动的操作的执行。这种服务容器可在例如普通PC、专门服务器等任何种类的数据处理单元上运行，所述处理单元具有处理器、工作存储器、辅助存储器并在理想状况下具有网络(有线或无线)接入。

Web服务：

Web服务是被设计用来支持网络上的可互相操作的机器到机器的相互作用的软件系统。其具有以机器可处理的格式(例如，使用WSDL)描述的接口，并允许其它系统以预定的方式(例如，使用所谓SOAP消息)与它相互作用。

状态化Web服务：

状态化Web服务包括表示服务的类型(通过WSDL描述)的接口，以及零到多个服务实例，其可通过接口进行访问，具有身份并遵循良好定义的生存周期。服务实例保存内部状态，并表示有限的状态自动操作，因为服务操作的结果会依赖于服务实例的内部状态。与网格服务相似，状态化Web服务定义用于发现、动态服务创建、生存时间管理、通知和一般管理的接口。

面向服务的体系结构：

面向服务的体系结构包括：至少一个服务容器、服务消费者、资源提供者和描述提供者。所有这些参与者经由网络连接，并且在所述体系结构内通信或交换信息。