CN1604103A

CN1604103A - 自动建立和配置许可模型和策略的方法

Info

Publication number: CN1604103A
Application number: CNA2004100476654A
Authority: CN
Inventors: 乔齐姆·布鲁克洛斯; 乔齐姆·海格莫尔; 戴尔特玛·库伯勒; 蒂莫·库斯毛尔
Original assignee: International Business Machines Corp
Current assignee: International Business Machines Corp
Priority date: 2003-09-30
Filing date: 2004-05-28
Publication date: 2005-04-06
Also published as: EP1523151A2; US20050071276A1; EP1523151A3; US11157915B2; US10521800B2; US20200043013A1

Abstract

本发明涉及联网计算机远程通信领域，尤其涉及一种用于处理与服务请求者(SC)和服务提供商(SP)之间的合同有关的服务的方法和系统，其中所述服务要通过网络来提供，其中在所述服务请求者与所述服务提供商之间规定了至少一种服务合同。为了改善Web服务的处理，将许可管理工具(75A)包含到现有技术方法中，从而与合同管理部分(74A)和服务计量部分(76A)密切配合。最好提供多个不同的许可类型供选择使用，这些许可类型还可以被组合，以便充分满足客户的需要。

Description

自动建立和配置许可模型和策略的方法

技术领域

本发明涉及联网计算机通信领域，尤其涉及一种用于处理与服务请求者(SC)和服务提供商(SP)之间的合同有关的服务的方法和系统，其中所述服务要通过网络来提供，其中在所述服务请求者与所述服务提供商之间规定了至少一个服务合同。

背景技术

Web服务规定了用于描述所要访问的软件组件的技术、用于访问这些组件的方法以及使得能识别相关服务提供商的发现方法。Web服务与编程语言、编程模型和系统软件无关。关于这一点，两种现有技术的Web服务标准是有关联的。为了说明现有技术中所关心的问题，将对它们作如下简要描述和说明：

首先，“简单对象访问协议(SOAP)”在服务提供商与服务请求者之间提供了一种传报工具。SOAP与基础传输协议无关，SOAP有效载荷可以通过HTTP、FTP、JMS以及其他协议来传送。

图1给出了通过HTTP POST请求所传送的一个SOAP例子。HTTP消息包括从客户到服务器的请求和从服务器到客户的响应。这两种消息(请求和响应消息)都包括：起始行，零个或多个标题字段(又称为“标题”)，表示标题字段结束的空行，和可能的消息主体。

HTTP请求消息的结构如图2中所示。该消息的第一行说明了要应用于该资源的方法、该资源的标识符和使用中的HTTP协议版本。HTTP协议规定了多种请求方法，如GET、HEAD、POST、PUT、DELETE、TRACE、CONNECT、OPTIONS。该方法表明对资源所要执行的操作。

对其应用请求的资源用“请求URI(即统一资源标识符)”来标识。统一资源标识符只是一些格式化字符串，它们通过名字、地点、地址或其他任意特征来标识资源。例如：通过HTTP协议用来查找网络资源的众所周知的HTTP URL方案包含有资源URI。与具体方案相关的“http URL”的语法和语义是：http_URL＝“http:”“//””host[“:”port][request-uri]。如果端口是空的或没有给出，那么假定端口80。语义是：所标识的资源位于倾听该主机的该端口上的TCP连接的服务器中，“request-URI”标识该资源。“request-URI”的语法和语义是：Request-uri＝abs_path[“？”query-string]，其中“abs_path”是资源的标识符，而“query-string”是能用于处理该请求的任意一种信息。

这些标题字段携带与该请求或响应有关的元信息。

HTTP消息的消息主体用来携带与该请求或响应有关的实体。

图2中所示的消息主体包括具有如图3中所给出的结构的实际SOAP消息。在envelope层部分中，规定了若干个标题字段1，...n，这些字段构成了所谓SOAP标题，随后是实际SOAP主体，该主体包括第二若干个所谓“主体字段1，...n”。

因此，在图4中，例如利用如HTTP的传输协议通过网络携带的SOAP消息的总结构被描述成图1至3的混合。

图1给出了通过HTTP POST命令所携带的一个SOAP例子。HTTP请求方法是POST，资源URI是“/StockQuote”，它是标识想要请求的资源的绝对路径。该资源URI不含查询字符串。

除了SOAP之外，现有技术中还有上述第二种相关的Web服务标准：

Web服务描述语言(WSDL)是一种XML文档，用于将Web服务描述成一组对含有面向文档的或远程过程调用(RPC)有效载荷的消息的端点操作。所谓服务界面抽象地根据消息结构和简单的消息交换的序列(或WSDL专用名词中的“操作”)来定义。然后，将它们限定在具体网络协议和数据编码格式上，以定义一个端点。汇总相关的具体端点，以定义抽象的端点(服务)。

WSDL支持与用于服务激起的协议捆绑不同的服务界面的定义。WSDL考虑到了单个服务的多个捆绑。此外，服务界面定义和访问捆绑与服务的功能性的实现也不同。服务请求者通常根据相应的WSDL产生Web服务的客户存根码(stub code)；服务的WSDL通常从服务提供商请求。客户存根码实现必要的逻辑，以建立正确的消息结构和正确的数据编码，来对端点进行寻址。由于服务的定义、捆绑和实现之间存在着差别，因此，为某一定义和捆绑所建立的客户存根码通常可以通过只是利用另一个端点地址，对各种端点进行寻址，而不要求代码变化。图5A及其续图5B为熟练技术人员揭示了一例WSDL文档的具体细节。

根据请求-响应方案，Web服务的重要特性在于它们是无状态的。无状态服务器是一种把每个请求都看作是一个与任何先前的请求互不相关的独立事务处理的服务器。这就简化了服务器的设计，因为它不必分配存储器来处理进程中的会话或如果客户在事务处理中死机时不必为解除它而担心。缺点在于，在每一请求中它可能必需包括更多的信息，并且这一额外信息每次都需要由服务器来解释。

以上描述了上述种类的电子通信运行的限制，以下将描述现有技术的缺点：

Web服务的商业使用基于服务提供商与服务请求者之间订立的合同。这种合同表示关于使用和提供Web服务或Web应用的条件的协定。合同细节可以规定：对服务记帐的情况(即价格)，更详细地指定所需服务质量的服务级别，和对服务请求者和服务提供商而言都十分关键的进一步的信息。基本上，在现有技术的商业中，不存在关于合同的范围或合同的数量的限制：一个合同可以包含多个服务，或者一个服务可以包含在多个合同中，这些都是同时有效的。

在典型的现有技术情况下，要么两方(即：这里被称为SC的服务请求者或服务消费者，和被称为SP的服务提供商)进行通信，要么三方(即：服务请求者，管理上述合同的服务提供商，和使请求者有时看不见的实际上执行服务的被称为SS的服务供应商)由Web服务通信组成。

被详细阐述以提出上述Web服务设施的这种现有技术的唯一揭示公布于“IBM Web Services Toolkit”(“Emerging TechnologiesToolkit”)，根据IBM Alphaworks的许可协定，只有在2002年的60天试用期内可供使用。

前面所述的被称为“合同服务”的且包括本发明相关的大多数技术特征的软件部分简要回顾如下：

该合同服务处理服务提供商与服务请求者之间的关系。该合同服务提供了关于服务提供商与服务中枢(service hub)之间的合同类型(部署合同，又称为提供商合同)和服务请求者与服务中枢之间的合同类型(使用合同)的信息。使用合同可用来预订通过服务中枢所提供的任何服务的操作的任意组合。一个使用合同包括了诸如对服务操作的调用如何收费(按时间、按使用个数、按使用量等)以及该客户应当为所预订的服务操作支付多少费用等信息。对于每个使用合同，合同服务规定了所使用的支付方法和费率模型，该合同的有效日期。合同可以任选地存储双方(服务中枢和服务提供商/请求者)对该合同的数字签名。在与Web服务工具包一同运送的实用服务演示中，合同通过与该演示一同运送的实用服务门户加入到合同服务中，并且在请求者可以使用该服务之前必须有在服务中枢与服务请求者之间的有效合同。

在Web服务的这种现有技术的签约系统中，存在着一些缺点，介绍如下：

Web服务规定了用于描述软件组件(其执行对客户来说可能具有相当大的商业价值)的技术，它们描述了这种Web服务如何可以被客户所访问，并且它们还描述了对客户来说使得能识别相关服务提供商的发现方法。Web服务主要是与编程语言、编程模型和系统软件无关的。上述Web服务不久的将来非常重要，因为它们构成了动态电子商务尤其是按需电子商务的关键部分。

按需电子商务除了对服务进行计量和记帐之外，还要求复杂系统处理在可以将实际按需服务提供给客户之前必须就位的合同关系。

在按需电子商务与现有技术的软件使用之间存在着显著的相似之处：在这两种领域中，客户都可以随时付一些款，以便使用某个软件(其执行可为客户带来一些预定的商业价值)。因为在现有技术的软件使用中，不同类型许可是已知的并且可用于为客户的特定要求所定制，因此，可能还强烈希望将许可工具实现成这种现有技术的可以实现客户喜爱的Web服务的合同管理系统。问题在于，许可方式可能被认为是一个特例，即一种为软件使用签约的特殊方式。不利之处在于，用于执行Web服务的现有技术的签约系统到目前为止还没有提供任何许可。将现有许可的商业方法简单地实现成电子Web服务管理的一个具体困难在于，用户可能在许可方面需要高度的个性化，Web服务的卖主或提供商无法以程序方式实现作为服务提供商与服务请求者之间面对面协商的对象的所有所希望的单独许可类型。因此，合同和许可管理基本上分成两类：

a)高级签约；和

b)低级签约。

高级签约处理上述用于商定所给定的合同条件的面对面协商，而低级签约处理合同属性的运行时间实现，直到签约双方都同意为止。Web服务的服务提供商与服务请求者之间的个性化许可需要很大的手工负担，因此通常只向值得担负协商的需要足够多许可的客户提供。

现有技术的合同管理的不利限制之一是，在消费者与服务提供的提供商之间存在一对一的关系。这表明了在将这种系统引用于大规模环境(例如，企业想为许多消费者(如使用这些服务的许多雇员)签定这些服务的合同的情况)时，会有较大的问题。如果现有技术的合同管理系统中加进现有软件许可技巧，那么，客户可以只从具有某些预置条件(在该条件下，他可以使用该软件或该服务)的预定许可中作选择。如果所提供的许可不能符合他的要求，那么，他只能接受一个不能真正符合他的需要的许可，或者，他根本无法使用该软件或该服务。

在许多商业情形中，不同许可策略的协商(基本上是客户所希望的)在对服务提供商来说值得付出努力的销售过程中需要许多交互。此外，还不能像在现有技术的软件许可方式中那样使用众所周知的已建立的使用模型，这是因为，现有技术的软件许可方式与这样一些情形(其中许可软件的使用是离线完成的并且与软件提供商或软件卖主无关)的离线过程相结合。

发明内容

因此，本发明的目的在于改善执行Web服务的现有技术的方法。

本发明的这一目的可以通过所附的独立权利要求中所述的特征来实现。本发明的进一步的有利配置和实施方式如各自的从属权利要求中所述。下面应当参照所附权利要求书。

根据权利要求1所述的本发明的基本方面，公开了一种用于改善Web服务的现有技术的交付的基本方法，其中服务消费者可以利用请求中所含的信息发出服务请求，该信息包括一种用户ID，该用户ID使得服务提供商可以选择服务消费者与服务提供商之间的有效合同。此外，在服务提供商站点，最好在运行时间期间利用现有许可转包合同和相应的许可软件组件，协同存储有关于实际提供的或在当前服务请求之前所提供的服务的使用的所有必要的使用信息的服务计量组件，对客户特定的许可模型自动进行例示，以便找到相应的特殊许可模型，这种模型可以充分满足客户的实际需要，并且它也被在所协商的合同条款和条件的合同范围所覆盖。从而，不同许可策略随后可适用于服务请求者的特定需要而被遵守。

实现这种方法的最好方式是，根据经验提供能够满足大多数客户需要的多种不同的许可类型。一批很好的不同许可类型包括以下类型：

a)消费类型，其中只允许服务的特定数量的请求。可选择地，这种类型可以与必须完成这些请求的预定时间段有关；

b)“并行”许可类型，其中只允许服务的特定数量的同时请求；

c)基于时间的许可类型，其中只在特定时间允许服务请求。这一时间可以是周期性的，比如星期一至星期五，或者可以是单一的类型，比如2003年1月至7月；

d)与名字相关的许可类型，其中只允许按许可策略中所列的预定原则来请求服务。据此，例如一个4人组可以使用服务；

e)“基本”类型许可，其中不必保持访问规则和使用条件，这意味着始终允许服务请求，而与时间、历史消费以及同时访问个数无关，这可以最好只授权给有限数量的个人；

f)使用条件许可类型，其中许可策略规定了任意预定的使用条件，例如，不允许任意转卖所提供服务的条件。当然，还可以有其他条件，无疑这取决于使用的特殊情形和领域。

上述不同的许可类型被归类为“基本单元”(atomic)许可类型，这是因为，每种单独的许可类型都提出了使用条件的单个完全独立的方面。此外，其优点在于，所述基本单元许可类型可以被组合，以便能够为客户提供许多不同的许可模型，比如Web服务界尚不了解的优选特性。可以通过关联单独的预定的一小部分来获得一种组合的许可类型(例如每种基本单元许可类型的一部分结合成组合类型)，这最好还可以用于记帐。

此外，其优点还在于，根据本发明的许可的定义或多种许可类型的定义是用于说明作为所述许可基础的合同的电子文档的一部分。据此，优点在于，合同信息和许可类型信息相互紧密地被保存，这使得在维护这些数据时更便于使用。

此外，当实现根据本发明的不同许可类型的签约系统还包括为计量所请求服务的技术细节(尤其是可用来形成服务本身延办的记帐过程的部分的那些细节)所设计和定义的计量软件组件时，并且当与当前合同ID相关的所述计量数据被读出且在检查步骤中用来判定是否允许服务预备时，那么，同一合同管理系统包括有效操作所请求服务以及产生与该服务有关的记帐过程所需的一个单独系统中的所有技术软件部分。

此外，当许可验证程序模块具有每种许可类型的模块结构时，并且如果这些模块在处理到来的请求时依次被运行，那么，另一优点在于，本发明的思想容易延伸到更多的许可类型，而无需围绕这新模块强制附加许多元逻辑。此外，本发明的思想还可以被结合到含有简档处理器、合同处理器和计量请求处理器的合同管理系统中，其中这些处理器组件配合相应的远程操作服务，即用于检查和确认请求者的个人身份的简档服务、用于检查合同使用的合同服务和用于计量任何与服务相关的实体(比如，使用时间、通过网络传送的数据量等)的计量服务，于是，处理的各个部分可以在最适合于收集和处理各种数据的位置来完成。

附图说明

下面利用附图中图形来举例说明本发明，但并不限于这些图形，其中：

图1是说明HTTP POST请求消息中所含的现有技术的SOAP请求消息的代码段表示；

图2是说明现有技术的HTTP请求的结构的代码段表示；

图3是说明现有技术的SOAP消息的细节结构的代码段表示；

图4是说明HTTP POST请求消息中所含的现有技术的SOAP消息的总结构的代码段表示；

图5A是说明用于描述Web服务的一例现有技术的WSDL文档的一部分的代码段表示；

图5B是图5A的续图；

图6是根据本发明方法的一种优选实施方式的服务消费者、服务供应商和服务提供商之间的关系的示意图；

图7是在图6中所给情况下所用的主要结构单元的示意图；

图8是根据本发明许可处理部分所改进的本发明方法的另一种优选实施方式的服务消费者、服务供应商和服务提供商之间的关系的示意图；

图9是在图8中所给情况下所用的主要结构单元的示意图；

图10是说明根据本发明的许可处理软件部分的一例实施方式中的控制流程的示意图。

具体实施方式

参照图6，描述这样一种情况，其中服务供应商(又简写成SS)向服务消费者(简写成SC)提供服务。服务提供商(简写成SP)实现含有主要发明的软件组件的合同管理基础设施的主要部分。

这就产生了如下交互，根据这一实施方式，这些交互在各自的程序模块中作为SC、SS和SP各方所用的各自发明方法的“步骤”来实现。如附图中所示，这些步骤列举如下：

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

步骤620：SS向SP发出服务请求以便使用SP提供的签约系统和基础设施服务。具体地说，在本实施方式中，签约系统服务包括签约服务，而基础设施服务是计量服务和简档服务。

步骤630：SP执行所请求的签约系统和基础设施服务，例如，验证有效合同可用，启动计量事件，再将这些状态返回给SP。

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

步骤650：SS把表示服务结果的数据发送给SC。

步骤620的实现细节如图7中所示：服务提供商实现虚线框所示的应用服务器，该服务器包括小服务器(servelet)71，从而实现服务请求的运行时间环境，例如Web服务运行时间环境，诸如Apache轴。

应用服务器还包括用标号72、74、76表示的多个处理器组件。这些处理器实现基础设施组件F-H的本地实现方式，这可以在例如又作为Web服务的远程服务器上实现。处理器72、74、76提供处理与远程服务的通信所需要的本地功能性：

●简档处理器72利用外部简档服务72A来验证请求者的身份。

●合同处理器74利用外部合同服务74A来验证合同状态和合同有效性。

●计量处理器76产生足够的计量事件(开始事件、结束事件、自组织事件、取消事件等)。

组件71、72、74、76(小服务器和处理器)在共享存储器环境下运行并通过共享数据进行通信。小服务器71确保按正确次序调用处理器。

基础设施服务描述如下：

简档服务72A基本上可以按上述现有技术中所用方式来使用。

简档服务提供对用户简档信息(诸如名字、地址、用户ID等)的访问。根据这一实现方式，用户简档信息可以扩展到包括更多的信息。简档服务可以用来保存、删除和得到简档信息。

为了其他服务可以正确地工作，商业服务的所有用户都必须具有简档服务所指定的简档。可以事先利用用户界面或者通过直接编辑保存有简档的XML文件来建立简档。这种简档服务可以用其他任何身份系统(诸如Tivoli身份管理器)来替换。

合同服务74A实现现有技术的签约管理思想，它适应于结合本发明的许可组件。

计量服务76A接收计量事件，如下所述，不断地保存计量事件并根据请求检索计量事件。根据这一优选实施方式，计量服务可以与来自合同服务74的合同信息结合起来使用，以产生使用特定服务的特定用户的使用报告。应当注意，合同服务74A和计量服务76A为了数据交换都要与本发明的许可服务组件75A连接。

本发明的许可服务组件75A配合合同服务74A和计量服务76A，以便使SC的服务使用充分满足商定的许可情况。更多细节如稍后所述。

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

●recordMeterEvent--保存一个计量事件

●recordMeterEvents--保存多个计量事件

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

计量事件含有服务名和所调用服务的操作名、时间标记以及用于处理请求的合同的ID。计量事件随类型而变，因此，对服务调用计费可能有各种各样的方式：

●当服务访问按进行服务所用的时间量计费，使用开始/结束事件；

●当访问按服务被访问的次数或除时间外的其他基础计费时时，使用自组织事件。

除了上述事件之外，还可以使用两种事件类型：

a)事件“被取消”，它用来取消已被发送给计量服务的事件，和

b)事件“未知”，它在服务请求者没有提供事件类型时被使用。

上述软件组件之间的交互如下所述：

步骤710：小服务器71接收服务供应商发出的服务请求，提取消息上下文，并将该消息上下文传递到后续处理器部分。

步骤720：消息上下文，共享数据对象，传递后续处理器部分。这些处理器对消息上下文进行扩展/修改，然后将它传递到链结构中的下一处理器。

步骤730：简档处理器72向含有相应数据库应用的外部简档服务72A发出服务请求，以便检查服务供应商的身份。

步骤740：简档服务72将身份检查结果返回到SP的简档处理器。

步骤750：合同处理器调用外部合同服务74A，以便识别和确认相应的合同：它调用“getUsageContractsForValidForIdentity”操作并传递从简档服务结果中得到的服务消费者身份。

根据这一优选实施方式，合同服务74A读取合同ID，然后使用这一身份的有效合同。根据本发明的一种优选实施方式，合同服务74A将各合同文档中的许可条件数据保存在合同服务数据库中。所述合同服务配合所述以上介绍的本发明的软件组件(称为许可(验证)组件75A)，这可以确保服务请求遵守合同中所预定的许可策略。其细节将参照图10作进一步的说明。

根据实现这一部分的一种优选方式，称为步骤752的实现变形A如下所述：

许可组件75A向上述计量服务76A中请求实际或历史使用数据。这一数据用来评估许可策略的具体类型，例如，如上所述的消费类型、并行类型等。

根据另一种有效方式，提出了实现变形B，其中许可部分75A具有当前使用数据并利用这一数据来进行评估。许可评估本身将参照图10作更详细的描述。

步骤760：合同服务74A将许可和合同情况的状态和有效性返回给SP的合同处理器。如果没有发现有效合同或许可使用条件，那么，提出异常情况，并可以拒绝该服务请求。

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

步骤780：计量处理器将更新的消息上下文返回给小服务器。根据上述变形B，计量服务76A将服务使用情况通报给许可组件75A。许可组件利用这一信息来确认某些许可策略，例如消费、并行许可使用，参见步骤750。

步骤790：小服务器71在步骤790中将初始服务调用(请求)返回给服务供应商。

在另一种情况下，参照图8和9，服务提供商为服务消费者提供服务。为了满足服务请求，服务提供商向服务供应商请求服务。具体步骤如下：

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

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

步骤830：SS执行服务并将结果返回给SP；和

步骤840：SP产生结束计量事件并将商业服务结果返回给SC。

下面说明本发明的实现方式，并将参照图9加以描述：

服务提供商将如以上参照图6和7所述实现应用服务器。因此，下面将主要描述其不同之处：

根据这一特殊实施方式，服务处理器90(参见图9的右边缘)调用(参见步骤980)外部商业服务，该外部商业服务是由服务供应商(SS)所提供的(步骤985)。

组件小服务器91以及处理器72、74、76和90还在共享存储器环境下运行并通过共享数据进行通信。小服务器91与前面图7中所述的小服务器相比只有因第2种情况下的特别不同之处所生产的相应不同之处，并确保按正确次序调用处理器。

商业Web服务92是服务供应商所提供的外部服务器部分；服务消费者SC在步骤910中将调用它，以便满足所请求的服务调用。

具体地说，这些组成部分之间的交互如下所述：

步骤910：小服务器91接收服务消费者(SC)发出的服务请求，提取消息上下文，并将该消息上下文传递到后续处理器部分。

步骤720-770--参见上述第1种情况。

步骤980：服务处理器90调用所请求的商业服务92，并利用所得到的服务响应更新消息上下文，和在

步骤985：将其返回到服务处理器90。

步骤990：服务处理器将更新的消息上下文返回到小服务器91。

步骤995：小服务器91将初始调用的结果返回到服务消费者。

许可组件75A的逻辑如图10中所示。

合同服务74A请求(参见步骤1005)确认来自许可组件75A的给定服务消费者(委托人(principal))和给定服务的许可的确认。SC的请求(用“C.request”表示)含有合同，该合同包括了许可表示方式。

根据图10，按预定次序逐一评估每种许可策略，这里只是举例进行了说明。其控制在许可调度器1010中实现。

使用消费量和并行使用量1030的计算1020基于计量服务76A通过调度器1010所请求和输入的计量数据。

在步骤1020中，计算使用消费量，即由作为步骤1020的一部分的各个计量数据评估提出和回答一些问题，比如，“该委托人到目前为止每隔多久消费一次该服务”、“该委托人在当前时段每隔多久请求一次该服务”等问题。然后，将使用消费量与许可中所规定的限值进行比较(参见步骤1022)。如果累计使用量仍然低于合同许可部分中的描述其消费方面的界定值，那么，利用进一步的判决1024来检查是否还有更多的许可类型可用于该合同。在判决1024的“YES”分支中，分支回到许可调度器1010，由此进入下一许可类型的类似控制流程，参见计算1030、1040或1050。因此，许可管理可以继续评估其余许可类型，以便根据合同中的协商条款和条件收取消费者的费用。这还可以包括：组合若干种许可类型来收取服务费。或者，它还可意味着，服务可采用最有利的“统一费用”(flat rate)(无限制/无约束使用的许可)方式，如果这至少对于所提供的部分服务有可能的话，例如在这样一种情况下：50％的服务属于并行使用许可类型，而另外50％属于时隙许可类型。

在判决1024的“NO”分支中，没有更多的许可。因此，许可生成器将存储消费类型许可部分支持当前请求，并发出相应的赞同SC的肯定许可确认响应。

再回头参照判决1022，否则，在其“NO”分支，即如果当前使用量超过了使用消费许可类型所允许的使用量，那么，控制转向许可生成器1060，该生成器发出例如伴随所请求服务的拒绝消息的相应否定许可确认响应。

于是，调度器1010启动步骤1030，该步骤计算并行使用量(“目前执行了多少该委托人所发出的并行服务请求？”)。该控制流类似于以上结合步骤1022和1024所述的控制流，但适应于若干个并行用户。在步骤1032中，计量服务76A请求当前使用数据。许可服务75A向计量服务发出相应的请求。根据本发明方法的实际实施方式，可以区分两种不同的请求类型：关于以前请求服务的次数的第一种请求数据和关于目前使用服务的次数的第二种请求数据。这两种请求采取可以被计量服务76A处理的类似参数。

在如上所述的类似方式中，执行了步骤1032、1034(并行使用类型)、1040、1042和1044(时隙许可类型)以及1050、1052、1054(基于身份的许可类型)。如果还存在所达成的无限制许可类型，那么，这种类型也可以使用(如果该请求被上述许可类型覆盖的话)。

此外，根据实际实施方式和所使用的应用，步骤1020、1022和1024和/或步骤1030、1032、1034可以激活计量服务76A并可以使用新使用数据以用于确认。此外，所述激活可以独立执行，而使用数据可以被存储，然后在后续步骤1020、1022和1024和/或步骤1030、1032、1034中作为参考。

在本发明方式的另一种变形中，计量服务76A可以将使用数据推进到许可部分75A。许可部分接收这些通报并保存这些使用数据；于是不会如上所述发出相应的请求。

响应生成器1070生成总确认：如果每一许可策略都被确认通过，那么总结果是“成功”。

从前面的描述可以看到，本发明通过建立许可的概念扩展了上述现有技术：许可规定了一个或多个委托人(如一个用户、一组用户、独特名称所标识的计算机资源或应用等)的访问规则和使用条件。

根据本发明，许可可以表示成一种许可策略或多种许可策略的组合。许可策略规定了访问规则和/或使用条件的一个方面。通过组合多种许可策略，可以规定访问规则和使用条件的任意方面。这样可以充分满足消费者的需要。

许可可以是指一整个合同或者是指一条或多条合同条款。

许可的表示方式可以嵌入在合同表示方式中，或者可以实现成逻辑上与合同链接的单独文档。以下列表说明了嵌入在合同文档中的许可的XML表示方式：

<UsageContractDoc

name ＝MyUsageContract

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

startdate ＝2002-07-01 00:00:00.000000000

enddate ＝2003-07-01 00:00:00.000000000><services>

<service servicekey＝0clf2376-043a-4294-a6ef-0c131cf2243a

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

<service servicekey＝3ec01bb7-331e-4e89-8256-3e0b0c3b1335

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

</services>

<license_policy type＝Named>

4412d44b-3163-4d42-bd5e-366d305e999

</identitykey>

</license_policy>

<license_policy type＝Consumptive>

1000

</maxRequests>

</license_policy>

<license_policy type＝UsageCondition>

ResellingNotAllowed

</usageCondition>

</license_policy>

</license></UsageContractDoc>End of Listing

下面的例子说明了根据本发明的优选方式如何组合基本单元许可策略以产生一个新许可。所用的基本单元策略(atomic policy)类型是“基本”、“命名”、“并行”、“消费”和“定时”类型；熟练技术人员可以理解，还可以有更多的基本单元许可策略类型。

在这些例子中，在使用合同内部定义了许可。在这种情况下，许可服务75A将利用合同服务74A所提供的信息以及来自计量服务76A的计量数据在运行时间作出有关许可的有效性的判决。这一本发明方法使得易于建立个性化许可。当然，还可以以各种方式来修改这一本发明的方法，例如，许可服务75A遵照许可数据库中所保存的信息行事，并且只与该数据库中所保存的作为合同一部分的许可链接。

例1

<UsageContractDoc

name ＝SampleContractl

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

101718f60116

startdate ＝2002-07-01 00:00:00.000000000

enddate ＝2003-07-01 00:00:00.000000000>

<service servicekey ＝0c1f2376-043a-4294-a6ef-0c131cf2243

ratingkeys ＝3312d44b-3163-4d42-bd5e-366d305e291

/>

<service servicekey ＝3ec01bb7-331e-4e89-8256-3e0b0c3b133

ratingkeys ＝1a2fdeed-026c-47a9-be32-2fb63896303

/>

</services>

<license_policy type＝Named>

<identity>Donald Duck</identity>

<identity>Mickey Mouse</identity>

</license_policy>

<license_policy type＝Consumptive>

</license_policy>

<license_policy type＝UsageCondition>

no reselling allowed

</license_policy>

</license>

</UsageContractDoc>

上例中，通过组合基本单元许可策略类型“标名”(举例说明唐老鸭和米老鼠)、“消费”(将每月最多请求次数界定为1000次)和“使用条件”(说明不允许转卖服务)来定义一个许可。虽然前两种许可组件技术上可以被强制执行，但类型“使用条件”规定了所涉及的两方之间的共同协定。

命名

通过命名许可策略，允许两个人(唐老鸭和米老鼠)使用合同所预订的服务。

消费

消费许可策略允许每月调用合同所预定的服务1000次。

使用条件

该许可策略禁止转卖合同所预订的服务。

通过组合这些基本单元许可策略来产生一个新许可，只有命名许可策略中所列出的人才能每月使用合同所预订的服务总共1000次调用。

例2

<UsageContractDoc

name ＝SampleContract2

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

101718f60116

startdate ＝2002-07-01 00:00:00.000000000

enddate ＝2003-07-01 00:00:00.000000000>

<service servicekey ＝0c1f2376-043a-4294-a6ef-0c131cf2243

ratingkeys ＝3312d44b-3163-4d42-bd5e-366d305e291

/>

<service servicekey ＝3ec01bb7-331e-4e89-8256-3e0b0c3b133

ratingkeys ＝1a2fdeed-026c-47a9-be32-2fb63896303

/>

</services>

<license_policy type＝Named>

<identity>Donald Duck </identity>

<identity>Mickey Mouse</identity>

<identity>Superman </identity>

</license_policy>

<license_policy type＝Concurrent>

</license_policy>

</license>

</UsageContractDoc>

上例中，通过组合基本单元许可策略类型“标名”和“并行”来定义一个许可。这两个许可组件技术上可以被强制执行。

命名

通过命名许可策略，允许三个人(唐老鸭、米老鼠和超人)使用合同所预订的服务。

并行

并行许可策略允许每次只能对合同所预定的服务进行单个调用。

通过组合这些基本单元许可策略产生一个新许可，命名许可策略中所列出的任何人每次只对合同所预订的服务进行单个调用。如果系统目前正在处理对这些服务中的任一服务的调用，那么，将不能继续其他调用(即使是来自另一所列人员的调用)。

例3

<UsageContractDoc

name ＝SampleContract3

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

101718f60116

startdate ＝2002-07-01 00:00:00.000000000

enddate ＝2003-07-01 00:00:00.000000000>

<service servicekey ＝0c1f2376-043a-4294-a6ef-0c131cf2243

ratingkeys ＝3312d44b-3163-4d42-bd5e-366d305e291

/>

<service servicekey ＝3ec01bb7-331e-4e89-8256-3e0b0c3b133

ratingkeys ＝1a2fdeed-026c-47a9-be32-2fb63896303

/>

</services>

<license_policy type＝TimeBased>

</allowedtime>

</allowedtime>

</license_policy>

<license_policy type＝Concurrent>

</license_policy>

<license_policy type＝Consumptive>

</license_policy>

</license>

</UsageContractDoc>

上例中，通过组合基本单元许可策略类型“基于时间的”、“并行”和“消费”来定义一个许可。所有这些组件技术上都可以被强制执行。

基于时间的

通过基于时间的许可策略，将可以请求服务的期限规定为9-12点和18-22点。

并行

并行许可策略允许每次只能对合同所预定的服务进行两个调用。

消费

消费许可策略允许调用合同所预定的服务1000次。

通过组合这些基本单元许可策略，产生如下新许可：只可以在“基于时间的”策略类型所规定的期限内调用合同所预定的任何服务。但即使在这里所列的时间段内，也只能同时进行两个调用，而每月根本不可以超过500次调用。

本发明可以用硬件、软件或软硬件组合来实现。根据本发明的工具可以在单个计算机系统以集中方式来实现，或者以分布方式(将不同的单元散布到多个互连的计算机系统中)来实现。适合于执行本文所述的方法的任意一种计算机系统或其他设备都适用。软硬件的一种典型组合可以是具有计算机程序的通用计算机系统，其中该程序在被安装和执行时可以控制计算机系统，使得该系统可以执行本文所述的方法。

本发明还可以嵌入到计算机程序产品中，该程序产品包括能实现本文所述的方法的所有特性，并且当被安装到计算机系统中时能够执行这些方法。

本文中的计算机程序装置或计算机程序是指以下指令集的任意表达方式(任何语言、代码或符号)，该指令集用来使具有信息处理能力的系统直接执行特定功能，或者在以下两者之一或这两者之后来执行特定功能：

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

b)以不同的具体形式再现。

Claims

1.一种用于处理与服务请求者(SC)和服务提供商(SP)之间的合同有关的服务的方法，其中所述服务要通过网络来提供，其中在所述服务请求者与所述服务提供商之间规定了至少一个服务合同，其特征在于如下步骤：

a)在有效合同情况下并有到来的服务请求时，从第一数据源(74A)中读取(1010，1020，1030，1040，1050)在所述服务请求者(SC)与所述服务提供商(SP)之间所订立的预定许可条件数据；

b)从第二数据源(76A)中读取表示当前提供的或在当前服务请求之前提供的服务的使用的特性的使用信息；

c)借助所述使用信息检查(1022，1032，1042，1052)所述许可条件数据是否允许提供所请求的服务；

d)如果允许，则初始化(1060，1070)所述所请求服务的提供。

2.如权利要求1所述的方法，其中所述许可条件数据包括选自一组预定的不同许可类型的至少一个许可类型。

3.如上述权利要求所述的方法，其中至少一个许可类型选自下列组：

a)消费许可类型；

b)并行许可类型；

c)基于时间的许可类型；

d)与个人相关的许可类型；

e)无限制许可类型；或

f)使用条件许可类型。

4.如上述权利要求所述的方法，其中有效许可可以由所述不同的许可类型中的一个或多个组合而成。

5.如权利要求1所述的方法，其中许可的定义是合同描述XML文档的一部分。

6.如权利要求1所述的方法，其中规定计量软件组件(76A)，用于计量所请求服务的技术细节，还包括如下步骤：

a)处理(752，780)与当前合同ID有关的计量数据；

b)无论是否允许服务提供，都将所述计量数据包含到检查步骤(1022，1032，1042，1052)中。

7.如权利要求1所述的方法，其中许可验证程序模块(75A)用于具有每种许可类型的模块结构。

8.如上述权利要求所述的方法，其中所述许可验证程序模块(75A)包括与合同管理软件组件(74A)和与所述计量组件(76A)的软件接口。

9.如权利要求1所述的方法，其中简档服务(72A)、签约服务(74A)和计量服务(76A)由具有相应的分开的数据库应用系统的服务提供商远程操作，并且其中所述服务(72A，74A，76A)与驻留在服务提供商站点的应用服务器中的相应处理器组件(72，74，76)进行交互。

10.一种用于处理与服务请求者(SC)和服务提供商(SP)之间的合同有关的服务的应用服务器系统，其中所述服务要通过网络来提供，其中在所述服务请求者与所述服务提供商之间规定了至少一个服务合同，该应用服务器系统包括功能组件(75A)，用于执行如下步骤：

d)如果允许，则初始化(1060，1070)所述所请求服务的提供。

11.数据处理系统中执行的计算机程序，包括计算机程序代码部分，用于当所述计算机程序代码部分在计算机上执行时执行如权利要求1-9任一所述的方法的相应步骤。

12.存储在计算机可用媒体上的计算机程序产品，包括计算机可读程序工具，用于当所述计算机程序产品在计算机上执行时使计算机执行如权利要求1-9任一所述的方法。