CN1745394A - 万维网服务合同选择 - Google Patents

Abstract

本发明涉及连网计算机远程通信的领域，尤其涉及用于处理为诸如万维网服务那样通过网络提供的服务定义服务请求者和服务提供者之间的合同的合同数据的方法和系统。为了在在服务提供者和服务消费者之间存在众多有效合同的情况下提高万维网服务的处理，建议使所述合同数据包括(1300)到所述服务的请求中，以便使服务提供者能够评估(1330)所述众多有效合同和从所述众多有效合同当中选择(1340)一份具体合同，从而最大程度地满足消费者的需要。

Description

万维网服务合同选择

1.发明背景

1.1.技术领域

本发明涉及连网计算机远程通信的领域，尤其涉及处理为诸如万维网服务那样通过网络提供的服务定义服务请求者和服务提供者之间的合同的合同数据的方法和系统。

1.2.现有技术描述和缺点

1.2.1.介绍

万维网服务定义用于描述要访问的软件部件的技术、访问这些部件的方法、和能够使相关服务提供者得到识别的发现方法。万维网服务是中性编程语言、编程模型、和系统软件。

两种现有技术万维网服务标准与这一点有关。为了引入现有技术存在的问题，下面对它们作简要叙述和评论。

首先，简单对象访问协议(SOAP)提供了在服务提供者和服务请求者之间传送消息的手段。SOAP独立于底层传输协议，SOAP有效负载可以在HTTP(超文本传输协议)、FTP(文件传输协议)、JMS(日本测量标准)和其它协议上传送。

图1给出了通过HTTP POST请求传送的SOAP例子。

HTTP消息包括从客户机到服务器的请求和从服务器到客户机的响应。这两种类型的消息(请求和响应消息)包括开始行、零个或更多个首标字段(也称为“首标”)、指示首标字段结束的空行、和消息正文(可能有)。

HTTP请求消息的结构描绘在图2中：那个消息的第1行指定要应用于资源的方法、资源的标识符、和使用中的HTTP协议版本。HTTP协议定义像GET、HEAD、POST、PUT、DELETE、TRACE、CONNECT、OPTIONS那样的多种请求方法。该方法表示对资源进行的操作。

对其应用请求的资源通过Requst-URI标识，Requst-URI是统一资源标识符。统一资源标识符是简单格式化字符串，它通过名称、位置、地址或任何其它特征标识资源。例如：用于通过HTTP协议定位网络资源的众所周知HTTP URL(统一资源定位符)方案包括resource-URI。有关http URL的方案专用语法和语义是http-URL＝″http:″″∥″host[″：″port][request-uri]。如果端口是空的或没有给出，则假设端口是80。语义是位于监听在那个主机的那个端口上的TCP(传输控制协议)连接的服务器上的标识的资源，并且Requst-URI标识资源。有关Requst-URI的语法和语义是：Requst-uri＝abs-path[″？″query-string]，其中，abs-path是资源的标识符，和query string是可以用于处理请求的任何类型信息。

首标字段携带与请求或响应相联系的元信息。

HTTP消息的消息正文用于携带与请求或响应相联系的实体。

在图2中描绘的消息正文包含实际SOAP消息，它具有如图3给出的结构：在封套部分内部，定义了数个首标字段1，…，n，它构成所谓的SOAP首标，后面接着实际的SOAP正文，它包括第二数个的所谓“正文字段1，…，n”。

因此，在图4中，例如，通过像HTTP那样的传输协议在网络上传送的SOAP消息的总体结构被描绘成图1到3的混合。

图1给出了通过HTTP POST命令传送的SOAP例子。HTTP请求方法是POST，resource-URI是″/StockQutoe″，它是用于标识请求打算使用的资源的绝对路径。resource-URI不包含询问字符串。

除了SOAP之外，在现有技术中还存在上述第二相关万维网服务标准：万维网服务描述语言(WSDL)是将万维网服务描述成对包含面向文档有效负载或远程过程调用(RPC)有效负载的消息的一组端点(endpoint)操作的XML(可扩充标记语言)文档。根据消息结构和一系列简单消息交换(或在WSDL术语体系中，“操作”)的术语抽象定义所谓的服务接口。然后，将它们绑定到具体网络协议和数据编码格式来定义端点。将相关具体端点结合在一起来定义抽象端点(服务)。

WSDL支持与用于服务调用的协议绑定不同的服务接口定义。WSDL允许多种绑定用于单个服务。服务接口定义和访问绑定也与服务的功能的实现不同。服务请求者通常从相应WSDL中为万维网服务生成客户机存根(stub)码；服务的WSDL通常是向服务提供者请求的。客户机存根码实现必要逻辑，以创建正确的消息结构和编码成寻址端点的正确数据。由于在服务的定义、绑定和实现之间存在差异，为某种定义和绑定创建的客户机存根码通常不用要求代码改变，仅仅使用另一个端点地址就可以寻址各种各样的端点。给出图5A和它的续部图5B是为了向本领域普通技术人员公开更详细的示范性WSDL文档。

万维网服务的重要特征是，根据请求-响应方案，它们是无状态的。无状态服务器是一种将每个请求当作与任何以前请求无关的独立交易来对等的服务器。这简化了服务器设计，这是因为如果客户机在交易中途死机了，无需分配存储器来处理正在进行的会话或担心释放它。缺点是可能有必要在每个请求中包括更多的信息和服务器每次都需要解释这个额外信息。

上面已经描述了上述类型的电子通信运行的制约，下面接着描述现有技术的缺点：

万维网服务的商业使用基于在服务提供者和服务请求者之间订立的合同。这样的合同代表有关使用和提供万维网服务或万维网应用的条件的协议。合同细节可以规定支付服务的条件，即，价格、以更详细方式规定所需服务质量的服务级别、和对服务请求者和服务提供者两者来说至关重要的进一步信息。基本上，在现有技术的买卖中，对合同范围或合同数量没有什么限制：一份合同可以包含多个服务，或一个服务可以包含在同时有效的多份合同中。

在现有技术的典型情形中，双方，即，这里称为SC的服务请求者或服务消费者，和这里称为SP的服务提供者相互通信，或三方，即，服务请求者、管理上面合同的服务提供者、和这里称为SS的服务供应者，形成万维网服务通信，服务供应者实际履行服务，有时将它隐藏起来使请求者看不见。

因此经过精心制作以阐明上述万维网服务设施的这样现有技术的唯一公开文本公布在www.alphaworks.com网站中在2002年有60天试用期的“IBMWeb Services Toolkit”和“Emerging Technologies Toolkit”中。

下面给出在那里公开的、称为“合同服务”和包括与本发明有关的大多数技术特征的软件部件的简要回顾：

合同服务管理服务提供者和服务请求者之间的关系。它提供有关服务提供者和服务中枢之间的合同(部署合同，也称为提供者合同)和服务中枢之间的合同(使用合同)的类型的信息。使用合同可以用于订购通过服务中枢提供的任何服务的操作的任何组合。使用合同包含诸如如何收取对服务操作的调用的费用(按时间、按使用次数、或按使用量等)、和那个客户机应该为订购的服务操作支付多少之类的信息。对于每份使用合同，合同服务都定义要使用的支付方法和定价模型、和那份合同的有效期。合同可以可选地存储双方(服务中枢和服务提供者/请求者)对合同的数字签名。在借助于WebServices Toolkit发货的Utility Service演示程序中，通过供给演示程序的Utility Services Portal将合同加入合同服务中，和有效合同在请求者可以使用服务之前必须位于服务中枢和服务请求者之间的地方。

合同服务支持像如下那样的WSDL定义操作：

·createContract  用于创建合同；

·getContractModel  用于读取合同模型；

·getContractState  用于读取合同的当前状态；

·updateContractState  用于更新合同的当前状态；

·getContractType用于读取合同的类型；

·setContractProperty用于设置合同的属性；

·getContractProperty用于读取合同的属性；

·getUsageContractForValidForIdentity用于检索对于给定服务消费者来说有效的使用合同。

当服务请求现在到达服务器时，如上所述的合同服务在执行请求之前，检验与服务请求有关的合同。只要存在唯一合同和可以以不用区分多级服务质量的单一方式进行基本服务，就可以没有任何进一步问题地提供服务。

但是，由于万维网服务的提供和使用稳定增加，那些万维网服务被划分成各个服务提供者提供它们的各种各样质量级别。例如，服务可以非常快速地提供，与较长“服务提供时间”相比，这使服务更加昂贵。或者，服务给出的信息或多或少经过精心制作的，因此，或多或少给予服务请求者一些细节，例如，经济信息系统的各自改变内容。因此，多份相关合同或合同的属性在服务提供者和服务请求者之间是有效的并绑定在一起的。在这种状况下，比如说，如果多份合同或合同的属性是相关的和有效的，在单份合同规定用于不同服务质量级别的数个相关合同属性的情况下，上述合同服务必须选择用于请求的实际合同或使用实际合同属性。然后，所选合同或合同属性规定当前服务请求的当前条件，例如，如上所述，操作的价格。

由于在网络上发送的请求不包含任何类型的合同规定，或合同相关信息，在现有技术中服务请求者方的客户机在这样的多合同状况下不能选择用于特定服务请求的实际合同，该客户机也不能影响选择的过程。换句话说：在现有技术中提供请求和对请求者有效的确切条件由外方，即，由服务提供者选择。这个缺点尤其基于这样的事实：像UDDI、WSIL、WSDL、SOAP那样的现有万维网服务协议标准不考虑为操作或服务请求选择合同的任何方法。

这个问题得不到满足处理意味着服务提供者选择实际合同或实际合同属性，而请求者对所述选择没有影响，或使用复杂的服务结构，这种复杂的服务结构被组织成对于相同服务的每个微小质量级别，都必须定义单独的合同，因此，同一个服务在逻辑上和在形式上被分成数个相关服务。但是，这种情况使服务消费者的人机界面复杂化和难以使用。

1.3.发明目的

因此，本发明的目的是提供对基于权利要求1的前言的方法的各种改进，和消除或至少减经了上述缺点的、实施该方法的相关系统。

2.本发明概述和优点

本发明的这个目的是通过在所附独立权利要求中陈述的特征达到的。并且，在各自从属权利要求中阐述了本发明的有益安排和实施例。现在应该参考所附的权利要求书。

根据本发明的基本方面，如权利要求1的前言定义的方法通过将指定给定服务规定的选择的合同数据包括到请求服务的请求中的步骤得到改进。

通过本发明的这种一般特征，可以容易地实现驻留在服务提供者方的合同服务软件部件，以便它可以从请求中提取这样的合同数据和根据预定规则评估它，使服务提供者能够正确地提供服务请求者借助于上述合同数据请求的那种服务质量。

根据本发明的优选特征，通过驻留在客户机方和服务器方两者上并包括所述合同数据的相关软件接口处理所述合同数据，其中，所述接口包括使用之中的传输协议、使用之中的消息传送协议和对使用之中的相关端口类型的各自定义。当然，由于服务可能因随着时间的进一步发展而发生变化，必须根据这样服务的各自当前类型和版本编程和管理这样的软件接口。

并且，根据本发明的进一步优选方面，可以在万维网服务请求消息的首标字段内处理所述合同数据。

在这种情况下，请求-评估软件部件当然必须据此提取这样的首标字段内容，这要求分别对它们加以编程。

根据本发明的最优选方面，所述合同数据组成相关服务请求的端点规定的一部分并被当作相关服务请求的端点规定的一部分来处理。这种特征限定了在可以没有任何改变地使用现有万维网服务协议和基础设施的时候，使客户机和服务请求者能够为服务请求选择一份或多份合同的方式。

构成服务请求和由客户机发送到服务器的消息本身因此包含服务器用于选择一份或多份合同的信息。

并且，合同选择参数基本上可以引用合同的内容或仅仅标识特定合同的元数据。

当像如下那样直接阐明服务质量时，例如，当像如下那样示范性地定义服务执行条件或服务内容条件时，引用内容：

a)服务价格＜固定价格上限，例如，10美元，或

b)响应时间小于等于0.5秒，或

c)服务的可用性大于90％，或

d)其它准则，例如，至于像一方面，摘要信息，或另一方面，详细报告那样阐明所提供服务的复杂性。

例如，当根据唯一ID规定合同时，在上面的意义上有关合同元数据的例子是由数个(例如，30个)标识字符组成。

还应该注意到，根据本发明的优选方面，还可以由服务消费者(请求者)规定或还可以由服务提供者提供上述合同选择准则的组合。

一个例子是与上面a)和b)或a)和c)的要求结合在一起的指定合同ID“hhffkk-rrssooll-ooddggjj-idghwelf-oodbmmss”的请求。

正如所附权利要求书所揭示的那样，可以将本发明当作请求者和提供者间分布式软件/硬件系统，其中，尤其，提供者方还可以划分成如上面提到服务器提供者(也称为服务中枢)和服务供应者那样的两个或更多个分立机构。由于所述分布式性质，对服务器部分和客户机部分分别存在特殊要求。这还包括在位于提供者处或请求者处的多于一个硬件系统上分配本发明功能的可能性。例如，可以部分或全部地在被安排成网关部件的截取计算机中实现本发明方法的相应请求者处或提供者处步骤，网关部件被集成在在将输入消息实际转发给包括实际相关数据库应用程序的专用服务器系统之前截取和处理输入消息的企业防火墙概念中。

本发明的主要优点是使客户机能够选择合同，以及因此所需服务的条件。由于指定合同选择的参数是构成服务请求的请求消息的组成部分，本发明还适用于无状态万维网服务。

本发明使用和支持现有标准万维网服务协议。根据本发明的最优选实施例，本发明不要求扩充现有万维网服务基础设施，并且对于万维网服务基础设施和服务实现两者都是透明的。因此，本发明相当好地适用于像，例如，.NET和JAVA万维网服务那样的异构环境。因此，在将合同数据当作作为这里提到的最优选选择对象的服务请求的端点规定的一部分来处理的情况下，可以不用改变服务接口地通过网络进行基于相应各种各样合同特征和替代品的各种各样服务。在这种不需要改变服务接口(既不需要改变硬件也不需要改变软件)的情况下，通过网络发送的所有消息仍然遵从现有技术中用于构建客户代理器的标准和工具，并且仍然可以使用客户机应用程序编程接口(API)。

消息中的术语“端点”表示发送或接收消息的资源(任何类型的硬件或软件资源)。请求中的术语“端点”表示提交请求或打算接收和执行请求的资源。术语“端点规定(specification)”表示这样的资源的标识符。任何类型的端点规定表示都是可以的。通常，像HTTP-URL或request-URI那样给出端点规定。

图1包含给出为request-URI″/StockQuote″的端点规定。

对于万维网服务来说，端点是接收特定格式的消息或实现以请求和响应消息的特定格式、特定数据编码和特定网络协议为特征的特定操作的资源。端点通常通过协议级端点地址，例如，HTTP-URL或request-URI来规定。

“无状态请求”指的是请求被当作独立交易来管理和与任何其它(以前或将来)请求无关。通常，请求由服务器处理，马上返还响应，然后，删除服务器上与这个请求有关的所有信息。换句话说，服务器在处理了请求之后不保存请求的状态。

3.附图说明

下面举例说明本发明，本发明不受附图的图形形状限制，在附图中：

图1是示出包含在HTTP POST请求消息中的现有技术SOAP请求消息的代码部分表示；

图2是示出现有技术HTTP请求的结构的代码部分表示；

图3是示出现有技术SOAP消息的详细结构的代码部分表示；

图4是示出包含在HTTP POST请求消息中的现有技术SOAP消息的总体结构的代码部分表示；

图5A是示出用于描述万维网服务的现有技术示范性WSDL文档的一部分的代码部分表示；

图5B是图5A的续部；

图6是基于本发明方法的优选实施例的服务消费者、服务供应者和服务提供者之间的关系的示范性表示；

图7是用在图6中给出的情形中的主要结构单元的示意性表示；

图8是基于本发明方法的进一步优选实施例的服务消费者、服务供应者和服务提供者之间的关系的示范性表示；

图9是用在图8中给出的情形中的主要结构单元的示意性表示；和

图10是示出在根据本发明提供的优选途径执行的包括合同选择参数的消息交换中的控制流和它的相关步骤的方块图表示。

4.优选实施例

接着描述本发明方法和系统的优选实现，其中，将注意力放在本发明合同系统的运行时行为，即，处理服务请求时的行为上。

基本上，合同系统必须：

1)根据至少一份有效合同核实实际输入服务请求，和

2)为这个服务请求检索合同指定的使用条件。

根据本发明的合同系统可以支持任意合同类型；每份合同是一种合同类型的实例。不同合同类型基于相同数据模型，即，所有合同都包含状态(有效、无效或删除)、表示合同类型的符号和合同文档。这可以是XML结构，它包含单独合同数据，即，合同项，也就是服务操作、和使用它的条款和条件。合同文档的格式依赖于合同类型。

仅仅为了例示的目的，下面更详细地描述一种合同类型。

类型“使用”的合同，即，使用合同代表一个服务消费者和一个服务提供者之间的一种协议。

每份使用合同与服务消费者的具体身份相联系。在典型的情形中，合同系统在服务提供者这一侧运行，因此，服务提供者身份不明确包含在使用合同中，而是暗中给出。

服务提供者使用合同系统来保证服务消费者只能调用有效使用合同涵盖的服务操作。应该注意到，对于一种服务操作，消费者可以拥有多份有效合同。

使用合同包含合同名称、消费者，即，服务请求者的身份关键字、开始日期和结束日期。它包含规定服务操作的关键字和相关定价的关键字的一个或多个服务要素。在本例中，使用代理关键字，但依赖于实际实现，也可以使用其它类型的关键字。定价模型规定如何收取对服务操作的调用的费用(按时间、按使用次数等)、和那个消费者应该为订购的服务操作支付多少。这可从如下列表中得出：

<UsageContractDoc

                     name       ＝MyUsageContract

                     identitykey ＝313c4dbb-14aa-47c3-84b8-

01718f60116

                     startdate  ＝ 2002-7-01

00：00：00.000000000

                     enddate    ＝ 2003-7-01

00：00：00.000000000>

  <services>

     service  servicekey＝c1f2376-043a-4294-a6ef-

0c131cf2243a

              ratingkeys＝3312d44b-3163-4d42-bd5e-66d305e2914

/>

     service  servicekey＝3c01bb7-331e-4e89-8256-

3e0b0c 3b1335

              ratingkeys＝1a2fdeed-026c-47a9-be32-fb63896303d

/>

</services>

</UsageContractDoc>

除这种样本合同类型之外，这种基本结构还允许容易地加入其它合同类型。其它类型的合同可以规定服务属性，即，响应时间、可用性等的质量。

在下文中，示出了两种典型运行时情形并例示了服务消费者、服务提供者、和服务供应者之间的交互。应该注意到，如何创建所讨论的合同不在本发明的范围之内，因为在所述情形开始之前，可以通过多种方式，例如，通过“传统”书面函件订立它们，但是，假设在请求服务之前一份或多份有效合同已经准备好。

参照图6，描述简称为SS的服务供应者向简称为SC的服务消费者提供服务的情形。简称为SP的服务提供者实现包括本发明主要软件部件的合同管理基础设施的主要部分。

这导致根据本实施例，在各自程序模块中作为各方A、B和C使用的各自本发明方法的“步骤”实现的如下交互。下面像附图中描绘的那样列举这些步骤：

步骤610：SC启用服务请求，以便调用SS提供的商业服务。SS接收请求。

步骤620：SS将服务请求发送到SP，以便使用SP提供的合同系统和基础设施服务。尤其，在本例中，合同系统服务包括合同服务，和基础设施服务是计量服务和简档服务。

步骤630：SP执行请求的合同系统和基础设施服务，例如，核实有效合同是否可用，启用计量事件和将状态返还给SP。

步骤640：SS执行请求的服务并调用SP，以便生成适当的计量事件。

步骤650：SS将代表服务结果的数据发送到SC。

在图7中更详细地示出了步骤620的实现：服务提供者实现用虚线方框画出的应用程序服务器，它包含用来实现用于服务请求的运行期环境，例如，像Apche Axis那样的万维网服务运行期环境的服务器小程序71。

应用程序服务器还包含用标号72、74和76表示的多个管理器部件。这些管理器实现可以在，例如，远程服务器上作为进一步万维网服务实现的基础设施部件F-H的局部实现。管理器72、74和76提供管理与远程服务的通信所需的局部功能：

·简档管理器72使用外部简档服务，以便核实请求者的身份。

·合同管理器74使用外部合同服务，以便核实合同状态和合同有效性。

·计量管理器76生成适当的计量事件(开始事件、结束事件、特定事件、取消事件等)。

部件71、72、74和76(服务器小程序和管理器)在共享存储器环境下运行和通过共享数据通信。

下面描述基础设施服务：

简档服务(72A)基本上可以像用在上述现有技术中那样使用。

简档服务提供对像名称、地址、用户-ID等那样的用户简档信息的访问。依赖于如何实现，可以将它扩展到包括更多信息。简档服务可以用于保存、删除、和获取简档信息。

为了使其它服务正确工作，商业服务的所有用户必须拥有通过简档服务指定的简档。简档可以利用用户界面或直接编辑保存简档的XML文件来事先创建。这个简档服务可以被像Tivoli身份管理器那样的任何其它身份系统所取代。

合同服务74A实现本发明的合同概念和支持像如下那样的WSDL定义操作：

·createContract-创建合同；

·getContractModel-检索合同的信息和内容；

·getContractState-获取合同的实际状态；

·updateContractState-设置合同的状态(例如，ACTIVE、INACTIVE)；

·getUsageContractForValidForIdentity-检索对于给定服务消费者来说有效的使用合同。

计量服务76A接收如下说明的计量事件，持久存储计量事件，并且一旦请求就检索计量事件。根据这个优选实施例，计量服务可以与来自合同服务74的合同信息结合在一起使用，为使用特定服务的特定客户机生成使用报告。应该注意到，合同服务和计量服务不直接交互。

计量服务76A支持三种类型的操作：

·recordMeterEvent-保存一个计量事件；

·recordMeterEvents-保存多个计量事件；

·getMeterEvents-从计量服务中检索多个计量事件。

计量服务包含被调用的服务的服务名和操作名、和时间标记，以及用于管理请求的合同的ID。计量事件按类型改变，因此，可以存在收取服务调用的费用的各种各样方式：

·当按用于执行服务的时间量收取对服务的访问的费用时，使用开始/结束事件；

·当按访问服务的次数，或根据除了时间之外的一些其它量收取访问费用时，使用ad-hoc事件。

除了上面之外，还有两种类型的事件也可用：

a)用于取消已经发送给计量服务的事件的“取消”事件；和

b)当服务请求者没有供应事件的类型时使用的“未知”事件。

下面描述上述软件部件之间的交互：

步骤710：服务器小程序71接收服务供应者初始化的服务请求，提取消息前后关系，和将它传递给随后的管理器部件。

步骤720：消息前后关系，即，共享数据对象，经过一连串管理器部件。管理器扩展/修改消息前后关系和将它传递给该链上的下一个管理器。

步骤730：简档管理器72初始化到包括相应数据库应用程序的外部简档服务72A的服务请求，以便检验服务供应者的身份。

步骤740：简档服务72将身份检验结果返还给SP的简档管理器。

步骤750：合同管理器调用外部合同服务74A，以便识别和核实相应合同：它调用“getUsageContractForValidForIdentity”操作，并且传递从简档服务结果中取出的服务消费者身份。根据本发明，合同服务74A然后为这个身份选择一份有效合同。在现有技术中，该选择只基于服务消费者身份；应该注意到，在现有技术中，服务消费者或任何其它部件没有什么手段来影响选择，例如，规定多份可能相互冲突的有效合同之间的优先级。

步骤760：合同服务74A将合同状态和有效性返还给SP的合同管理器。如果没有发现有效合同，则指出异常情况。

步骤770：计量管理器76调用外部计量服务76A，以便生成反映商业服务调用的状态的计量事件。

步骤780：计量管理器76将更新的消息前后关系返还给服务器小程序。

步骤790：服务器小程序71在步骤790中将最初服务调用(请求)的结果返还给服务供应者。

参照图8和9，在可替代的情形中，服务提供者向服务消费者提供服务。为了完成服务请求，服务提供者向服务供应者请求服务。具体地说，在

步骤810：SC向SP请求商业服务；

步骤820：SP使用合同系统和基础设施服务来核实有效合同是否可用，启用开始计量事件，然后，向SS请求服务；

步骤830：SS进行服务和将结果返还给SP；和

步骤840：SP生成结束计量事件和将商业服务结果返还给SC。

图9示出了本发明的实现，下面将参照图9加以描述：

服务提供者实现上面参照图6和7所述的应用程序服务器。因此，下面描述主要差异：

根据这个特定实施例，服务管理器90调用服务供应者(SS)提供的外部商业服务。

部件-服务器小程序91、和管理器72、74、76和90(看图9的右边缘)再次在共享存储器环境下运行和通过共享数据通信。服务器小程序91仅具有在情形2中的具体差异造成的、与图7中如上所述的那一个的相应差异，并且保证以正确的顺序调用管理器。

商业万维网服务92是服务供应者提供的外部服务器部件；在步骤910中调用它，以便完成所请求的服务调用。

这些部件之间的交互如下：

步骤910：服务器小程序91接收服务消费者(SC)初始化的服务请求，提取消息前后关系和将它传递给随后的管理器部件。

步骤720到770-参见上面供参考的情形1。

步骤980：服务管理器90调用请求的商业服务92和用所得的服务响应更新消息前后关系，和在

步骤985：将它返还给服务管理器92。

步骤990：服务管理器将更新的消息前后关系返还给服务器小程序91。

步骤995：服务器小程序91将最初调用的结果返还给服务消费者。

根据本发明，和参照图10，图10例示了基于包含合同选择数据的本发明优选消息交换的逻辑，合同信息被客户机方，即服务消费者编码成服务请求的端点规定的一部分，请见步骤1300。端点是可以在服务器上调用部署的万维网服务的地址。它通常由URL组成。服务请求消息包含端点的规定。

由于没有考虑通过服务器小程序引擎、SOAP服务器或任何现有技术部件来寻求服务实现，询问字符串部分不影响消息的处理或路由。因此，最好使合同信息包括在其中。

然后，在客户机步骤1305中，将通过所述合同选择数据，例如，用作合同标识符的整数充实的SOAP请求发送到服务器方。

然后在步骤1310中，在提供者处的应用程序服务器接收请求，通过它接收合同选择信息(步骤132)，并且从请求的询问字符串估计(步骤1330)合同选择信息。通过它服务器可以确定(步骤1340)所需服务的所需合同并可以像通过合同规定数据和来自上述询问字符串的参数详述的那样调用服务。

并且，在步骤1350中，安装相应服务，生成(步骤1350)相应SOAP响应消息，和发送到在步骤1360中接收那个消息的客户机。

并且，应该注意到如下通过万维网做出合同选择的本发明概念：

合同选择参数可以涉及由像合同服务那样的万维网服务管理部件创建的、像合同标识符那样的合同元数据、或涉及合同内容。在内容相关合同选择参数中可以引用像价格、服务质量等那样合同涵盖的所有变量。可以将各种各样合同选择参数组合在一起创建有关合同选择的复杂条件。

单份或多份组合合同选择参数可以表示成符合服务请求者和服务提供者都可理解的语法的文本字符串。本发明可以与任何语法一起使用。作为一个例子，可以用基于特定XML模式的XML语言表示合同选择参数。由于XML数据是用字符串编码的，端点地址编码的本发明特征可以用于有益地将这个合同信息嵌入服务请求消息中。

在使用本发明的示范性情况中，服务请求者想要为服务请求设置价格界限。因此，他选择适当参数来表示指示价格上限的条件(″price＜$10″)并将这个参数包括在服务请求中。这个参数涉及合同的内容并通过合同ID不明确地选择合同。

在本发明的特定实施例中，这个参数可以用XML语言编码：

<contract>

  <price>

    <max>

       10

    </max>

  </price>

</contract>

有益的是，合同选择参数可以被编码成端点地址的询问字符串的一部分：

字符串：

endpoint＝address+″<contract><price><max>10</max></price></contract>″；

服务器选择对服务请求者有效和满足与给定参数相对应的条件的那些合同。

在本例，即，上面参照图6到9所述的应用程序服务器中，服务器检索有效合同的内容，根据合同条件计算假定价格，和将这个价格与价格极限相比较。从而，服务器确定众多合格合同。如果多于一份的合同合格，服务器根据可以容易加入到此为止所述的本发明概念中的任何进一步逻辑选择一个。如果没有合同合格，服务器可以指出表示错误的异常情况。

如下的伪码例子通过评估有关固定合同要素和可变合同要素的条件实现服务器逻辑。固定要素不依赖于请求的时间或内容，例子是元数据要素(例如，合同id)和固定价格。可变要素依赖于日期，或依赖于服务请求，例如，服务价格依赖于时间或请求消息中的其它输入参数。虽然有关固定要素的条件可以合并在数据库询问中，但有关可变要素的条件需要通过评估合同和计算变量来检验。

伪码开始：

从请求消息中获取合同信息；

从合同信息中获取合同选择参数(CSP)；

从CSP中获取固定和可变条件；

从数据库中选择

1)对请求者身份有效，和

2)满足固定条件的合同；

如果没有合同可用，以错误退出；

通过读取合同内容和通过动态地评估变量为每份可用合同检验可变条件；

如果多于一份的合同满足条件，那么，执行进一步的逻辑以选择一份(例如，随机选择，取第一份)；

如果没有合同满足条件，以错误退出；

伪码结束。

在合同服务中这个逻辑可以在如上所述的getUsageContractForValidForIdentity操作中或可替代地在更多的分立操作中实现。

本发明可以用硬件、软件、或硬件和软件的组合来实现。本发明可以在一个计算机系统中以集中方式实现，也可以以不同单元遍布在几个互连计算机系统上的分布方式实现。适合实施这里所述的方法的任何类型计算机系统或其它设备都是适用的。硬件和软件的典型组合可以是含有计算机程序的通用计算机系统，当装入和执行计算机程序时，计算机程序控制计算机系统，以便实施这里描述的方法。

本发明也可以嵌入计算机产品中，该计算机产品包括使这里所述的方法能够得以实现的所有特征，和当被装入计算机系统中时，能够实施这些方法。

在当前背景下的计算机程序模块或计算机程序指的是一组指令用任何语言、代码或表示法的任何表示，这些指令旨在使具有信息处理能力的系统直接或在如下之一或两者之后完成特定功能：

a)转换成另一种语言、代码或表示法；和

b)以不同内容形式再现。

Claims (12)

1.一种处理与要通过基础设施中的网络提供的服务相联系的合同数据的方法，其中，对于具有相应许多服务规定的服务，在服务提供者(SP，SS)和服务请求者(SC)之间存在数份绑定合同，其特征在于，包括如下步骤：

a)接收(710；910)包含在用来请求服务的请求中的所述合同数据，其中，所述合同数据包括从所述数份合同当中至少选择一份服务合同的合同选择参数；

b)评估(720到780；720到770，980到990)所述合同选择参数；

c)根据所述评估和进一步选择逻辑选择一份特定合同；和

d)根据所述合同提供(790；995)提供服务。

2.一种处理与要通过基础设施中的网络提供的服务相联系的合同数据的方法，其中，对于具有相应许多服务规定的服务，在服务提供者(SP)和服务请求者(SC)之间存在数份绑定合同，其特征在于，包括如下步骤：

a)创建所述合同数据，所述合同数据包括从所述数份合同当中至少选择一份服务合同的合同选择参数；

b)使所述合同数据包括到对所述服务的请求中；

c)通过网络发送(710；910)对所述服务的所述请求；

d)根据所述选择接收(790；995)服务。

3.根据权利要求1或2所述的方法，其中，通过适合包括所述合同数据的软件接口来处理所述合同数据，所述接口包括使用之中的传输协议、使用之中的消息传送协议和对使用之中的相关端口类型的各自定义。

4.根据权利要求1或2所述的方法，其中，在万维网服务请求消息的首标字段内处理所述合同数据。

5.根据权利要求1或2所述的方法，其中，所述合同数据被当作相关服务请求的端点规定的一部分来处理。

6.根据权利要求1或2所述的方法，其中，在符合SOAP标准的SOAP消息中传输所述合同选择参数。

7.根据权利要求1或2所述的方法，其中，将多个合同选择参数组合在单个服务请求中。

8.根据权利要求1或2所述的方法，其中，所述合同选择参数包括标识特定合同的元数据。

9.一种处理与要通过基础设施中的网络提供的服务相联系的合同数据的服务提供者计算机服务器系统，其中，对于具有相应许多服务规定的服务，在服务提供者(SP，SS)和服务请求者(SC)之间存在数份绑定合同，包括执行如下步骤的功能部件：

a)接收(710；910)包括到用来请求服务的请求中的所述合同数据，其中，所述合同数据包括从所述数份合同当中至少选择一份服务合同的合同选择参数；

b)评估(720到780；720到770，980到990)所述合同选择参数；

c)根据所述评估和进一步选择逻辑选择一份特定合同；和

d)根据所述合同提供(790；995)提供服务。

10.一种处理与要通过基础设施中的网络提供的服务相联系的合同数据的服务请求者计算机服务器系统，其中，对于具有相应许多服务规定的服务，在服务提供者(SP)和服务请求者(SC)之间存在数份绑定合同，包括执行如下步骤的功能部件：

a)创建所述合同数据，所述合同数据包括从所述数份合同当中至少选择一份服务合同的合同选择参数；

b)使所述合同数据包括到对所述服务的请求中；

c)通过网络发送(710；910)对所述服务的所述请求；

d)根据所述选择接收(790；995)服务。

11.一种在包括计算机程序代码部分的数据处理系统中执行的计算机程序，用于当在计算机上执行所述计算机程序代码部分时，完成根据前面权利要求1到8的任何一项所述的方法的各个步骤。

12.一种存储在包括计算机可读程序模块的计算机可用媒体上的计算机程序产品，所述计算机可读程序模块用于当在计算机上执行所述计算机程序产品时，完成根据前面权利要求1到8的任何一项所述的方法。

Images