专利名称：在分布式计算环境中供应聚合服务的制作方法
技术领域：
本发明涉及计算机软件，具体涉及在分布式计算环境中供应聚合服务的技术。
背景技术：
最近几年，分布式计算网络和网络计算的普及已迅速增长，大部分由于被称为“万维网”(或简称“web”)的公共因特网及其子集的增长的商业和消费使用。其他类型的分布式计算环境，例如公司内联网和外联网，也迅速普及。由于解决方案提供者致力于提供改善的基于web的计算，所以开发出的许多解决方案适于其他分布式计算环境。因此，在此引用因特网和web仅为了示例目的，而非限制目的。
在分布式计算中正在作出改进的领域在所谓的“web服务”倡仪(initiative)中。该倡仪通常也称作用于分布式计算的“面向服务的架构”。web服务是因特网中分布式应用集成的新兴技术。一般来说，“web服务”是描述一组网络可访问操作的接口。web服务实现一个特定任务或一组任务。它们可以以可互操作的方式与一个或多个其他web服务合作，以执行复杂工作流程或商业交易中它们的各自部分。例如，完成复杂的购买订单交易可能需要位于订购商业机构的下订单服务(即下订单软件)与位于其一个或多个商业伙伴的订单实现服务之间的自动交互。
许多业界专家认为面向服务的web服务倡仪将是因特网的下一发展阶段。利用web服务，对软件的分布式网络访问将变得广泛可用于程序到程序操作，而不需要人为干涉。
web服务一般是使用这样的模型来构造的，其中提供网络可访问服务的企业将服务发布到网络可访问注册中心(registry)，并且需要服务的其他企业能查询该注册中心以得知该服务的可用性。该计算模型中的参与者通常称为(1)服务提供者，(2)服务请求者，和(3)服务代理(broker)。图1中示出了这些参与者，以及涉及在它们之间交换消息的基本操作。服务提供者100是具有可用服务的实体，而这些服务将被发布110到的注册中心由服务代理120维护。服务请求者150是需要服务并查询140该服务代理的注册中心的实体。当利用该注册中心找到所需服务时，为了使用该服务，服务请求者绑定(bind)130于所定位的服务提供者。这些操作被设计为程序化地发生而无需人为干预，从而服务请求者能在运行时动态搜索特定服务并利用该服务。理论上，对于任何类型的计算应用，该web服务模型都是可用的。然而，如今可从注册中心访问的web服务限于相对简单的程序，例如“你好，世界！”演示程序，查询特定邮政编码的当前温度的程序，执行外汇兑换计算的程序等。
构建web服务工作的标准的核心集包括HTTP(“超文本传输协议”)、SOAP(“简单对象访问协议”)和/或XML(“可扩展置标语言”)协议、WSDL(“web服务描述语言”)、和UDDI(“统一描述、发现和集成”)。HTTP通常用于通过例如因特网的TCP/IP(“传输控制协议/网际协议”)网络交换消息。SOAP是用于在分布式环境中发送方法调用消息的基于XML的协议。XML协议是用于应用层传输协议的万维网联盟(“W3C”)的发展中规范，它将允许应用到应用的消息发送，并且可以与SOAP汇合。WSDL是用于描述分布式网络服务的XML格式。UDDI是基于XML的注册技术，利用其企业可列出他们的服务，而服务请求者可找到提供特定服务的企业。(欲知SOAP的更多信息，参考可在网址http//www.w3.org/TR/2000/NOTE-SOAP-20000508上得到的“Simple Object Access Protocol(SOAP)1.1，W3C Note 08 May2000”。欲知XML协议和XML协议标准的创建的更多信息，参见http//www.w3.org/2000/xp。名为“Web Services Description Language(WSDL)1.1，W3C Note 15 March 2001”的WSDL规范可获得于网址http//www.w3.org/TR/2001/NOTE-wsdl-20010315。欲知UDDI的更多信息，参考可在网址http//www.uddi.org/specification.html上得到的名为“UDDIVersion 2.0 API Specification，UDDI Open Draft Specification 8 June 2001”的UDDI规范。HTTP在名为“Hypertext Transfer Protocol-HTTP/1.1”(June 1999)的来自因特网工程任务组的请求注解(“RFC”)2616中有描述。)利用这些开放标准的应用集成需要几个步骤。必须描述web服务的接口，该接口包括利用其调用服务的方法名，该方法的输入和输出参数及其数据类型等。WSDL文档提供该信息，并利用UDDI发布操作发送到根据UDDI规范实现的注册中心。一旦在UDDI注册中心中注册了该服务，则服务请求者可发出UDDI查找请求以定位分布式服务。以这种方式定位服务的服务请求者然后发出UDDI绑定请求，其利用来自该WSDL文档的服务信息而将该请求者动态绑定到所定位的服务。(图1在高层上示出了这些UDDI操作。)SOAP/XML协议和HTTP消息通常用于发送该WSDL文档和该UDDI请求。(以下，对SOAP的引用应解释为等同地引用XML协议的语义上类似的方面。而且，应注意这里对“HTTP”的引用是一般意义上的，它是指引用HTTP类似功能。例如，一些UDDI操作需要HTTPS而不是HTTP，这里HTTPS是HTTP的安全性增强版本。然而，这些差别与本发明无关，因此以下当讨论HTTP时不作区别。)web服务的目标是为服务提供者提供对可驻留在一个或多个远程位置中的程序组件的透明访问，即使这些组件与请求者的组件相比可能在不同操作系统上运行，并且可能以不同的编程语言编写。尽管已做了大量的工作来定义web服务将基于的目标、架构、和标准，但仍有很多工作尚待完成以使web服务有效且高效地操作。
具体而言，考虑到以传统方式提供的许多应用服务需要用户在使用这些服务之前进行认证和授权。本上下文中的认证是指判定用户实际上是他声称的那个人，而授权典型地是指判定该用户的访问权限是什么或是否允许该用户访问特定服务或其功能。在web服务环境中，目的是可动态定位服务提供者以执行特定服务。如果多个服务提供者可用，则可能基于例如利用该提供者的服务的价格、该提供者的服务的响应时间保证等的标准来选择这些服务提供者中的特定一个。每一提供者都可能具有不同的认证和授权信息格式，以及访问认证和授权功能的独特方式。没有为本发明人所知的用于在web服务环境中联合、或加入异构身份系统的技术，这将是使用聚合web服务的严重抑制因素。
发明内容
本发明提供了用于在计算网络中供应聚合服务的方法、系统、和计算机程序产品。在优选实施例中，一个或多个软件资源提供聚合服务，并且该技术包括定义该聚合服务的供应接口；在服务描述文档中指定该供应接口；根据该服务描述文档而获得该聚合服务的用户的凭证(credential)；分析所获得的凭证；以及如果通过该分析表明，则允许该用户执行该聚合服务。
该技术还可包括定义该聚合服务的一个或多个软件资源的至少一个的供应接口；和对于该至少一个软件资源的每一个，在该服务描述文档或一个或多个其他服务描述文档中指定由该软件资源执行的服务的供应接口。在该情况下，除了获得该聚合服务的用户的凭证之外，还根据该服务描述文档或一个或多个其他服务描述文档而获得该至少一个软件资源的凭证。然后如果通过这些凭证的分析也表明，则最好允许该用户执行由该至少一个软件资源的供应接口代表的所选服务。
在优选实施例中，该分析步骤包括该凭证的(1)认证和(2)授权中的至少一个。
因此可在该聚合服务的软件资源所执行的分布式服务之间程序化地传递(relay)身份信息。最好，该程序化传递包括发送消息，在该消息的报头中指定该凭证，并在该消息的主体中指定服务请求。该消息可为例如SOAP(“简单对象访问协议”)消息。
最好使用置标语言来指定该服务描述文档。该标记语言最好是web服务描述语言(“WSDL”)。
该技术还可包括在注册中心注册该服务描述文档，该注册中心可为利用标准化消息访问的网络可访问的注册中心。
现在将参考附图仅作为示例描述本发明的优选实施例，其中相同的附图标记在全文范围内表示相同的单元。
图1提供了示出根据现有技术的面向服务的架构的参与者和基本操作的图；图2是示出根据相关发明的优选实施例的构造为web服务代理的小端口(portlet)的方框图；图3A和3B分别示出根据相关发明的优选实施例的指定部署(deployment)接口和系统接口的样例WSDL文档的内容；图4提供了相关发明中公开的服务聚合的web服务栈方法的图示；图5A到5E示出根据本发明优选实施例的描述供应服务接口的样例WSDL文档片段；图6提供了示出可用于实现本发明的优选实施例的逻辑的流程图；以及图7A和7B提供了根据现有技术的在其报头载有数字签名的SOAP信封的例子。
具体实施例方式
web服务的承诺是不同应用将能够前所未有地互相操作，从而通过企业系统的开放和有礼化(urbanization)而提供新型的无缝高度集成的应用。web服务将使分布式软件资源更广泛地可用，并允许软件作为服务出售。将动态聚合来自一个或多个服务提供者的服务，以为用户提供执行每一特定用户当前感兴趣的任务或服务所需的功能。为了有效使用这些动态集成服务，必须能够自动且动态地加入它们可使用的异构身份系统。这必须实时完成，以便使得用户(人或程序)能被无缝地认证和授权、或“识别”，以使用该服务。而且，期望利用单点登录(single sign-on)提供该无缝识别，因为在特定服务(包括由多个子服务组成的服务)期间要求用户反复标识他们自己会使得用户受挫并耗时和低效。本发明提供了这些需求的解决方案，并且在实施该解决方案中支持多个开放工业标准技术，后面将对此进行描述。
在讨论这些实施例的细节之前，回顾一点背景信息是有帮助的，其中包括本发明的优选实施例所基于的技术。相关发明定义了用于管理web服务和用于提供其中服务可被聚合以形成然后可被部署的新服务的聚合点的技术。相关发明的优选实施例基于例如门户平台的内容框架，因为这类框架提供很多用于内容管理和内容托管(hosting)的内置服务，例如持久性、个人化、和代码转换。相关发明中所公开的技术将平台扩展为提供web服务的聚合、部署、和管理。公开了模型化组合工具，它可用于定义聚合服务；然后可根据该聚合服务定义来程序化地集成软件资源。另外，可以自动方式管理聚合服务。
本发明定义了用于供应通过使用相关发明而产生的聚合服务的技术。这些技术也可适用于以其他方式创建的聚合服务，而不脱离本发明的范围。而且，应注意尽管本文是按照供应“聚合”服务来讨论的，但聚合服务本身是web服务(由子服务组成)，因此本发明也可有利地用于可以被认为是原子服务的那些web服务(因此是聚合的退化情况，其中聚合“子服务”集具有单个成员)。
一个市场上可买到的可在其上实现本发明(以及相关发明)实施例的门户平台是来自国际商业机器公司(“IBM”)的WebSpherePortal Server(“WPS”)。(“WebSphere”是IBM的注册商标。)然而注意，尽管相关发明和本发明的讨论都关于门户平台，但具有创造性的概念适用于提供类似功能的其他类型的内容框架，并且也适用于WPS以外的门户，因此对门户及其小端口范例(paradigm)的引用仅作为示例而不起限制的作用。
通过相关发明使得可能的web服务的动态运行时(run-time)集成可使用用于聚合新web服务的组合工具。利用该组合工具，系统管理员(或者等同地，服务组合者或其他人)可定义由更细粒度的服务组成的新服务。根据其构建其他服务的细粒度服务可本地或远程驻留，并且相关发明的技术允许以透明方式引用这些服务和使用这些服务，而不管它们是本地还是远程的。细粒度服务可包括任何形式的编程逻辑，包括脚本程序、JavaTM类、COM类、EJB(“Enterprise JavaBeans”TM)、存储过程、IMS或其他数据库事务、传统应用等。(“Java”和“Enterprise JavaBeans”是Sun Microsystems，Inc.的商标。)然后，以这种方式创建的web服务可自动地由门户平台管理并也可用于以递归方式创建新web服务，这在相关发明中有描述。
相关发明支持(leverage)小端口作为门户接口，并且也基于远程小端口接口的概念(该概念扩展到应用于程序化小端口)，从而允许访问软件资源。以这种方式工作的小端口可称作“web服务中介”或“web服务代理”。也就是说，相关发明使得小端口能用作请求特定服务的应用或软件资源和提供该服务的软件资源之间的中介。执行特定功能的软件资源可静态绑定于web服务代理(例如，在开发时候)，或web服务代理可绑定于动态选择的软件资源(例如，基于在运行时评测的标准)。在任一种情况下，小端口代理接收请求消息并将它们转发到与其绑定的软件资源；一旦该软件资源完成所请求的功能，则它将其响应返回到该小端口代理，然后，该小端口代理将该响应转发到请求者。
应注意被调用以执行聚合服务的软件资源可被设计用于程序到程序的交互，但可选地它可以在性质上是可视的。例如，在主要以程序到程序方式工作的web服务的执行期间，可调用面向可视的资源。这里所用的术语“程序化小端口”泛指根据相关发明和本发明的小端口代理，而不管底层软件资源是否包括面向可视的代码。
图2示出一个方框图，其中示出根据相关发明的构造为web服务代理的小端口。如图所示，小端口代理240包括部署接口210、系统接口220、和功能接口230。该小端口代理利用这些接口与门户平台200通信，从而担当门户平台和执行感兴趣的功能的软件资源250之间的中介。每一功能接口的细节特定于软件资源250所提供的web服务，而不形成相关发明的一部分。然而，相关发明使软件资源250的功能接口可用作小端口代理的接口230。(如相关发明所述，在部署过程中，可利用市场上可买到的工具如IBM WebServices Toolkit或“WSTK”实现利用WSDL定义和SOAP服务暴露功能接口。)部署接口和系统接口在相关发明中有详细描述。现在将提供简要概述。根据相关发明的优选实施例，为每个用作web服务代理的小端口定义部署接口和系统接口(尽管在可选实施例中，可实现这些接口中的一个或其他)。这些新接口也可分别称作部署端口类型和系统端口类型。因此，根据相关发明的小端口定义了服务提供者类型，该类型包括软件资源的门户集成以及服务交互和管理所必需的端口类型。(“端口类型”是本领域中用于表示小端口操作规范的术语，而“服务提供者类型”是用于表示端口类型集合的术语。)根据相关发明，该部署接口使得小端口代理(即，由小端口代理代表的聚合web服务)能以递归方式在随后的web服务组合操作中使用。例如，当小端口A与其他小端口聚合以形成新web服务“Z”时，小端口“A”的部署接口提供关于小端口A的信息以进行使用。根据相关发明，通过定义web服务Z的部署接口，当服务Z用于组合其他新服务时，可随后提供关于web服务Z的信息。
系统接口由门户平台用于小端口(即由小端口代理代表的web服务)的运行时管理。系统接口的使用允许门户平台执行例如事件记录、结帐、和关于web服务执行的其他类型的管理操作的功能。为此目的而使用门户平台和小端口代理之间的双向通信。
图3A和3B分别提供了示出部署接口规范和系统接口规范的样例WSDL文档。根据相关发明的优选实施例，采用WSDL文档表示部署和系统端口类型，然后可在注册中心注册它们。如图3A中WSDL文档300的310所示，该示例部署接口被命名为“Deployment”并包括例如“getDisplayName”和“getDisplayIcon16×16”的操作(见元素330)。例如可使用这些操作以检索该web服务的描述名称并检索放置在web服务组合工具的调色板上的代表该web服务的图形图像。根据WSDL规范，在“<message>”元素320中指定了用于与服务通信的输入和输出消息，其中这些消息所使用的参数被定义为“<part>”元素。因此，对于为该端口类型指定的每一操作的每一消息，定义一个消息元素。(参考WSDL规范，可获得关于WSDL文档的详细资料的更多信息。)图3B中的WSDL文档350定义了系统接口，在本例中它被命名为“System”(见元素360)。在本例中，定义了名为“Event”的复杂数据类型(见元素370)，它包括两个字符串参数和一个日期参数。例如，当交换将在审核日志文件中记录的日志数据时，可使用该数据类型。还定义了“logEvent”操作(见元素390)，在本例中，它是利用具有类型为Event的参数的“logEventReceive”消息(见元素380)调用的单向操作。另外，本例还定义了具有两个消息“reportInput”和“reportOutput”的“reportUsage”操作。
本发明的优选实施例可以扩展部署接口以包括关于聚合web服务的供应信息。可选地，为此目的可定义单独的供应接口，而不脱离本发明的范围。图5A到5E示出样例供应接口规范500。如在此所述，通过采用WSDL文档表示供应端口类型或接口，然后可在注册中心程序化地注册web服务的供应信息，并可在运行时程序化地定位和绑定关于该供应接口的信息。
如果将该供应接口实现为部署接口的扩展，则特定web服务的接口规范最好在部署接口定义内的供应portType元素中指定其操作。例如，图3A中的部署接口规范300可扩展为包括部署portType元素。现在简要参考图5A到5E，当利用该方法时，图5A到5E所示的样例消息规范可添加到在部署规范中定义的其他消息中(图3A的元素320所示)，并且可随同用于部署操作的portType 330一起指定例如图5D和5E所示的附加portType元素。可选地，可提供单独WSDL文档来专用于供应，其中该单独文档具有其自己的<types>元素、<schema>元素等。在该可选方案中，该WSDL文档的<definitions>元素可由例如图5A到5E的接口规范所示的供应消息和操作组成。
根据WSDL规范，在“<message>”元素中指定用于与web服务通信的输入和输出消息，其中由这些消息使用的参数被定义为“<part>”元素。因此，对于为该端口类型指定的每一操作的每一消息，定义了消息元素。(参考WSDL规范，可获得关于WSDL文档的详细资料的更多信息。)如相关发明所述，最好使用有向图来对在执行由其他web服务(即子服务)组成的聚合web服务中所涉及的操作进行建模。所选的小端口操作代表该图的节点，而链接这些节点的图形边代表从一个服务操作或过程到另一个的潜在跃迁。可用一个或多个跃迁条件，如果适用的话也可用数据映射信息限制这些服务链接。这些条件指定在什么条件下应调用下一链接的服务。经常地，将利用前一服务调用的结果判定这些条件。数据映射是指在小端口端口类型之间链接操作并从一个操作向另一个操作传输数据的能力。例如，数据映射信息可表示将一个服务的输出参数映射到另一服务的输入参数。
最好，对于该有向图支持，支持web服务流语言(“WSFL”)。具体而言，可将利用有向图的WSFL的持久存储技术和运行时评估技术添加到web服务栈，以在服务组合者所创建的图上操作。关于WSFL的详细讨论，参考可在IBM的http//www-4.ibm.com/software/solutions/webservices/pdf/WSFL.pdf上得到的名为“Web Services Flow Language(WSFL 1.0)”，Prof.Dr.F.Leymann(May 2001)的WSFL规范，这里将其全文引作参考。
参考图4，其中示出在相关发明中公开的服务聚合的web服务栈方法。web服务栈400最好使用用于定义和执行聚合服务的WSFL服务流支持410，并且最好利用UDDI提供服务发现420和服务发布430。该web服务栈还包括WSDL层440以支持服务描述文档。SOAP可用于提供基于XML的消息发送450。例如HTTP、文件传输协议(“FTP”)、电子邮件、消息队列(“MQ”)等的协议可用于网络支持460。如相关发明所述，WSDL用于定义web服务端口类型和定义如何调用这些端口类型的操作，而WSFL用于聚合web服务(因此聚合它们的接口)。在运行时，利用UDDI服务发现过程在注册中心内查找服务，并利用来自它们的WSDL定义的信息来绑定服务。WSFL运行时然后使用这些(端口类型)定义来聚合这些服务。(因为这些操作的签名将典型地不一一匹配，所以如相关发明所述，可在代理模型中使用在WSFL规范中定义的“插入链接”机制以采用简单方式映射接口，从而提供操作接口之间的一致。相关发明公开了将该插入链接机制用作集成小端口代理以实现web服务的持久定义。)创建要被部署为web服务的软件资源的源代码的开发者指定将由该服务提供的认证、授权、和/或配置方法。然后可以如相关发明所述聚合这些服务，并且可以使用本发明的技术来供应聚合服务。例如，假设聚合服务被设计成为个人用户提供电子邮件服务。可提供一个子服务来建立用户的电子邮件帐户。典型地，该帐户建立子服务将需要输入如下信息，即用户的全名、与该人关联的电子邮件用户标识符、该人访问其电子邮件帐户的密码、以及可能的配置信息如应为该用户的电子邮件消息分配多少存储空间。(当用户利用聚合电子邮件服务的另一子服务来访问他的电子邮件消息时，随后可以结合用户标识符使用所存储的密码来认证该用户。)也可能提供访问权信息作为帐户建立子服务的输入。例如，作为系统管理员的用户可被给予用于执行例如增加另一用户的存储空间分配、删除另一用户的电子邮件等的操作的附加访问权。然后可使用WSDL文档来定义由每个子服务提供的操作、以及用于调用这些操作的消息和参数。
如相关发明所述，可通过个人用户或利用程序操作、或其结合来执行创建WSDL文档。(例如，可能会要求个人用户提供例如端口类型名、名称空间信息的位置等的信息，而程序操作为软件资源的公共方法生成<operation>和<message>元素。IBM的WSTK是市场上可买到的可用于程序化地为现有软件资源生成WSDL的产品的一个例子。参见IBM在网址http//wwW-106.ibm.com/developerworks/webservices/library/ws-peer4公布的“The Web services(r)evolutionPart 4，Web Services Description Language(WSDL)”，G.Glass(Feb.2001)，它提供了程序化地为具有“getTemp”和“setTemp”操作的简单天气服务生成WSDL文档的例子。
为了加入动态集成的服务的身份系统，根据本发明，利用WSDL文档将每一服务的供应接口发布到UDDI注册中心。然后，可通过人工地或程序化地从组成聚合的子服务的接口中选择来创建聚合服务的供应接口，并且可以递归方式为该新供应接口创建WSDL文档并进行发布。
分布式服务的发现和调用的动态性质使得统一的认证和授权操作更难。这里公开的技术通过使得能够在web服务工作流的上下文中供应聚合服务而克服了这一困难，其中在工作流定义中利用WSDL文档标识操作，并利用SOAP消息调用操作。
聚合服务可将对它们所暴露操作的访问限制于具有足够凭证并利用所暴露的认证操作成功地证明这些凭证的那些用户。允许创建跨越聚合服务的用户简档(profile)、并可选地允许利用相应服务操作来查询、改变、和/或删除这些用户简档也可能是有利的。
现在将描述在图5A到5E中示出的样例消息和操作，并将使用它们来阐述本发明如何使得能够在分布式计算环境中供应聚合服务。(本领域内的技术人员应清楚仅为了示例说明的目的而提供图5A到图5E中示出的消息和操作及其参数。实际供应接口可包括其他消息和操作而不脱离本发明的范围。)“InResolveProvisioningIDRequest”消息502示出可用于向一个服务查询以查看谁是特定认证用户或实体的输入请求消息。(以下，如果不作具体限定，则术语“用户”可解释为等同地应用于个人用户或程序化实体例如自动服务。)消息规范502声明该请求采用字符串类型的名为“authToken”的参数。例如，假设对于聚合服务，个人用户已被认证，并且该聚合服务持有该个人用户的认证令牌“X”。还假设该聚合服务希望程序化地确定该个人用户如何为特定子服务“ServiceABC”所知。聚合服务需要定位具有该用户信息的供应系统。可使用消息502和504以提供该功能，其中将令牌“X”传递给“ServiceABC”的“ResolveProvisioningID”操作(最好，利用SOAP消息，如后面参照图7A和7B所述)。如图5D所示，“ResolveProvisioningID”552是具有“InResolveProvisioningIDRequest”消息(见图5A的元素502)和“OutResolveProvisioningIDResponse”消息(见图5A的元素504)的操作。“OutResolveProvisioningIDResponse”消息504被定义为返回名为“Identifier”(字符串类型)的参数。最好，返回的标识符是远程供应系统的标识符。然后可使用该标识符作为随后操作的输入参数(例如，见下述消息506、510和526)，以指定管理用户简档或服务配置信息的供应系统，这根据具体情况而定。
现在参照图7A和7B，本发明的优选实施例使用SOAP消息以在web服务之间通信。根据现有技术，示例SOAP消息700包括在其报头载有数字签名的SOAP信封。关于报头710和数字签名720，参见图7A。该数字签名可用于认证提交在SOAP消息主体中所承载的服务请求的请求者。关于消息主体730和请求740，参见图7B。在该样例消息700中，消息主体指定“GetLastTradePrice”消息，对于其，<msymbol>子元素具有值“IBM”。可假设这是调用股票报价服务，并且该服务需要认证用户；所以已在SOAP报头中提供用户的数字签名。(欲知关于以这种方式使用SOAP消息的更多信息，参考可在网址http//www.w3.org/TR/SOAP-dsig/得到的“SOAP SecurityExtensionsDigital Signature，W3C NOTE 06 February 2001”。)本实施例支持该数字签名技术以传达与认证聚合web服务的用户、确定这些用户的授权、和/或配置聚合web服务有关的信息。
回到图5A中样例供应接口消息的讨论，“InResolveUsersRequest”消息506示出可用于确定被授权访问特定服务的用户集的输入请求消息。在本例中，将认证令牌传递到正被查询的服务，并在该消息中，该令牌最好用于认证信息请求者(也就是说，请求授权用户信息的程序化实体或个人用户)。“provID”参数可用于提供服务提供者所托管的供应系统的地址(例如，统一资源标识符、或“URI”)。服务的“ResolveUsers”操作(见图5D的元素554)接收“InResolveUsersRequest”消息506，并且以“OutResolveUsersResponse”消息508响应。在本例中，该输出消息508被定义为返回名为“UserSet”的数组。消息508的part元素中的语法“SOAP-ENC”是名称空间的前缀，并用于限定该数组定义。(该输出数组可假定标识利用UDDI绑定并利用SOAP消息调用的托管该“ResolveUsers”操作554的特定服务的授权用户。当“ResolveUsers”被操作时，它可能已请求供应系统执行授权用户的确定。)“InCreateUserProfileRequest”消息510示出可能如何设计创建用户简档的输入请求消息的接口。如同在其他示例消息中，有利地包括认证令牌作为传递到远程服务的输入参数之一，从而该远程服务能认证该信息请求者并判定该请求者是否被授权使用暴露“InCreateUserProfileRequest”消息510的“CreateUserProfile”556服务。如上所述，可使用“provID”参数以提供供应系统的URI或其他地址，其中用户简档将存储在该供应系统中。“userID”参数最好标识正在为哪个人(个人用户的情况)或为哪个物(程序化用户的情况)创建简档的用户。可提供“password”参数以设置与该用户关联的密码。(如果需要，可使用密码以外的凭证来达此目的。)根据底层服务的需求，可将用户的全名传递到“FullName”参数中。最后，在该样例消息中，作为数组提供了用户的访问权。“CreateUserProfile”操作556接收“InCreateUserProfileRequest”消息510，并以“OutCreateUserProfileResponse”消息512响应。在本例中，该输出消息512返回表示简档创建是否成功的布尔值。
“InQueryUserProfileRequest”消息514示出用于从用户先前存储的简档中检索信息的输入请求消息的示例接口。该消息参数包括用于认证信息请求者的认证令牌“authToken”、用于标识其中存储了简档的供应系统的供应标识符“provID”、以及用于标识为其请求简档信息的用户的用户标识符“userID”。将消息514作为输入接口提供到“QueryUserProfile”558服务，并且本例的“OutQueryUserProfileResponse”消息516返回来自所存储简档的用户密码、全名、和访问权。
“InUpdateUserProfileRequest”消息518与“InCreateUserProfileRequest”消息510类似，并在本例中使用相同的参数。“UpdateUserProfile”操作560接收“InUpdateUserProfileRequest”消息518，并且以类似于“OutCreateUserProfileResponse”消息512的“OutUpdateUserProfileResponse”消息520响应。在本例中，该输出消息512返回表示该简档创建是否成功的布尔值。
“InDeleteUserProfileRequest”消息522和“OutDeleteUserProfileResponse”消息524被提供为“DeleteUserProfile”操作562的输入和输出接口(见图5E)，并且允许以类似于如何通过“CreateUserProfile”操作556和“UpdateUserProfile”操作560创建或更新简档的方式删除用户的简档。
除了例如已描述的认证和授权消息之外，定义与聚合web服务的配置有关的消息和操作也是有用的。图5E示出“SetConfigParameter”564和“GetConfigParameter”566操作的例子。
“SetConfigParameter”564操作的样例输入消息是“InSetConfigParameterRequest”526，而样例输出消息是“OutSetConfigParameterResponse”528。本例中的输入消息526具有多个输入参数，包括请求者的认证令牌“authToken”、标识其中应存储了参数值的供应系统的供应标识符“provID”、标识该参数应与其关联的用户的用户标识符“userID”、以及配置参数名称“parameterName”和值“parameterValue”。输出消息528返回布尔值“result”，表示“SetConfigParameter”操作是否成功。
“GetConfigParameter”566操作的样例输入消息是“InGetConfigParameterRequest”530，而样例输出消息是“OutGetConfigParameterResponse”532。除了省略了“parameterValue”参数之外，本例中的输入消息530具有与“InSetConfigParameterRequest”消息526相同的输入参数。输出消息532利用“parameterValue”参数返回所请求参数的值。
现在转到图6，其中示出了根据本发明优选实施例的可用于在web服务工作流的上下文中执行聚合服务及其子服务的身份和/或配置操作的逻辑。
根据本发明，可为聚合服务提供“统一登录”或单点登录能力，从而可以在执行该聚合服务的开始使用聚合服务的供应接口以向用户请求所有需要的信息。(显然，可能发生在执行期间需要向用户请求一些信息，因此本发明应被认为是使得能够最小化这些请求。)根据工作流定义，执行在聚合服务的WSFL工作流内顺序定义的操作。最好，从用户获得的登录信息被“堆栈化(stack)”以由与登录信息的各个元素有关的子服务使用。本领域内熟悉提供单点登录能力的身份系统和认证系统的人员了解模块的堆栈化。堆栈化是指使用“主”密码作为加密密钥，其中由此加密的信息包括一个或多个“副”密码。由于在本发明中使用堆栈化处理，因此副密码是用于子服务的密码，而主密码适用于聚合服务的范围并保护这些副密码。根据WSFL定义，按照特定顺序调用子服务，然后使堆栈化的密码出栈(unstack)，并且将其提供给适当的认证或授权子服务。
该过程开始于图6的块600，其中获得用户标识符和密码(或类似的认证输入类型)。(注意这里对“密码”的引用不意味着限制可以支持的凭证类型。可以许多方式提供凭证，包括明文、经过加密的字符串、票券(ticket)、和例如X.509证书的公开密钥安全证书。)然后可传递该认证信息作为远程服务的输入，一旦调用其认证操作，该远程服务将生成认证令牌(块610)。
最好，作为XML片段生成在块610生成的认证令牌，然后可将其包括在SOAP消息报头中。以这种方式，当访问web服务时，可传递(relay)用户身份。参考图7A和7B中对样例SOAP消息700的讨论，其中示出如何利用XML语法在SOAP报头中包括数字签名。(如这里所示，该数字签名令牌使用限定名称空间，因此开头为字母“ds”。)也可利用SOAP报头将认证系统和策略系统绑定于服务操作。WSDL描述最好将操作建模为SOAP报头和主体的结合。也就是说，所有需要身份证明的操作最好需要交换用户凭证。这里在本例中使用的SOAP安全性扩展技术是如何可实现此的一个例子。安全性关联置标语言(“SAML”)、一般安全性服务(“GSS”)API和公共安全互操作性(“CSI”)架构也提供用于安全交换当事人(principal)的凭证的手段。(SAML的一个版本在2001年4月11日的OASIS草案中有定义，可在网址http//www.oasis-open.org/committees/security/docs/draft-sstc-saml-spec-00.PDF上得到该文献。GSS-API在2000年1月的RFC 2743，“Generic Security ServiceApplication Program Interface，Version 2，Update 1”中有定义。CSI在“CommonSecure Interoperability V2 Specification”中有定义，该文献可在网址http//www.omg.org/cgi-bin/doc？ptc/2001-03-02上得到。)利用在块600获得的输入信息而在块610生成的令牌这里称为“通用”认证令牌，因为它最好用作该用户的替代者，随后使用它来向聚合服务的各个子服务标识该用户。(换言之，该令牌最好不特定于任何一个子服务或操作。)块620的测试检查该用户是否(仍然)被全局认证(也就是说，对于该聚合服务)。在优选实施例中，一旦认证了用户，则他/她的凭证与该流的剩余部分的请求(即根据该聚合服务的调用)关联。然而，图6的逻辑被设计成多次在块620执行测试，以例如考虑用户可能在流模型中所指定的操作序列期间退出登录的情况。如果该测试具有否定结果，则不允许该用户继续操作该聚合服务，并最好返回失败码(块640)，其后图6的处理结束。如果该测试具有肯定结果，则在块630处理继续，测试该用户是否被局部认证(也就是说，对于所要执行的下一服务，其中根据WSFL流模型确定该服务)。如果该测试具有否定结果，则控制转移到块640；否则，控制转移到块670。
在块625，检索所要执行的下一操作的堆栈化身份信息。将所检索的信息传递到该下一操作的认证服务，其利用该身份信息来生成(或检索)操作特定令牌。
在块660，利用SOAP报头将该操作特定令牌返回到调用方(如参照图7A和7B所述)。(注意尽管图5A到5C中的响应消息没有示出返回认证令牌，但如果需要也可添加这样的令牌。)块670然后使用该接收的操作特定令牌以确定用户的操作特定认证。(用户可具有多个角色来对于特定类别的操作确定他们的凭证。作为一个例子，作为管理者的人当以管理者角色操作时可能允许查看其雇员的人事记录，而当以雇员角色操作时则可能不允许使用该相同操作来查看他自己的人事记录。)块670的授权调用最好也使用SOAP报头，以传递在块660接收的操作特定令牌。如果授权操作的结果表示对于该聚合服务中所要执行的下一操作，该用户被授权，则处理进入块680。(否则，可以产生错误和/或流程可能进入不同操作。特定处理可根据具体实现而不同，因此不在图6中示出。本领域内的普通技术人员应明白如何可将适当的逻辑添加到图6。)块680调用下一顺序操作。如果需要用户凭证，则该调用也可使用SOAP报头，以传递在块660接收的操作特定令牌。(如果作为块670的处理结果而接收到授权令牌，则可作为对来自块650的令牌的补充或代替来传递该令牌。)该操作完成之后，块690检查该序列中是否有更多操作。如果否，则图6的处理结束。否则，控制返回到块620以判定对于该聚合服务，用户是否仍被认证(然后，如前所述，块630将判定对于该下一服务，用户是否被认证)。
如前所述，本发明提供用于供应聚合web服务的有利技术。最好使用SOAP报头来传递身份信息。所公开的技术使得不同身份系统能加入web服务的动态、运行时集成环境。支持开放标准。注意，尽管在描述优选实施例时引用了特定标准(例如WSFL和SOAP)，但这只是为了阐述本发明的创造性概念。可使用用于提供类似功能的另外方式而不脱离本发明的范围。
本领域内的技术人员应明白，本发明的实施例可提供为方法、系统、或计算机程序产品。因此，本发明可采用完全硬件实施例、完全软件实施例、或结合软件和硬件方面的实施例的形式。而且，本发明可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、CD-ROM、光学存储器等)上实施的计算机程序产品的形式。
本发明是参照根据本发明实施例的方法、设备(系统)、和计算机程序产品的流程图和/或方框图来描述的。应理解可由计算机程序指令实现流程图和/或方框图中的每一流程和/或方框、以及流程图和/或方框图中的流程和/或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理设备的处理器以产生一个机器，使得通过计算机或其他可编程数据处理设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的装置。
这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理设备以特定方式工作的计算机可读存储器中，使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品，该指令装置实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能。
这些计算机程序指令也可装载到计算机或其他可编程数据处理设备上，使得在计算机或其他可编程设备上执行一系列操作步骤以产生计算机实现的处理，从而在计算机或其他可编程设备上执行的指令提供用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的步骤。
尽管已描述了本发明的优选实施例，但本领域内的技术人员一旦得知了基本创造性概念，则可对这些实施例作出另外的变更和修改。所以，所附权利要求意欲解释为包括优选实施例以及落入本发明范围的所有变更和修改。
权利要求
1.一种在计算网络中供应聚合服务的一个或多个软件资源的方法，包括以下步骤定义该聚合服务的供应接口；在服务描述文档中指定该供应接口；根据该服务描述文档来获得该聚合服务的用户的凭证；分析所获得的凭证；以及如果通过该分析步骤表明，则允许该用户执行该聚合服务。
2.根据权利要求1所述的方法，还包括以下步骤在注册中心注册该服务描述文档。
3.根据权利要求2所述的方法，还包括以下步骤定义该聚合服务的一个或多个软件资源的至少一个的供应接口；以及对于该至少一个软件接口的每一个，在该服务描述文档或一个或多个其他服务描述文档中指定由该软件资源执行的服务的供应接口。
4.根据权利要求3所述的方法，其中获得该聚合服务的用户的凭证的步骤也根据该服务描述文档或一个或多个其他服务描述文档来获得该至少一个软件资源的凭证；并且还包括以下步骤如果通过该分析步骤表明，则允许该用户执行由该至少一个软件资源的供应接口代表的所选服务。
5.根据权利要求4所述的方法，还包括获得该用户的操作特定凭证的步骤，并且其中允许用户执行所选服务的步骤依赖于该所选服务的操作特定凭证。
6.根据权利要求4所述的方法，其中该分析步骤包括该凭证的(1)认证和(2)授权中的至少一个。
7.根据权利要求1所述的方法，其中在该聚合服务的软件资源所执行的分布式服务之间程序化地传递身份信息。
8.根据权利要求7所述的方法，其中该程序化传递包括发送消息，在该消息的报头中指定该凭证，并在该消息的主体中指定服务请求。
9.根据权利要求8所述的方法，其中该消息是SOAP(“简单对象访问协议”)消息。
10.根据权利要求1所述的方法，其中以置标语言指定该服务描述文档。
11.根据权利要求10所述的方法，其中该标记语言是web服务描述语言(“WSDL”)。
12.根据权利要求2所述的方法，其中该注册中心是利用标准化消息访问的网络可访问的注册中心。
13.一种用于在计算网络中供应聚合服务的一个或多个软件资源的系统，包括用于定义该聚合服务的供应接口的装置；用于在服务描述文档中指定该供应接口的装置；用于根据该服务描述文档来获得该聚合服务的用户的凭证的装置；用于分析所获得的凭证的装置；以及用于如果由该用于分析的装置表明则允许该用户执行该聚合服务的装置。
14.一种用于在计算网络中供应聚合服务的一个或多个软件资源的计算机程序产品，该计算机程序产品实施在一个或多个计算机可读介质上，并且包括用于定义该聚合服务的供应接口的计算机可读程序代码装置；用于在服务描述文档中指定该供应接口的计算机可读程序代码装置；用于根据该服务描述文档来获得该聚合服务的用户的凭证的计算机可读程序代码装置；用于分析所获得的凭证的计算机可读程序代码装置；以及用于如果由该用于分析的计算机可读程序代码装置表明则允许该用户执行该聚合服务的计算机可读程序代码装置。
全文摘要
公开了用于供应与聚合web服务一起使用的软件资源的方法、系统、和计算机程序产品。该公开的技术使得异构身份系统能加入到动态、运行时web服务集成环境。现在可为聚合服务及其子服务执行认证和授权。作为一个例子，SOAP(“简单对象访问协议”)消息可用于在分布式服务之间传递身份信息，从而可在该SOAP消息报头中指定凭证以伴随在该SOAP消息主体中指定的服务请求。
文档编号G06F21/20GK1608248SQ02826017
公开日2005年4月20日 申请日期2002年12月11日 优先权日2002年1月15日
发明者詹姆斯·弗莱彻, 戴维·利德奎斯特, 迈克尔·万德斯基, 埃贾姆·韦斯利 申请人:国际商业机器公司