CN101146106B - 级联发现web服务 - Google Patents

Abstract

本发明涉及一种用于调用所请求服务的配置，所述配置包括发现服务(2106)，该发现服务(2106)包括用于存储至少一个服务的数据模型的存储装置和用于获取服务(2103，2104，2105)的获取装置，其中所述存储装置适用于存储服务之间的关系，包括提前获取装置，用于获取所述数据模型中的多个服务的路径，其中服务的级联对应于所请求服务。本发明还涉及一种用于调用所请求服务的方法，该方法包括步骤：提前获取所述数据模型中的多个服务的路径，其中服务的级联对应于所请求服务，用于连续地调用路径上的服务。

Description

级联发现web服务

相关申请的交叉引用

本发明基于优先申请EP 06 300 944.3，在此通过引用将其包含于此。

技术领域

本发明涉及一种用于在面向服务的架构(SOA)中调用所请求服务的配置。本发明还涉及一种用于调用所请求服务的方法、一种发现服务、一种相应的计算机软件产品以及一种服务器主机。

背景技术

目前的服务技术主要集中于服务的功能性。然而，可用服务的重要部分表现出数据驱动而非功能性驱动的特征，这使得目前的技术不那么适用。本申请集中于特别是对数据驱动服务的发现。

在面向服务的架构的上下文中的服务，或者更具体地说，web服务的典型特征在于它们支持的功能。服务的开发和使用是功能性驱动的：服务基于它们的功能性被定义、搜索以及连接。

数据也经常在服务内部受到管理，但是这是服务的功能“视图”的一部分。然而，对于某些类型的服务，功能性非常类似于对服务的数据的管理。例如，典型日历服务的大多数操作涉及到数据管理而不是涉及到基于该数据的功能性。这些服务是数据驱动而非功能性驱动的。最近，例如很多在线服务表明，服务的数据驱动方法越来越重要，这些在线服务提供代表性状态传输应用编程器接口，这种接口有利于这种方法。

考虑面向服务的架构中的web服务之间的联合的情况。web服务是可以在因特网上寻址的功能实体，其在XML格式化的接口描述文档WSDL文档中公布其提供的功能性。

对于能够彼此通信的两个web服务，它们必须对一个共同协议(典型地为SOAP)以及对消息内容的共同理解(即接口)达成一致。

在SOA(面向服务的架构)中，服务松散地耦合，意味着它们典型地独立于彼此而开发，并且因此不必具有一致的共同接口。因此，必须执行映射以确保web服务提供方理解web服务接受方发送的消息。该映射典型地采取XSLT转换的形式。

本发明特别针对于(但不限于)数据联合系统，其中预定给特定服务的消息可能需要也转发给一个或多个其他服务，因为该消息可能影响这些服务共同拥有的数据。在此情况下，本发明优选地应用于类似UDDI或ebXML注册中心(Registry)之类的、作为全部服务基础设施的一部分的发现服务中。

SOA的典型实施例是企业服务总线(ESB)。ESB是分布式的基于标准的集成平台，其预见消息传送、智能路由以及转换能力方面的情况以便可靠地连接和协调服务的交互。如上所述，在这样的设置中，还需要集中于功能性以外的可用数据。总之，对服务总线上的可用数据的管理引入了不同种类的问题：

-数据在注册于总线上的服务之间分布，并且常被复制；

-服务操作驻留在不同位置上的相似数据，并因此对这些(语义相同)的数据项的同步是一个问题；以及

-交互服务的数据模型不兼容并且需要被桥接。

万维网联盟(W3C)定义了作为软件系统的一部分的(web)服务，其设计用于支持网络上的相互可操作的机-机交互(machine-to-machineinteraction)。其具有一个以诸如web服务描述语言(WSDL)之类的机器可读格式描述的接口。其他系统使用消息以其接口指定的方式与web服务进行交互，该消息可以包括在简单对象应用协议(SOAP)封装内，或遵从Restful(代表性状态传输(REST))方法。这些消息典型地使用超文本传输协议(HTTP)来传送，并且通常包括与其他web相关标准协作的可扩展标记语言(XML)。以各种编程语言编写并在各种平台上运行的软件应用可以使用(web)服务以在类似于因特网之类的计算机网络上以与在单个计算机上的内部处理通信相似的方式交换数据。

web服务描述语言(WSDL)是一种公布用于描述web服务的XML格式。WSDL是基于XML的服务描述，有关于如何使用web服务进行通信；即，有关于与其目录中列出的web服务进行交互所需的协议绑定和消息格式。所支持的操作和消息被抽象地描述，并且随后绑定到具体网络协议和消息格式。这意味着WSDL描述到web服务的公共接口。

WSDL与SOAP和XML模式结合起来使用，以在因特网上提供web服务。连接到web服务的客户端程序可以读取WSDL以确定服务器上何种功能可用。所用的任何特殊数据类型都包含在XML模式形式的WSDL文件中。客户端于是可以使用SOAP来实际地调用WSDL中列出的功能。

UDDI是通用描述、发现和集成的缩写，是平台独立的、基于XML的注册中心，用于世界范围的企业，将它们列在因特网上。UDDI是开放行业的始发端，使企业发布服务列表，发现彼此以及定义因特网上的服务或软件应用如何交互以提供地址、联络方式以及已知标识；基于标准分类方法的行业分类；以及关于服务的技术信息。

UDDI设计为由SOAP消息询问并提供对描述与在其目录中列出的web服务交互必需的协议绑定和消息格式的web服务描述语言文档的访问，参见http://uddi.org/pubs/uddi_v3.htm。可扩展样式表转换语言(XSLT)是基于XML的语言，用于XML文档的转换。它是产生AWK的XML专用过滤器语言，以及功能语言。

XSLT是一种标准，它允许将某个XML文档映射到另一个XML文档。XSLT经常用于服务上下文中以在不同XML模式之间转换数据或对XML数据进行转换。XSLT脚本典型地必须被人工构建，或者通过编写XSLT脚本本身，或者通过使用工具来辅助生成这样的XSLT脚本。后者典型地通过描绘XML文档的图形表示中的字段之间的链接而获得，但是对链接每个字段的明确需要导致麻烦的过程。

本发明拓展了诸如上述的UDDI或CORBA命名服务之类的典型发现服务的功能性，使其不仅基于语义查询返回对服务的参考，即特定客户端应用从该服务请求的功能性，并且还返回对搜索到的服务的参考，还返回在将寻址到该搜索到的服务的消息传送给该服务之前需要对该消息进行的操作。

当消息由于是不同格式/不同协议/预定给不同接口的而不能被可以提供客户端感兴趣的功能的搜索到的服务所理解时，这是非常有价值的。根据本发明的发现服务，收集充足的信息以便甚至得到消息必须经过的服务的路由，在该路由中的每个服务执行对该消息的必要调整，即格式调整例如XSLT转换，协议转换例如SOAP/HTTP转换成SOAP/JMS，接口调整例如XSLT转换。

根据现有技术，典型的情形是：在提供对服务应当提供的内容的语义描述的同时，联系UDDI，获取提供所请求功能性的服务的WSDL描述，以及对符合该WSDL描述的客户端应用进行编码。从UDDI中发现运行时参考并调用目标服务。

发明内容

根据本发明，可能利用应当被某些服务理解的消息以及对方法的语义描述来联系UDDI，然后获取对目标服务的参考以及使消息适应所返回的服务的实际接口的途径。然后可能经由发现的途径将消息转发给目标服务。

由此，本发明的贡献在于与现有技术的离线步骤加上在线步骤相比利用了服务发现的一步式方法。

该进步通过一种用于调用所请求服务的配置来达到，其中该配置包括发现服务。该发现服务包括用于存储至少一个服务的数据模型的存储装置，以及用于获取服务(2103、2104和2105)的获取装置，其中存储装置适用于存储服务之间的关系。发现服务包括提前获取装置，用于获取所述数据模型中的多个服务的路径，其中服务的级联对应于所请求服务。

通过发现至少一个服务的数据模型来获取对应于所请求服务的服务以及调用所获取的服务来执行发现，即用于调用所请求服务的方法，其中提前获取包括所述数据模型中的多个服务的路径，其中服务的级联对应于所请求服务。最后，连续地调用在路径上获取的服务。

并且本发明以计算机软件产品的形式实现，该产品包括用于执行上述方法的编程装置。

换言之，本发明实现了服务级别上的数据联合方法。数据联合的主要优势在于服务之间的仲裁：总线上的服务由第三方提供并在没有预先协定的情况下部署。作为结果，服务不需要符合共同数据模型。因为这一点，数据联合可以操作为这些服务之间的仲裁器。

基于数据的合成：除了明确的基于功能性的服务合成之外，服务可以基于相关的数据模型而合成。数据联合的示例使用是具有重叠数据模型的服务之间的同步。

例如，考虑独立部署的地址簿和即时消息传送服务。客户端可能希望改变地址簿中的条目之一的地址。即时消息传送服务接着存储一组Vcard，其也包含地址信息。在数据联合环境中，有可能发生下述情况，当地址簿条目的地址将要发生改变时，即时消息传送服务中的相应Vcard也被更新。

该思想是使用元数据令转换的生成自动化，以便将与web服务相关联的XML文档映射到另一语义相同的web服务中。

有各种不同类型的元数据可以辅助这一自动化：描述公共web服务接口的WSDL文档列出了该接口上支持的所有方法。当这些方法是强类型(strongly typed)的时候，对应于该方法属性/自变量的数据模型可以从WSDL规范中自动提取。可选地，管理员/集成者/服务提供商可以提供诸如部署描述符之类的附加配置文件，进一步详述web服务的行为。

通过web服务揭露到本体描述(ontology description)的数据分类可以被看作另一种类型的元数据，促进不同命名但语义相关的数据字段的映射。本体描述通常采取定义类及其关系的分类法的形式。如果目标、属性、方法及其自变量、数据模型字段等术语指向定义了同等关系的特定本体即上下文，则可以解析这些术语的意义。

例如最后可以提供接口的语义描述，以表示方法是执行只读操作还是读写操作。

附图说明

通过附图具体地描述本发明，其中图1和图2示出了根据本发明的配置。

图3示出了根据本发明的数据联合方法。

图4和图5示出了根据本发明的发现服务的高级架构。

图6示出了根据本发明的发现服务所存储的发现的服务网络。

图7至图10示出了所发现的服务网络的信息如何能够促进服务调用。

图11示出了关于服务的信息如何与根据本发明的数据联合方法结合。

具体实施方式

图1所示的是基本情形。在图中，两个服务1103和1104已经部署在服务基础设施1500上。因此，发现服务1106已经在其知识库1206和元数据库1207中具有关于服务1103和1104的数据模型的信息。还假定图中所有三个服务1103、1104和1105具有重叠的数据模型1202、1203和1204。因此转换功能1200已经由系统推导出并且该转换功能已经部署在转换引擎1102上。

该情形继续：将另一服务1105部署在服务基础设施1500上。管理员在服务基础设施1500上部署新的服务1105。

因此，管理员向管理工具1107提供该服务的WSDL接口以及对应于该服务实施的包。管理工具1107向发现服务1106发送请求1400。发现服务解析WSDL接口并从文档中提取数据模型。

数据模型包括对应于在WSDL接口上定义的方法的数据结构以及方法自变量数据结构，其在WSDL文档中被描述为XML模式。该数据模型存储在元数据库1207中。

发现服务1106在其知识库1206中进行查询，知识库1206包含对在前一服务部署期间在模型中插入的数据结构等的本体和/或语义定义，即，当部署时，服务1103或1104试图解析新服务数据模型与其之前已经发现的数据模型之间的任何依赖和关系.

当新的数据结构或这些数据结构中的特定字段保持未解析时，即不能关联到任何已有本体时，请求1401操作者通过管理工具1107提供对它们的另外的本体描述。

管理工具回复1402以新的关联。它们被发现服务1106存储在知识库1206中。

当所有数据结构和字段都已经被分类后，推理器1205搜索数据结构之间的关系。这是一种类型推断机制。

对于这样一种关系，系统试图基于之前发现的合成数据结构的单个字段之间的关系自动地构建映射功能。

可能需要一个手动确认步骤，以确保自动地生成的映射是正确的。此外，不能容易地由XSLT脚本处理或需要从外部系统诸如属性提供商处获得另外的信息的复杂的映射情形可能需要手动干预。

当不能自动地完全解析关系时，可能会再次请求1401操作者提供映射。该映射被存储在发现服务1106的知识库1206中。

相关联的映射功能部署1403在转换引擎1102中，以便其作为服务基础设施中的服务1201变得可用，通过该服务，消息应当被路由，以便相应地被转换。

随着发现单个数据结构字段之间的越来越多的关系，未来的服务部署将能够从这些信息中获益，以便处理变得越来越自动化。

图2示出了一种运行时情形，其中消息2400被客户端应用或另一服务2100发送给服务A 2103。该消息对应于请求更新服务A 2103的数据库2202中存储的数据记录的请求。该情形还假定服务B 2104和服务C 2105都在它们各自的数据库2203和2204中共享由消息2400更新的数据。

所有的服务2103、2104和2105连接到服务基础设施2500。其可以是企业服务总线或等效的消息代理。服务基础设施包含基于内容的路由器2101，通过该路由器所有预定部署在服务基础设施2500上的服务2103、2104和2105的请求被转换和路由。

在从客户端2100接收到消息2400后，基于内容的路由器2101在如图中箭头2402所示将消息2400路由给它的原拟目的地(服务2103)之前首先查询发现服务2106以查看其他服务是否受到与消息2400相关联的更新操作的影响。

在该示例性情形中，发现服务2106响应以两条路由：一条路由经由第一转换功能2200通向目标服务2104，并且一条路由经由第二转换功能2201通向目标服务2105。每个转换功能将原始消息2400转换为等效的消息，即具有引起对受影响的服务2104和2105的数据库2203和2204中的共享数据的相同更新的效果的消息，其符合每个受影响的服务2104和2105所暴露的接口，如箭头2404和2406分别所示。

基于内容的路由器2101从发现服务2106接收路由，首先将原始消息2400转发给他原始拟到达的目标服务2103，如箭头2402所示。然后，基于内容的路由器2101处理该第一路由，首先如箭头2403所示，将消息2400发送给第一转换功能2200，并且接下来如箭头2404所示将结果即转换后的消息发送给服务B 2104。最后，基于内容的路由器2101处理第二路由，首先如箭头2405所示，将消息2400发送给第二转换功能2201，并且接下来将结果即转换后的消息发送给服务C 2105。

服务2104和2105都执行分别与消息2404和2406相关联的逻辑，即它们分别更新它们的数据存储2203和2204。

本发明具有重要性的另一领域是SCA兼容(服务组件架构)服务环境，参考图3，其中服务/组件3100、3101、3102和3103声明(declare)入口3300、3301、3302，即它们期望另一组件提供的接口，以及出口3200、3201、3202和3203，即组件自己提供给其他组件的接口，并且其中入口3300、3301和3302链接/绑定3400、3401和3402到出口3200、3201、3202和3203，以便构成提供特定功能性的新组件/服务。

至少一个转换功能(包括其等同体)3500、3501和3502与链接/绑定3400、3401和3402相关联。

在ESB环境的上下文中，专用的联合数据管理器(FDM)可以显著地有助于实现该数据联合模型。概念上，FDM可以被认为由发现服务、获取服务以及供应服务所构成。

发现意指对总线上可用数据进行定位并维护代表该数据的模型，获取或询问是支持对不同服务和数据模型进行搜索的集成询问，并且供应是基于总线上已经可用的数据为新注册的服务提供数据。

FDM还可以用于同步，即，使类似的数据保持一致状态。

由UDDI提供的传统的服务发现，使得企业发布服务列表并从其他企业发现服务。在注册中心中可用的元数据适合于描述和搜索服务。即使已经增加了语义表示，其仍然是有限的，并且主要有关于企业、协议和标准分类。

在数据驱动服务的视角，该发现功能性是不充分的。本发明的贡献在于分析数据驱动服务发现的需求以及呈现这些高级发现服务的综合模型。

图4中示出了FDM Reg。发现服务Dis可以被看做FDM的一部分。其负责发现和定位服务以及基于这些服务的数据模型来发现和定位它们的数据利用率。特定服务的数据模型必须基于它的接口。发现服务应当检查服务的接口(或用于此用途的任何其他规范)并从该描述中推导数据模型。

对于数据驱动服务发现，必须定义数据类型之间的关系以便支持不同服务的数据模型的集成。无论何时新服务注册到发现服务，发现服务都将更新数据模型并发现和实例化新关系。

作为扩展，元数据可以用于这些数据类型和关系以增加对导致更多语义数据发现的分类模型的支持，即在元级别上讨论例如以定位处理多媒体内容的服务而不是仅仅查找类似于电影或书籍之类的内容。

关于FDM服务仲裁，发现服务必须了解相关数据类型之间的语义差异。例如，地址簿服务所使用的地址信息的格式可能不同于即时消息服务，不同之处在于：数据字段存储的顺序，或者在一种类型中信息表示为单独数据字段而在另一种类型中表示为综合字段。

因此，除了不同数据类型之间的关系之外，发现服务还应当优选地结合如何转换这些数据类型的知识。这可以通过将每种数据关系与(如何利用)转换服务(的知识)相关联来获得，转换服务能够基于关系是否是单向的而将关系中的一种数据类型转换成另一种并且反之亦然。

发现服务能够浏览得到的数据模型并推导出如何使用这些转换通过服务的数据类型将一个服务映射到另一个服务。在此上下文中，术语路由还用于这样的映射。这些路由的基本使用是对结合的服务之间的数据进行自动的同步Sy。

总之，这种数据库发现包括三个主要活动：

-从注册服务的接口中提取数据模型；

-将提取的数据模型关联到注册中心中存储的数据模型；

-查询所存储的数据模型以基于服务的数据模型来发现服务。

当新服务在发现服务处注册时，将检查该服务的接口并将提取数据模型。基于接口的性质以及该接口上的数据部分的重要性，存在多种情形。

最困难的情况-并且目前由于这样一种数据联合尚未应用因此也是最常见的情况-是从未使用数据联合的服务中提取数据模型。接口上数据部分的重要性较小并且发现服务能够提取的信息相当有限。

例如，WSDL描述通常只包括对在服务的操作的输入或输出上使用的数据类型的基本描述。对于数据驱动服务更适合的是具有单独数据接口的接口，更详细地描述数据类型以及不同数据类型如何能够被读或被写，即，通过使用共同访问操作而被处理。

用于JavaBeans组件的属性的获得者(getter)和设置者(setter)是这种访问操作的好例子。在最理想的情况下，数据类型也被语义地描述，例如使用内嵌(in-lined)的Web本体语言(OWL)、构造(construct)，或使用单独的OWL文件，将这些类型关联到其他已知类型或将它们集成在共同或标准本体中。

将服务的数据模型集成在目前存储的数据模型中使得在新的和已存在的数据类型之间进行区分并且识别新数据类型和之前已知的数据类型之间的关系。

当信息从接口中提取出来时越详细，在目前存储的数据类型中集成新数据类型的发生就越有意义。在此影响因素是使用明确的类型。例如，如果某个服务的所有数据使用字符串来建模，则发现服务将不能推导出很多与其他服务的数据类型的有意义的关系。接口中语义的程度越高，集成可以越自动化地执行。如果新的数据类型在不参考或不关联其它类型的情况下独立的定义，则接下来不可能完全自动化地集成这些类型。在此情况下，将新类型关联到已存储的数据类型需要例如由发现管理员所提供的全局知识。

然而，如果接口中存在语义信息，则可以通过对注册中心和接口中存在的语义信息进行推理而发生集成。更有可能的，这种语义信息将以对标准或共同本体的参考的形式获得。在此情况下，发现服务可以直接从该本体中提取正确的关系。

为使发现服务能够通过数据模型搜索相关服务，需要某些规则来定义数据模型级别上的哪些关系可以引入服务级别上的关系。

例如，可以将特定操作S的一组语义相关操作定义为操作之间的关系R的传递闭包。如果操作X的输入与操作Y的输入重叠则X与Y相关。在某种程度上这可能是输入类型是输入的子类型或一部分的情况。

更实际的方法，可能包括关系isTransfomableTo，其只意味着存在从一种数据类型到另一种数据类型的转换，对于isTransfomableTo、其关系子类型和其一部分中的每一个存在与转换服务之间的关联。

于是，相关操作的上述定义规定从一种数据类型或操作到另一总数据类型或操作的一系列转换。这一系列操作实际上是一种路由，其用于数据联合管理器中的服务之间的自动同步。

对于地址簿和即时消息器的情况的例子，可能存在经由将UpdateAddress映射到Address数据类型、将Address数据类型映射到在VCard数据类型中的所用地址类型的转换并从此处经由VCard到updateVCard的从UpdateAddress操作到UpdateVCard操作的路由。

对于实际的实施，需要数据描述和数据发现技术二者。在不需要任何进一步集成的情况下，例如可以使用WSDL和OWL二者。也就是说，OWL可以同样地在WSDL规范中使用，或者其可以用作单独的规范文件。关于数据发现技术，例如可以选择UDDI上的ebXML，因为它可以提供表达能力强得多的数据模型和询问应用编程器接口。

ebXML可以用作用于电子商务组织的一组规范，发现是其一部分，ebXML所用的注册中心包括注册库(registry)和储存库(repository)。储存库能够存储任何类型的电子内容，而注册库能够存储描述该内容的元数据。储存库中的内容称作“储存库项”，而注册库中的元数据称作“注册库对象”。

ebXML注册中心定义了注册信息模型(RIM)，其规定了可以被提交给注册中心的标准元数据。该信息模型的主要特征包括：

-RegistryObject：ebRIM中的最高级别的类是RegistryObject。这是模型中大多数类使用的抽象基本类。其为注册库对象提供最少的元数据。

-Classification：使用ClassificationScheme和ClassificationNode可以对任何RegistryObject进行分类，ClassificationScheme和ClassificationNode代表各个类分级元素。ClassificationScheme定义构成ClassificationNode的树结构。ClassificationScheme可以是用户定义的。

-Association：使用Association实例可以将任何RegistryObject与任何其它的RegistryObject相关联，其中一个对象是Association实例的sourceObject并且另一个是targetObject。Association实例可以具有associationType，其定义该关联的性质。存在注册中心必须支持以成为ebXML兼容的多个预定义的Association Type。ebXML允许该列表被扩展。

-Service Description，ServiceBinding和SpecificationLink类提供定义包括WSDL的服务描述的能力。ebXML输出两个用以使用注册中心的接口。

-Life-CycleManager(LCM)负责所有对象的生命周期管理请求。

-QueryManager(QM)负责处理所有的询问请求。客户端使用此服务定义的操作来询问注册中心和发现对象。

ebXML询问服务充分地利用该数据模型，所有的信息可以被用于搜索注册中心中的项目，例如与某个项目相关联的所有RegistryObject或与利用某个ClassificationNode分类的所有服务项。为了增强ebXML注册中心中的数据分类模型使其具有语义关系，可以使用ebXML中可用的构造。ebXML注册信息模型可以用于仿真对数据类的OWL描述。

已经定义了一种架构，用于使用ebXML作为骨干组件的数据发现服务原型。

图5示出了该架构的高级组件视图。其包括3个组件D，QF和EB。发现组件D提供三个接口LC、Q、A，它们由其它FDM服务使用。生命周期接口LC用于注册服务的生命周期管理。其可以由系统管理员用来定制、发布和激活新服务。该组件基于描述将服务信息存储在注册中心中并提出服务的数据模型以及与注册中心中其它数据类型的关系。该接口还包含用于解析和存储所提出的数据关系的操作。管理接口A用于维护注册中心上的操作。

系统管理员将使用它进行维护，尤其是对数据模型和它们之间的关系进行维护。询问接口Q用于搜索注册中心中存储的信息。它提供一种特殊操作，主要由同步服务使用来查找到相关服务的路由，并提供一种通用操作，用于类似于在ebXML标准中定义的询问的结构化询问语言(SQL)。ebXML组件EB是完全兼容ebXML标准的注册中心和发现服务。其可以被发现组件D和第三方客户端使用。前者将利用它作为注册中心，存储可用服务和它们的数据模型，包括这些模型之间的关系以及相关联的转换；而后者可以利用它作为传统的发现服务。QueryFacade组件QF可以处理递归询问，例如用以搜索传递关系。该组件是必需的，因为ebXML标准规范不包括这种功能性。

发现组件的接口Q、A和LC主要使用WSDL和OWL格式作为输入和输出，但是内部的，发现注册中心基于ebXML格式。数据模型的提取由此将涉及到将WSDL和OWL转换为ebRIM和ebRS公开格式。

服务可以利用Service类表示并且来自WSDL的信息的其余部分以ServiceBinding和SpecificationLink类的形式获得。服务所用的数据模型被映射到ClassificationScheme，其中每个ClassificationNode代表数据模型中的一种类型并且与使用Classification的服务相关联。

例如，上述地址簿服务可以被存储在ebXML注册中心中。服务被分为两种数据类型，一种用于改变地址信息，另一种用于在地址簿上添加新的条目。使这些类型包括地址类型、个人类型和字符串。

作为在注册中心中发布的新服务，新的数据模型元素应当被插入到注册中心中并且服务的数据模型应当与已经存储在注册中心中的数据类型相关联。发现服务可能不能完全自动地完成后一种操作。则它可以推导一组建议的数据类型关系，其例如由系统管理员最后确定。

一些有关于关联的简化可以基于数据类型之间的完全等效，例如当类型在注册中心中已经可用时，其服务特定的关系将必须也添加到注册中心中。为了使这种推论合理和完整，系统管理员可以通过在WSDL公开中嵌入OWL构造将服务描述扩展为具有语义数据信息。

为了搜索不同服务的操作之间的路由的模型，可以使用Floyd-Warshal类算法，或一对最短路径发现，即来自Dijkstra搜索类型的算法。

图6示出了服务网络的更抽象的表示。如上所述，服务对应于箭头T所示的功能。服务形成箭头T的种类，其中服务T具有输入和输出数据类型D。这些类型定义服务，并且反之亦然。为了两个服务之间的级联，类型必须一致，即类型必须至少通过能够从语义级别上的类型的元信息得出的转换功能而匹配。对圆点(bullet)仔细观察会发现该类型形成在应用于上述数据模型的概括实现中的数据表现的等效类。

图7示出了级联的情形，即具有适当的即兼容的接口的服务的连续调用。存在描述为虚线的结果(级联的)服务的输入类型S和输出类型E。该(虚拟)服务包括三个真实的服务。

服务以箭头的种类的形式被级联。一系列级联的调用对应于具有开始S和结束E的曲线图(粗体)中的路径。约束在于数据类型需要是一致的，即第N个箭头结束于一个圆点，在该圆点第N+1个箭头开始。该路径对应于具有输入类型S和输出类型E(虚线)的(虚拟)服务。

根据本发明的发现服务感知图6中所示出的服务网络。发现服务X存储对如图8所示的服务网络的映射。客户端C可以询问S？E例如，是否存在输入数据类型S和输出数据类型E定义的服务。询问用客户端c和发现服务X之间的连接来表示。

在图9中，示出了如何发现通过服务网络的路由。发现服务X必须识别其映射中的输入数据类型S和输出数据类型E，并且该服务必须识别映射中相应的点(或等效类)的数据类型，即数据模型之间的连接。这是服务T1、T2和T3的路径，或者总的来说是一组路径。该信息，即路由信息(可选地包括用于类型变换的数据转换)被回复给客户端C。

如图10所示，这使得客户端调用由此路径定义的服务链。通过输入调用(IT1)第一服务T1，通过该调用的结果调用(IT2)第二服务T2，并且最后调用第三服务T3，产生所提供的输出类型E的结果。

总结来看：寻求具有输入数据类型S和输出数据类型E的服务的客户端C可以问询专用服务X关于提供所搜索的服务的一系列服务调用。专用服务X可以在其存储器中查找数据类型并可以例如经由Dijkstra的算法或借助于经由Foyd-Warshal算法的传递闭包来计算路径。这使得客户端可以以级联的方式调用服务。

图11示出了如何能够(递增地)创建发现服务中存储的映射。假定，开始于图6所示的(已经发现的)服务网络，新的服务S必须被注册。这用虚箭头示出。该服务具有输入数据类型DS和输出数据类型DE。查找说明输入数据类型DS相当地新，即未知，但是从语义描述中可以得到已知数据类型与该新数据类型之间的转换。这通过在映射中创建新的圆点和新的箭头来记录。在本例中输出数据类型DE可以被识别为已知数据类型。这用点画圆示出。通过集成直接连接数据类型DS和DE的箭头来完成映射。最后，上述的发现服务具有这些服务、数据类型和数据类型转换的一致和整体的图形(模型)。

该技术实现了一种用于调整在例如面向服务的架构中的用户服务与多个提供商服务之间交换的消息的配置，其中该配置包括发现服务，其包括存储装置，用于区分服务数据模型，每种服务数据模型与提供商服务相关联，并且存储装置用于存储所述服务数据模型之间的关系。这实现了发现消息路由，每个提供商服务一个消息路由，每个消息路由被定义为一系列零个或多个服务调用，可选地具有与数据模型关系相关联的转换。发现装置能够将所述用户服务的消息调整到通向指定提供商服务的消息路由中。优选地，发现装置能够将作为最后的提供商服务的所述用户服务的消息包括在所述一系列消息路由中。

该发现装置还可以包括推理器(2205)，其适应于支持基于之前建立的关系对服务数据模型之间的新关系进行的自动推导。发现装置可以适用于基于在所述用户服务和所述指定的提供商服务之间交换的所述消息的影响自动地确定至少一个附加目标提供商服务，具有关于其它提供商服务的服务数据模型的信息以便支持提供商服务之间共享的数据的同步。

Claims (7)

1.一种用于调用所请求服务的设备，所述设备包括：

-用于通过发现至少一个服务的数据模型来获取对应于所请求服务的服务并调用所获取的服务的装置，

-用于提前获取所述数据模型中的多个服务的路径的装置，其中服务的级联对应于所请求服务，以及

-用于连续地调用所述路径上的服务的装置，

所述设备还包括：

-用于存储服务的数据模型之间的关系的装置；

-用于基于相关的数据模型来合成服务的装置；以及

-用于在具有重叠数据模型的服务之间进行同步的同步装置。

2.根据权利要求1所述的设备，其中所述设备适合于将数据类型的转换关联到关系。

3.根据权利要求1所述的设备，还包括推理装置，其适合于支持基于先前建立的关系和对服务的语义描述来自动推导服务数据模型之间的新关系。

4.根据权利要求1所述的设备，其中所述同步装置还用于基于所述至少一个服务的数据模型以及所述数据模型之间的关系自动识别冗余数据。

5.一种用于调用所请求服务的方法，所述方法包括：

-通过发现至少一个服务的数据模型来获取对应于所请求服务的服务并调用所获取的服务，

-提前获取所述数据模型中的多个服务的路径，其中服务的级联对应于所请求服务，以及

-连续地调用所述路径上的服务，

所述方法还包括：

-存储服务的数据模型之间的关系；

-基于相关的数据模型来合成服务；以及

-在具有重叠数据模型的服务之间进行同步。

6.根据权利要求5所述的方法，包括步骤：

获取用于在所述级联中校准接口的转换方法。

7.一种服务器主机，包括根据权利要求1所述的用于调用所请求服务的设备。

Images