CN1592291A

CN1592291A - 管理服务状态数据的方法和系统

Info

Publication number: CN1592291A
Application number: CNA2004100623193A
Authority: CN
Inventors: J·约瑟夫; T·R·马圭尔
Original assignee: International Business Machines Corp
Current assignee: International Business Machines Corp
Priority date: 2003-08-28
Filing date: 2004-07-01
Publication date: 2005-03-09
Anticipated expiration: 2024-07-01
Also published as: US20050050311A1; CN100518167C; US7693973B2

Abstract

一种用于通过建立可插入的元数据处理器来管理面向服务的体系结构内服务的服务状态数据的方法和系统，包括：建立与平台无关的、可扩展的元数据信息模型以定义关于服务状态数据的元数据；建立包括一组可扩展服务状态数据属性的可扩展元数据定义；配置一个或多个可扩展的语义处理器；配置控制器元数据处理器；以及定义所述语义处理器之间的约定。

Description

管理服务状态数据的方法和系统

技术领域

本发明涉及计算机系统信息通信。特别地，本发明涉及面向服务的状态数据和元数据。当前，在面向服务的体系结构(如Web服务)中没有内建对通知客户其状态改变的支持。对于面向服务的体系结构，这是一种重要的特性，因为大多数计算系统本质上是异步的并且客户需要通过某些异步的机制获得这种状态改变。

背景技术

在面向服务的组件模型(Java服务和/或Web服务)中，服务通过组件的实例变量和/或会话状态变量和/或永久存储介质和/或使用外部资源来掌握组件的状态。服务通过各种定制应用编程接口(API)说明其状态信息。这种接口模型不够灵活并且不可扩展，因此每个客户必须编制代码以便适应特定的API和理解通过该API定义的语义。客户不能足够灵活地根据其说明的信息模型(数据模式)来查询状态数据。这些API的细致程度以及灵活性随着不同的实现而变化。

因此，所需要的是一种用于定义机制的框架，所述机制能够通过使用说明的状态信息模型(模式)对服务状态进行各种查询，使服务以改变通知语义，实现一种灵活的服务状态说明模型来扩展服务的状态。

发明内容

在下面更详细的描述中阐明了这些和其它的改进。为了更好地理解本发明的优点和特征，请参考本说明以及附图。

本文中的一个示例实施例中公开了用于通过建立可插入的元数据处理器来管理面向服务的体系结构内服务的服务状态数据的方法，该方法包括：建立与平台无关的、可扩展的元数据信息模型以定义关于服务状态数据的元数据；建立包括一组可扩展的服务状态数据属性的可扩展的元数据定义；配置一个或多个可扩展的语义处理器；配置控制器元数据处理器；以及定义诸语义处理器之间的约定。

本文中另一个示例实施例中还公开了一种用于通过建立可插入的元数据处理器来管理面向服务的体系结构内服务的服务状态数据的系统，该系统包括：用于建立与平台无关的、可扩展的元数据信息模型以定义关于服务状态数据的元数据的装置；用于建立可扩展的元数据定义的装置，所述元数据定义包括一组可扩展的服务状态数据属性；用于配置一个或多个可扩展的语义处理器的装置；用于配置控制器元数据处理器的装置；以及用于定义诸语义处理器之间的约定的装置。

本文中的另一个示例实施例还公开了一种存储介质，该介质编码有机器可读的计算机程序代码，该代码包括这样的指令，所述指令使得计算机执行用于通过建立可插入的元数据处理器来管理面向服务的体系结构内服务的服务状态数据的方法，所述的方法包括：建立与平台无关的、可扩展的元数据信息模型以定义关于服务状态数据的元数据；建立可扩展的元数据定义，所述元数据定义包括一组可扩展的服务状态数据属性；配置一个或多个可扩展的语义处理器；配置控制器元数据处理器；以及定义诸语义处理器之间的约定。

附图说明

现在将参考附图通过实例的方式对本发明进行说明，其中各图中相同的元件标注有相同的数字，其中：

图1A图示了说明并示例了计算机实现的简化的方块图；

图1B图示了说明在进行查询时客户和服务间交互作用的简化的方块图；

图1C图示了说明在通知状态的改变时客户和服务间交互作用的简化的方块图；

图2图示了根据一个示例实施例包括用于面向服务状态的网关的信息通信框架的简化的方块图；

图3图示了根据一个示例实施例包括面向服务的状态产生器的信息通信框架的简化的方块图；

图4图示了根据一个示例实施例的关系模型；以及

图5图示了根据一个示例实施例包括可插入、可扩展的元数据处理器的信息通信框架的简化的方块图。

通过参考附图以实例方式详细地说明了本发明的优选实施例的优点及其特征。

具体实施方式

参考图1A-C和图2，在本文中的一个示例实施例中公开了一种用于在面向服务的体系结构中管理服务的状态数据的方法和装置。更具体地，框架10a定义了能够使服务20以改变通知语义扩展其状态的机制。在一个示例实施例中，服务20可以驻留在被配置为与各系统元件以及介质2通信的计算机1中，并且介质2包括具有客户30的另一计算机。此外，客户可以象服务20一样驻留在同一计算机1中。

框架10a使得服务20组件支持对服务状态数据22的各种可扩展数据查询、对服务状态数据22的改变具有自动通知的能力，以及使得服务状态数据22可以灵活地进行数据转换。框架10a是灵活的，因为客户30可以编写关于服务状态数据22的任何查询表达式；例如，对状态数据22的概览，或者对状态数据22的细致(细微)查看。有利地，框架10a是可扩展的，因为新的类型的服务状态可以被插入到该面向服务的体系结构内。在示例实施例中，通过可插入的处理器108、110、112实现这些特征，所述可插入的处理器108、110、112使用与状态数据限定符、限制以及访问机制有关的、可扩展的元数据框架10a。

应当理解，此处使用的体系结构旨在同时表示对整个结构、逻辑组件以及计算机的内部逻辑关系、其操作系统、网络或其它概念的指定及处理过程。体系结构可以是一参考模型，诸如开放系统互连(OSI)参考模型、旨在作为特定产品体系结构的模型或者其可以是特定的产品体系结构，诸如用于特定处理器或操作系统的特定产品体系结构。

计算机体系结构可以被划分为五个基本组件：输入/输出、存储、通信、控制以及处理。实际上，这些组件中的每个组件(有时称为子系统)有时也被称为具有体系结构，因此，通常要参考上下文确定其用法和含义。

通过比较，术语设计包含范围比体系结构窄的含义。体系结构是设计，但大多数设计不是体系结构。一个单独的组件或一个新的功能具有设计，该设计必须符合整个体系结构。

类似的术语，框架可以被认为是体系结构的结构化的部分，但是在此处的使用中也包括过程。框架可以同时包括对整个结构、逻辑组件以及系统的内部逻辑关系、处理器等等的指定及处理过程。

工具集可以被认为是在用户的干预下从一组输入创建产品(例如，效果、代码、模式、数据等等)的工具或功能的集合。

组件是物理的或非物理的抽象元素，其提供/有助于体系结构和/或框架的一组选定的功能/能力。

框架10a其它有益的特征是为客户30提供对数据转换的支持。基于传输的异类性质、呈现介质、QoS以及格式要求，存在不同类型的客户。这些客户30访问服务20以获得其状态数据22，并且期望该结果以适合客户30使用的方式来表达/配置。在一个示例实施例中，提供了一种基于客户(诸客户)20的要求为其转换服务状态数据22的框架10a。这些要求可以包括将服务状态数据22转换为客户可以理解和使用的格式；例如，可以为移动设备显示将来自股票报价服务的股票报价服务状态数据转换为无线标记语言(WML)格式，或为可使用语音的设备将其转换为扩展标记语言(XML)格式。

特别应该理解的是，此处公开的示例实施例的面向服务的体系结构和框架10a有助于并提供了：

1.能够查询服务20的当前状态，优选地，使用客户指定的查询语言；

2.能够使服务20向选定的感兴趣的客户发送服务状态数据22的改变。

3.将此类查询的结果以及通知信息转换成客户指定的格式。

一示例实施例使用一组元数据信息和可插入的/自适应接口以及工具解决了面向服务的体系结构的上述要求。有利地，元数据框架10a是可扩展的以便支持状态数据限定符(安全性、启用/禁用事务、事务范围等等)、限制(可用性、时间限制、生存时间、易变性、基数等)以及访问机制(推、拉和定制的访问机制)。

现在参考图1B和图1C，其示出了示例实施例框架10a中所涉及到的诸组件的示意图。其示出了服务20与客户30之间的过程和通信的一个示例性的示意图。服务20，例如Java服务/Web服务、状态地址提供者服务(State Address Provider service)以及类似的服务具有某些状态信息/数据22，诸如地址，并且希望其客户30能够使用某些查询语言来查询40该状态，所述查询语言包括，但不限于，XQuery、ISQL、XSL、EJBOL以及类似的语言。例如，客户20可以从该地址中查询邮政编码。此外，如图1C所示，服务20，例如Java服务/Web服务、状态地址提供者服务(StateAddress Provider service)，具有某些状态信息，在此实例中为一个地址，并且希望向各个可能对收听该状态数据的改变感兴趣的客户30发送状态改变的通知42，例如地址改变。

用于面向服务的状态的网关

现在转到图2，其给出了一个示例实施例框架10a的简化的方块图。在该示例实施例中框架10a包括并说明了一个用于面向服务的状态的网关(GSOS)100及其特征。GSOS100负责管理面向服务的体系结构内的服务状态数据22。服务状态数据22可以是逻辑的或物理的抽象，在逻辑意义上的状态和/或状态数据22可以只是一个指针，或是一个物理构造，例如一个实地址。在另一个示例实施例中，可以使用随框架10a可选地提供的工具创建此服务状态数据22的抽象以及元数据信息。利用一个示例实施例的所述GSOS的框架10a包括，但是并不限于，以下这些组件和功能：

1.元数据定义；

2.可扩展的元数据处理器；

3.定义服务20和GSOS100之间的交互的接口框架；

4.支持服务状态数据查询、通知和转换的可插入的接口。

元数据定义

一个示例实施例的元数据定义是一组可扩展的状态数据限制、限定符和数据访问机制。元数据定义是与状态数据22相关联的信息模型，并且提供了关于服务20的状态的更多的语义信息。通过对状态数据22模式的注释，元数据定义可以是对该模式的一种扩展，或者可以是一种更为通用的语言，例如资源描述框架(RDF)、DARPA代理标记语言(DAML)以及其它语言。在一个示例实施例中，GSOS100利用XML模型来定义此元数据信息。

可扩展的元数据处理器

可扩展的元数据处理器300(另请参见图4)包括用于处理与服务20的状态数据22相关联的元数据的规则引擎。通过基于元数据提供专家决策，此规则引擎在本质上是复杂的。这些决策包括何时通知状态改变，解释查询的语义以及从外部资源(例如，SQL、简单网络管理协议(SNMP)服务器、通用信息模型对象管理器(CIMOM)、Web服务)或从服务20检索所述状态，对事务要求和安全限制做出决策，以便对状态数据22的有效性和可用性做出决策，从而基于用户和/或客户查询标准做出将使用哪个查询处理器的决策。应当理解正如此处所述的，可扩展的元数据处理器300被说明为是GSOS100的一部分或是嵌入到GSOS100之内。然而，元数据处理器300也可以被插入到提供有适当接口的GSOS内。应当理解，基于支持定制场合的元数据语言的可扩展性，框架10a提供了扩展能力。

定义服务和GSOS之间的交互的接口框架

在示例实施例中，GSOS100提供了标准的接口以定义服务20和GSOS100之间的交互。在示例实施例中使用了三种类型的接口：

A.状态元数据管理接口102；

B.网关访问接口104；以及

C.来自服务或外部资源的状态数据访问接口106。

支持服务状态数据查询、通知和转换的可插入的体系结构

在示例实施例中，GSOS100还提供了与多个可插入的处理器间的接口以有助于并支持服务状态数据的查询、客户通知以及转换。应当理解虽然在示例实施例中给出并说明三种此类可插入处理器，不失一般性地可以构想任意数目的可插入处理器。然而，还应进一步理解，也可以构想使用类似类型的多个处理器。例如，可以利用多个查询接口108和处理器110以帮助解决框架10a，和/或客户30等等的需求。

查询

查询接口108使得GSOS100能够支持任意查询语言以及客户20对处理器110的选择。用户/客户20基于与所述状态相关联的模式创建查询。GSOS100负责基于元数据信息在状态数据22上应用该查询，并且将有关服务状态数据22的查询结果以处理器110可以理解的规范的模式格式提供给查询处理器110。另外，GSOS100还提供了高速缓存机制以支持更快的查询处理。在GSOS100的示例实施例的说明性的实现中，查询接口108支持常驻存储器的XML文件对象模型(DOM)编程接口。

通知

基于选定的通知要求，GSOS100通过通知处理器接口112支持可插入的通知处理器114。这些要求包括服务状态汇集、排队、周期性的发送以及异步行为。基于所述服务状态元数据信息，GSOS100自动地向处理器114发送包含该状态数据22的当前值和以前值的状态改变信息。

转换

基于客户20的请求，GSOS100框架将查询结果或改变通知转换成客户20规定的格式。GSOS100包括转换处理器接口116以有助于插入所选择的任何转换处理器118。

使用元信息建模生成面向服务的状态数据以及状态元数据

在本文中另一个示例实施例中公开的是一种用于基于状态数据模式为面向服务的体系结构生成服务状态数据和可扩展的元数据信息的方法和装置。该框架在状态元数据之上使用元信息模型在建模、版本控制和兼容性方便提供更多的灵活性。这使得该服务组件可以与利用先前公开的用于面向服务状态的网关(GSOS)的框架一起使用，从而支持对服务状态数据的各种可扩展的数据查询、获得自动通知服务状态数据改变的能力以及对服务状态数据的数据转换灵活性。

现在参考图3，其给出了以10b表示的框架，该框架为另一个示例实施例且是前面描述的示例实施例的扩充，该框架使用面向服务的状态生成器200(此后也被表示为SSDG)。在面向服务的组件(例如，Java服务和/或Web服务、企业(enterprise)等)中，由服务20通过其实例变量和/或会话状态变量和/或永久存储介质和/或使用外部资源来保持组件的状态。面向服务的状态的网关(GSOS)100以及框架10b通过使用公开的状态信息模型(数据模式)对服务20的状态进行各种查询，提供了灵活的服务状态公开模型。包括GSOS100的框架10b被配置为是灵活的，并且允许客户20构造关于服务状态数据22的查询表达式。框架10b还提供了用于定义机制以使服务20能够借助改变通知语义来扩展其状态的装置。该可扩展框架10b依赖于所述状态数据及其元数据信息。

在示例实施例中，定义了总体上以12表示的工具集(服务状态生成器框架)，以支持使用必须的元数据来创建状态数据22。再次地，该生成的状态数据可以是对服务状态数据22的逻辑或物理映射。工具集12可以运行于任何数据模式210(例如，XML模式、文件类型定义(DTD)、用于XML的常规语言描述-下一代(RELAX-NG)模式)之上。此服务状态生成器200通过使用元模型220为状态元数据建模来提供最大的灵活性。使用此建模比喻有助于定义具有版本控制、兼容性的元数据语言、有助于定义工作在状态数据上的工具标准以及定义代码生成标准。

在示例实施例中，工具集12和状态数据生成器200使用各种元数据和模式为服务状态数据22的生成提供了大量优点和特征。例如，工具集12和状态数据生成器200生成状态数据、状态数据逻辑映射和/或物理映射、与该状态数据相关联的元数据，并且包括与该元数据相关联的元数据模型220。工具集12生成必要的接口和代码以支持所述状态数据及其在服务20中的使用。此外，工具集12还有助于在框架10b中将状态数据创建为逻辑组(logical grouping)或具有必要的接口的直接的物理表示，以支持对元数据的要求，例如串行器和解串器、数据推拉机制等等。

工具集12和SSDG200与状态数据模式210和元数据语言一起工作。元数据语言是一种通过元数据模型220(关于元数据的元数据)描述元数据的通用语言，以有助于并确保与以前版本的兼容性。这可以是任何现有的XML语言或是其派生的语言。另外，工具集12还有助于扩展以支持新的元数据特性。该工具集12与状态数据模式210一起工作；这些状态模式210可以通过端口类型(接口)扩展性或是通过包括外部模式定义来与WSDL(Web服务描述语言)相关联。状态数据模式210可以是，但并不限于，XML模式、RELAX-NG、反向描述框架(RDF)以及类似的模式。

对SSDG200的其它输入可以包括定制的模板230、元数据属性240以及元信息模型等。

a.元数据属性240包括，但是并不限于：限定符：安全性、事务、是否应通知等；限制：状态数据可变性、生存时间(TTL)、基数以及关系(工作流)信息等；以及数据访问机制：回调机制、数据推机制、可扩展数据访问机制，诸如到数据库的连接性、通用信息模型对象TBD(CIMOM)、简单网络管理协议(SNMP)服务器以及类似的机制。

b.元信息模型220可以被看成是模式或是服务状态元数据的元数据。元信息建模通过提供版本控制、兼容性、灵活的设计过程以及标准的代码生成在服务状态数据22以及元数据设计过程中提供了灵活性。基于元数据模型的元数据使得工具集12可以提供模型版本控制机制。图4示出了根据示例实施例说明工具集12的各组件间的关系的关系模型。具体地，示出了SSDG200、元数据模型220和属性240之间的关系。

c.定制模板230包括，但并不限于，定制属性(例如，用户定义的属性)和状态元数据的默认值。

工具集12和SSDG200为服务20的状态数据22的生成以及必要的元数据的创建和与该状态数据22相关联的信息映射提供了基于图形用户接口(GUI)和/或命令行解决方案。此外，还使用了GUI特性，例如用户定制对话、元数据信息拖放、灵活的上下文菜单和创建状态数据关系(工作流)的灵活方法。

工具集12和SSDG200基于属性240，例如，与该状态数据相关联的限定符、限制和数据访问机制具有获得用户(服务开发者)对有关服务状态数据22的元数据生成的反馈的能力。

a. 通过定制对话框，用户可以给出反馈。工具集12可以向开发者查询其对属性240的类型的反馈，例如，状态数据的限定符；事务处理要求、访问控制信息、通知能力等。

b.用户可以向生成器工具集12传递参数；

c.用户可以提供模板以引导元数据生成和映射。

工具集12和SSDG200被开发和配置成可插入的框架，从而其可以用作eclipse插件或包括在其它用户用接口框架中。用户，例如，服务20的开发者，可以定义元数据信息的可扩展集合并且基于服务20的需要，为元数据属性240，例如，数据限定符、限制以及访问机制，生成可插入的扩展机制。通过可插入框架为元数据模型220提供了可扩展性。这使得服务开发者能够支持定制的元数据属性240。

工具集12提供了一组用于基于元数据模型220和数据模式210来验证元数据的验证工具。此外，工具集12还提供了某些对访问机制的运行时验证。作为一个实例，用户可以使用SQL查询和CIM依据所提供的实用程序验证数据访问。

工具集12实现了用于开发服务状态协作和状态关系的状态工作流模型。

面向服务的体系结构中的基于元信息建模的状态元数据处理器

在本文另一个实施例中公开了一种用于基于面向服务的体系结构中的元信息模型的嵌入的/可插入的状态元数据处理器的方法和装置。该框架提供了一个或多个从上述的用于面向服务的状态的网关(GSOS)框架的元模型中生成的处理器，通过利用也在本文说明的可扩展元信息模型框架，所述的处理器还具有一组扩展功能，以便处理与状态数据的限定符、限制和访问机制有关的元数据。这些处理器在特定服务控制器引擎内定义和执行，该引擎提供了过程流以及配合(orchestration)功能。

现在参考图5，在面向服务的体系结构中，用于面向服务的状态的网关(GSOS)框架10a(图2)和10b(图3)，通过使用公开的状态信息模型(例如，状态数据模式)的各种对服务状态的查询提供了灵活的服务状态公开模型。这种GSOS框架还有助于定义机制，使得服务20能够借助改变通知语义来扩展其状态。上述框架10a、10b的另一个特征是支持客户30以适合其使用的方式转换数据。这些可扩展的框架依赖于状态数据及其元数据以及元数据信息模型220(关于元数据的元数据)。该元数据提供了状态数据限定符(安全性、事务和是否应该通知等)、限制(可变性、生存时间)和访问机制(数据库连接、到CIMOM的连接、SNMP等)。使用元信息模型220对这些元数据建模并且这使得应用开发者能够以新的由服务定义的语义来创建新的元模型和/或扩展现有元模型。

在另一个示例实施例中，说明了用于通过嵌入的/可插入的并且是可扩展的元数据处理器300来处理元数据及其相关联的语义的框架10c。再次地，应当理解，用于元数据处理器300的框架10c可以与GSOS100和框架10a以及工具集12和SSDG、框架10b一起实现。在本文示例实施例中描述的元数据处理器可以被认为是嵌入GSOS100或是可插入GSOS100的。在本文另一个示例实施例中描述框架10c使用某些工作流模型(定制的或预先存在的)来控制调用流和元数据处理器300的处理逻辑。简言之，这允许定义元信息驱动的体系结构，所述的体系结构具有用于状态元数据的与平台无关的模型(PIM)以及用于处理与该状态数据相关联的元数据的语义处理器的特定平台的模型(PSM)。

有利地，示例实施例的框架10c包括模型驱动的体系结构，该体系结构具有与平台无关的模型以便为状态数据定义元数据，以及用于基于元数据模型220，对该状态元数据进行特定(语义)处理的与平台相关的模型。对平台相关和平台无关的模型的区分使得应用开发者能够为任何类型(EJB、Java bean、.NET服务等)的服务组件创建灵活的状态数据处理规则。

另外，可以创建并使用任何数目的通用语义处理器以管理状态元数据处理。这样的配置允许服务开发者为语义处理编制特定的扩展。这种通用语义处理功能所提供的一个优点是其允许用于模型扩展和应用处理扩展的灵活性。语义处理器302的另一个功能是有助于关联工作流机制(定制的或预先存在的配合引擎)。

如图2所示，如上所述的面向服务的状态的网关(GSOS)包括多个组件。这些组件包括，但是不限于，元数据处理器300(由元模型工具和/或服务开发者及其扩展所生成)，连接GSOS的接口、内部元数据表示102和连接外部系统和处理器108、112、116(查询、通知和转换)的接口。在本文公开的示例实施例中，涉及(多个)元数据处理器300及其与元数据310之间的关系、元数据信息模型220以及处理器执行流模型。另外，用于特定服务控制器处理器(特定服务的元数据处理器)的框架10c，其负责基于特定服务的要求来管理元数据处理，所述要求包括对元数据310的内部检查以及元数据处理器300的流配合。

该处理框架10c的主要组件以及元数据处理器300包括，但是并不限于，元数据信息模型220、元数据信息310、语义信息处理器302、控制器元数据处理器304和用于处理器302、304的接口102、104、106，以及用于处理器302、304的语法、语义和工作流信息320。

元数据信息模型

再次地，采用元数据信息模型220来定义关于状态元数据的元数据。在示例实施例中，该模型220与平台无关(PI)并且是平台可扩展的(PE)模型，其具有如下信息：

用于状态元数据验证、版本控制、一致性检查的元数据语法；

用于以下的元数据语义，

a.关于状态数据的限制、限定符和数据访问机制的通用语义信息

b.用于处理上述元数据语义的规则

c.元数据处理(执行语义逻辑)工作流信息；

元数据关系；以及

满足服务要求所需的元数据可扩展性。

这是个灵活的信息模型并且可以用任何模型语言(例如，XML元数据语言(XMI)、元对象工具(MOF)、统一建模语言(UML)等)表示，而且可以由面向服务的状态数据生成器SSDG200和工具集12使用，从而创建元数据以及处理那些元数据310的通用语义处理器302。

作为一个实例，我们可以通过元数据模型220定义关于状态数据的事务要求的语义信息。元数据模型220包括事务属性的与平台无关的模型，所述事务属性包括事务类型、隔离级别、锁定等。服务20的开发者可以采用前面所述的关于面向服务的状态数据生成器SSDG200(在图4中示出)的工具集12来生成特定平台的模型，该模型包括元数据处理器300，其用于事务管理、事务部署以及该特定平台的运行时配置信息。

元数据信息

对于每个服务状态数据22(逻辑的或物理的映射)，存在与该服务状态数据22相关联的元数据映射，该映射具有关于状态数据22的限制、限定符和状态数据访问机制的详细内容。这些元数据310是元信息模型220的实例并且构成了GSOS100所使用的核心数据。此映射信息使得可以设计灵活的状态管理框架。在示例实施例中，利用工具来创建这些服务状态元数据310。这些元数据与用于版本控制、验证、一致性和处理语义的元模型相关联。

基于处理元数据的元模型的语义信息处理器

这些语义信息处理器302从特定平台建模产品中创建，其源于平台无关的元模型。这些处理器302为服务20的开发者提供了接口以便定义规则引擎，所述规则引擎处理与元数据310相关联的语义。换言之，这些处理器执行由元数据310指定的有关状态数据的限制。这些处理器可以内建于特定平台和/或特定容器的处理器以便处理元数据的限制、限定符和数据访问机制。这样的处理器的一个实例可以是事务处理器，其处理关于状态数据访问的事务性要求。这些特定平台的处理器302可以配置为与特定平台的事务协调器一起工作，以便执行关于状态数据的事务性要求。这些处理器配置为遵循某些特定约定(接口和工作流)以便符合先前定义的元数据模型220。这些是基于模型的版本和特定服务要求的可插入且可扩展的处理器。

在示例实施例中，语义信息元数据处理器302被配置为与平台相关，其中每个可扩展服务处理器302涉及选定的元模型语义，该元模型语义带有规则引擎以执行所述元数据语义。每个语义处理器302带有一个由控制处理器304指定的详细定义的约定模型，其用于诸语义处理器302之间的协同工作能力。有利地，语义元数据处理器302可以使用标准的编程模型访问和发现元数据。此外，这些处理器还可以用于通过使用元数据模型220验证元数据。

控制器元数据处理器

控制器处理器304是特定服务的元数据处理器(起控制器的作用)304，其定义了诸语义处理器302间的约定并基于状态元数据信息来控制诸语义处理器302之间的数据流。服务20的开发者，可以基于元数据和元数据模型220中定义的规则开发这些处理器304和约定。可以使用工具集来开发处理器302的基本构架。此处理器提供了状态元数据和状态数据仓库。此仓库可以是为了提高性能的物理表示(高速缓存)，或者可以是服务20内或其它位置(数据库)的带有外部存储的逻辑表示。在示例实施例中，由此处理器304提供的功能包括，但是并不限于，使用元数据模型220验证元数据、检查元数据以标识并选择适合的处理器执行引擎、使用适合的协调引擎控制(多个)语义处理器302的执行流、提供各个语义元数据处理器302间的约定的定义、以及提供诸语义元数据处理器302间的流机制。控制处理器还可以提供元数据或状态数据仓库。

接口和处理流

所有的元数据处理器302、304应当遵循一些已定义的约定信息，并且当然需要遵循详细定义的接口要求。在示例实施例中，定义了元数据处理器的无状态模型。这些约定被用于管理接口，例如，生存期管理、状态管理以及处理约定(数据流、验证、版本控制等)。所述约定还有助于通过以工作流引擎协调工作流来管理过程流，并有助于实现工作流要求。

要重申的是，这些元数据处理器300提供了可插入的和可扩展的框架10c，该框架用于通过其元数据语义来管理该状态数据。此状态数据对于所述服务可以是本地的或是可以存储于其它位置，或是保持于任何外部资源内。这些元数据处理器300通过抽象模型(元模型)为客户提供了数据的公共视图，由此隐藏了平台内部特定的细节。

所公开的发明可以以计算机、控制器、或由处理器执行的过程以及用于实现这些过程的装置的形式实现。本发明还可以以计算机程序代码的形式实现，所述代码包括体现在有形介质2(图1A)内的指令，所述介质例如是软盘、CD-ROM、硬盘或任何其它计算机可读存储介质，其中，当计算机、控制器或处理器1装入该计算机程序代码并执行该代码时，该计算机、控制器或处理器1就成为了用于执行本发明的装置。本发明还可以以计算机程序代码的形式作为数据信号来实现，例如，无论是储存于存储介质，装入和/或由计算机、控制器或处理器1执行，还是通过某些传输介质被传输，例如通过电线或电缆、光纤、或经由电磁辐射，其中当该计算机程序代码被装入并由计算机执行时，该计算机成为执行本发明的装置。当在通用处理器1上实现时，该计算机程序代码段配置该处理器以创建特定的逻辑电路。

应当理解，为了表示相似的项而使用的第一、第二或类似术语并非旨在特指或暗示着任何特定的顺序，除非其被说明。

虽然已经参考示例实施例说明了本发明，本领域的技术人员可以理解，可以做出各种改变并且可以有各种等同物用于替代诸元素而不脱离本发明的范围。此外，可以做出许多改型以使特定的情况或材料适合于本发明的精神而不脱离其基本范围。因此，本发明并不限于作为实施本发明的最佳模式而构想并公开的特定实施例，本发明将包括落在所附权利要求的范围内的所有实施例。

Claims

1.一种通过建立可插入的元数据处理器来管理面向服务的体系结构中服务的服务状态数据的方法，所述方法包括以下步骤：

建立与平台无关的、可扩展的元数据信息模型以定义关于服务状态数据的元数据；

建立包括一组可扩展的服务状态数据属性的可扩展的元数据定义；

配置一个或多个可扩展的语义处理器；

配置控制器元数据处理器；以及

定义所述各语义处理器之间的约定。

2.如权利要求1所述的方法，进一步包括配置与平台相关的模型以便有助于基于所述元数据信息模型对所述服务状态元数据进行语义处理。

3.如权利要求1所述的方法，其中所述元数据信息模型为所述服务状态数据定义元数据。

4.如权利要求1所述的方法，其中所述元数据信息模型提供元数据语法以确保验证、版本控制、兼容性和一致性，并且其中所述元数据信息模型表示出了所述服务状态元数据的模式或元数据。

5.如权利要求1所述的方法，其中所述元数据信息模型为下述的至少一个提供元数据语义：服务状态数据的限制、限定符和数据访问机制和处理所述元数据语义的规则；以及工作流信息的元数据处理。

6.如权利要求1所述的方法，其中所述元数据信息模型定义了元数据关系。

7.如权利要求1所述的方法，其中所述元数据信息模型提供了元数据的可扩展性。

8.如权利要求1所述的方法，其中所述服务状态数据属性包括状态数据限定符、限制和访问机制；以及模板。

9.如权利要求1所述的方法，其中所述建立包括定义服务状态数据限定符，包括：

使能表达状态改变通知限定符，所述限定符包括通知状态结果中的改变；

使能定义并表达关于服务状态发现和通知的安全性要求；

使能表达事务要求，所述事务要求包括启用/禁用事务；以及

提供链接到事务协调器的框架并且定义事务范围，所述的事务范围包括服务开发者所控制的事务、服务控制的事务以及网关管理的关于状态数据的事务。

10.如权利要求1所述的方法，其中所述建立包括定义服务状态数据限制，包括：

使能表达关于易变性的限制；

使能通过生存时间限制来表达所述服务状态数据的有效性限制，所述生存时间限制包括以下至少一个：生存时间(TTL)、激活时间、从何时开始是可用的、到何时为止是可用的、从何时开始是良好的、到何时为止是良好的以及到何时为止不可改变；

使能对所述的服务状态数据使用基数；以及

使能说明所述服务状态数据之间的关系，所述说明支持复杂的查询和状态管理。

11.如权利要求1所述的方法，其中所述建立包括定义服务状态数据访问机制，包括：

使能通过元数据对所述服务状态数据及其表达式使用灵活的回调机制；

建立数据推机制，该机制用于通过元数据以所述限制的表达式来更新服务状态数据；

建立其它关于所述服务状态数据的可扩展的数据访问机制，所述其它可扩展数据访问机制包括在数据库中对所述服务状态数据的直接访问；通过SNMP、CIM、Web服务直接访问所述服务状态数据；以及

基于服务要求为服务状态数据访问建立可扩展的定制模板机制；所述基于服务要求的服务状态数据访问包括用于定制脚本的服务模板。

12.如权利要求1所述的方法，其中所述配置一个或多个语义处理器包括建立通用处理器，所述通用处理器配置为在一个或多个约定之下，与所述控制器元数据处理器和另一个语义处理器中的至少一个一起运行。

13.如权利要求1所述的方法，其中所述语义处理器基于特定平台建模产品是平台相关的。

14.如权利要求1所述的方法，其中所述控制器元数据处理器是特定服务处理器，其配置为定义所述各语义处理器之间的约定，并且控制其间的数据流。

15.如权利要求1所述的方法，其中所述控制器元数据处理器提供元数据或服务状态数据仓库。

16.一种用于通过建立可插入的元数据处理器来管理面向服务的体系结构内服务的服务状态数据的系统，所述系统包括：

用于建立与平台无关的、可扩展的元数据信息模型以定义关于服务状态数据的元数据的装置；

用于建立包括一组可扩展服务状态数据属性的可扩展的元数据定义的装置；

用于配置一个或多个可扩展的语义处理器的装置；

用于配置控制器元数据处理器的装置；以及

用于定义所述各语义处理器之间的约定的装置。

17.一种存储介质，其上编码有机器可读的计算机程序代码，所述代码包括用于使得计算机执行一种方法的指令，该方法通过建立可插入的元数据处理器来管理面向服务的体系结构内服务的服务状态数据，该方法包括：

建立包括一组可扩展服务状态数据属性的可扩展元数据定义；

配置一个或多个可扩展的语义处理器；

配置控制器元数据处理器；以及定义所述各语义处理器之间的约定。