展示过程流以及作为万维网服务的安排控制器的制作方法

专利名称：展示过程流以及作为万维网服务的安排控制器的制作方法
技术领域：
本发明涉及支持文档交换安排(choreography)的基于计算机的设备和方 法。具体地说，本发明的一些方面涉及便于通过安排版本、服务版本和文档版 本的各种组合来升级系统的设备和方法。本发明提供采用安排代理的安排管理
器，并向非安排使能的应用提供能使用安排的界面。本发明的其它方面包括图 形设计工具和将主机服务透明地别名为多语境设置特许服务。
背景技术：
商业到商业(B2B)和应用到应用(A2A)的电子商务正将以前的协议替 换为电子数据交换(EDI)。由于商业力争用B2B和A2A系统来提高效率，因 此出现了很多不兼容的平台和相互竟争的标准。即使在兼容标准中也存在需要 填补的空白。例如工业上定义了什么是简单的web服务。涉及简单Web服务的 标准包括UDDI、 WSDL、 XSDL和SOAP。但是，这些标准没有完全满足对实 际B2B和A2A电子商务的安全性、可靠性、可管理性以及安排需求。在本文 中，服务之间的消息交换安排包括为安排的交换设置一种模式，并用标识符(例 如会话ID)跟踪作为交换一部分的消息。安排尤其表示具有大量选项和配置问 题的竟争平台。期望协作web服务及其安排逐渐成为非web业务。不存在任何广泛或统一的设备或方法可以动态解决发展中产生的问题。
实施B2B和A2A电子商务的一种方法是采用web服务。web服务是一种 以模块方式展示功能于万维网上的根本的新方法。在web服务发展的当前阶段， 大量注意力都集中在文档交换和RPC web服务上。RPC web服务支持其中调用
程范例。
web服务的当前实现通常遵循3个标准。UDDI是基于搜索准则发现web 服务并下载其界面的登录标准。WSDL是定义web服务的消息界面的界面标准。 SOAP是包括与用于通过导线传送有效载荷的HTTP传送器之间的定义的绑定 的包络协议。web服务通常依赖于XML标准，例如XSDL、 Xlink、 Xbase和 Xpointer以及通用web标准，例如HTTP和URI。
目前大多数web服务都是简单的web服务。简单web服务采用同步的不 可靠的HTTP传送器，并且不支持除发送级安全性之外的安全性，或者允诺有 效载荷中的、只能由通信双方理解的安全信息。简单web服务包含操作。调用 web服务意味着调用该web服务的操作。操作可能设计成接受单路消息或支持 其中调用者为响应而进行阻塞并且被调用的服务立即响应的请求/响应范例。简 单web服务可以采用RPC编程范例或基于文档的编程范例。
对标准兼容的web服务的挑战是定义高性能web服务以改善企业的业务能 力。这样的web服务支持具有可靠性(就是一次性)、异步传送如SMTP、 JMS、 专有性(加密)、完整性(签名)、验证和授权、以及路由的调用。
所出现的另一个挑战是定义协作的web服务。这些web服务可能与其它 web服务保持长时间的交互，并且可以在没有安排的会话式语境的情况下调用 非协作web服务。这种协作web服务需要对在会话中将相关的消息相关的支持， 以及对返回地址的支持。
有很多企业着手扩展可用于B2B及A2A的电子商务的标准。对于安排 (choreography)方面的努力包括来自OASIS的ebXML/BPSS、来自IBM的 WSFL、来自Microsoft的XLANG。对于会话方面的努力包括来自OASIS的 ebXML/TRP和Microsoft的WS-routing。其它方面的努力包括来自IBM、 Microsoft和BEA Systems的BPEL4WS (用于Web服务的商业处理执行语言)、 来自Sun Microsystems的"Web Service Choreography Interface 、 WSCL ( AVeb月良 务会话语言)和BPML (商业处理建模语言)。这么多的安排(choreography)努力都在进行中，以至于一些企业领导人在2002年9月要求W3C标准协会的 Web Service Architecture Working Group ( Web月良务体系结构工作组)设立可以 解决不兼容性的标准。对于可靠性，有来自Microsoft的建议、来自OASIS的 ebXML/TRP和来自IBM的HTTPR。 W3C正在所有这些领域致力于标准化。 基础工业的参与者已经形成了称为WSI的竟争同盟。但是他们尚未致力于服务 进展和安排问题。
因此，就出现了开发支持发展文档交换安排的方法和设备的机会。

发明内容
本发明涉及支持文档交换安排的基于计算机的设备和方法。具体地说，本 发明的一些方面涉及便于通过安排版本、服务版本和文档版本的各种组合来发 展系统的设备和方法。本发明是为采用安排代理的安排管理器提供的，并向非 安排使能的应用提供安排使能的界面。本发明的其它方面包括图形设计工具和 将主机服务透明地别名为多语境设置特许服务。


图1示出动态确定文档版本和翻译版本、服务版本和安排版本的能力。
图2示出消息交换如何涉及服务版本。
图3示出对一个或多个记录的引用以发现用于谈判的信息。
图4示出活动的4种类型。
图5示出活动和内部过程之间的交互。
图6示出在过程引擎中执行的用于构建安排代理的的内部过程流。 图7示出消息的相关。
图8和9有助于区分常规的非特许服务和特许服务。
图10-17示出本发明的实施例的多个屏幕。
图10是管理主机软件包屏幕。
图11示出注册新主机服务的部分。
图12示出用于编辑文档交换活动的屏幕。
图13示出用于验证或修改签名和加密策略的屏幕。
图14示出用于注册主机服务软件包的屏幕。
图15示出用于选择新的特许包的屏幕。图16示出用于选择特许选项的屏幕。
图17示出用于编辑服务详情的屏幕。
具体实施例方式
下面的详细说明是参考附图进行的。描述优选实施例是为了说明本发明， 而不是限制本发明的范围。本领域的技术人员可以知道对下面说明做出的各种 等价修改。
团体以及团体网络是一个其中实现文档交换安排的计算机辅助设备和方 法非常有用的环境。在这些团体中，有一个团体维护包括诸如作为该团体一部 分的用户、公司、服务和连接器的信息的本地记录。该团体可以是市场、公司 或子公司。团体可以属于一个或多个团体网络。典型地，团体和网络都具有一 些共同的商业兴趣。互操作存在于一个或多个团体网络中的成员团体之间。一 个团体网络提供团体的全局记录。该全局记录允许查找该团体并确定至该团体 或外部连接器的一个或多个路线，通过该外部连接器可以路由绑定给该团体的 电子商务文档。从一个团体到另一个团体路由的文档可以直接在这两个团体的 外部连接器之间路由，或间接通过一个或多个中间团体路由。还可以定义涉及 这些团体的事务的商业和安全规则，并保持在团体记录中。连接器是用于一个 与其它应用通信的应用的通用术语。连接器可以基于对等(P2P)通信，或以 定向为基础通过其它作用为集线器、网关、外部端口、中央连接器等的连接器 通信。P2P通信的连接器可以与其它采用相同传输/包络协议的连接器通信。或 者，P2P通信的连接器在试图与不采用相同传输/包络协议的连接器通信时，可 以征集其它执行翻译服务的集线连接器的帮助。以定向为基础通信的连接器通 过集线连接器根据路由规则来通信。在连接器之间的路由规则可以映射为定向 图，支持用于一个或多个传输/包络协议的一个或多个集线和辐射拓朴结构。集 线和辐射拓朴沿着至集线器的辐射在一层(tier)或多层中引导通信。这有利于 诸如结帐、商务智能采集、跟踪、审计、会计等等的集中服务。多个集线和辐 射组织结构可以覆盖相同的连接器，以支持不同的传输/包络协议和技术。例如， 可要求更强大的集线和辐射组织结构采用Sonic作为传输技术，而不是采用 HTTP或HTTPS。或者，通信路线可取决于源和目标是否属于同一团体。在子 团体(可以包括整个团体)内，当与其它子团体中的目标通信时，可能不需要 集中功能，并且可以在在其它情况下只能与父连接器通信的连接器之间进行P2P通信。
连接器可以分类为简单连接器(有时简称为连接器)、集线器(有时称为 网关或路由器)或中心连接器。或者，还可以对它们进行功能描述。筒单连接 器只能通过集线连接器通信，但是它们被允许在同一子团体中的连接器之间进
行P2P2通信。所谓的集线器由明确指向它们或链接到它们的连接器使用。集
线器可以提供多种功能，并因此可以在从源到目标的路线上出现不止一次。集 线器传递电子商务文档或消息。集线器还可以在支持公共包络协议的传输协议 之间进行翻译。例如，集线器可以翻译包络协议，还在传输时实施与接收时不 同的传输协议。中心连接器是一种特殊的集线器，可由非显式地指向它们或链 接到它们的连接器使用。中心连接器例如用于在根据路由规则从不引向任何支 持由目标使用的传输/包络协议的源穿越连接器时实施翻译功能。
在标准语境中，WSDL是基于标准的语言，用于定义所谓的服务定义 (WSDL中称为端口类型)、服务实例(服务)和连接器(端口 )。服务定义类 似于类定义。WSDL为服务类型命名，为该服务定义限定一组操作，该组操作 实质上就是服务方法，并定义该操作的输入/输出消息。由WSDL规定的操作 类型包括通告(向外绑定的消息)、单向(向内绑定的消息)、恳求/响应(与一 个跟随了 一个向内消息的向外消息同步)和请求/响应(与 一个跟随了 一个向外 消息的向内消息同步)。WSDL不处理服务之间交互的安排(choreography )。
本发明的方面大大超越WSDL而涉及服务中经过安排的操作。协同操作由 协作交互调用，其中在一个服务实例中的操作调用在另 一个服务实例中的操作。 两个服务实例之间的协作交互是单会话的一部分，其中会话是消息的双向流， 并且是安排实例。在会话中的消息通常包括安排采用的会话ID,和初始服务/ 操作的标识或返回地址。
图1结合本发明的几个方面示出为安排成会话的特定消息交换动态确定文 档版本和翻译版本101、服务版本102、安排版本103的能力。下面以相关应用 描述这些动态确定。
WSDL中的消息具有名称和一组部件。每个部件都具有名称、MIME内容 类型、和如果是XML还有用于该部件的图解(schema)定义。
本发明添加了文档系列的概念，而不是针对XML部件的显式图解定义， 其支持对文档版本的动态确定。文档系列是一组其图解定义文档结构的文档版 本。这允许两个正在交互的服务支持不同的文档版本。提供了版本转换逻辑，以便将源文档转换为要求的目标文档图解。这允许在不升级网络中所有采用该 文档相互交互的服务的情况下来发展文档版本。这就是所谓的文档版本互操作，
其进一步描述在上面指出的Registry Driven Interoperability and Exchange of Documents应用中。
本发明介绍了服务定义版本的概念，该服务定义版本也可以动态确定。新 版本可以向已存在的输入/输出参数或文档添加新的选项部件或删除已经存在 的选项部件，还可以向早期的服务版本添加新的操作。采用该早期版本的服务 实例可以用升级的新服务实例版本来正确寻址，因为版本号不是消息地址中服 务定义名称的一部分。(地址通常包括团体/服务定义名称/4喿作)总之，服务定 义是允许该定义的服务实例(有时简称服务)的模板。定义服务模板就像定义 类型，而定义服务实例就像定义该类型的变量。服务定义具有名称和版本，并 定义了在该服务中的活动列表以及一个或多个活动界面。该界面不显式地指明 所支持的文档，但至少指明所支持的文档系列。文档系列是一组具有相同业务 功能的文档。例如"purchase order (购买订单)，，是一个文档系列，xCBL3.5 purchase order和Rosettanet 1.0 purchase order是该系歹'J的成员。月良务定义可以由 团体管理员来建立，可以从供应商那里采用，如Commerce One,或者在将来， 可以由标准联盟来定义。服务实例通过指定实际使用的版本文档来完成界面定 义。实例还指定服务的策略和提供该服务的CP。实例还指定该实例所驻留的连 接器。消息由服务实例发送和接收。优选地，服务实例中的活动驻留在一个连 接器中。
安排定义语言通常定义角色之间的消息流。WSDL定义角色的服务界面。 但是安排定义语言没有与WSDL合并。在安排和服务之间缺乏清晰的绑定。本 发明的一个方面包括将安排角色映射为服务实例，并将安排消息映射为服务操 作的输入/输出参数。这在上面指出的BPSS Conversation Management和Local Business Management应用之间的Dynamic Interface中详细讨论了 。
本发明允许服务定义来定义一组该服务支持的安排(例如由名称标识的) 和可以动态确定的安排中的角色。服务实例将指明它所支持的安排的子集，并 可以指明在所支持的安排之间的优先顺序。运行时，计算参与的服务实例中所 支持的安排的交叉，并选择安排的一个特定版本用于消息交换。对一个或多个 服务的偏好可以成为决定采用哪个安排版本的因素。诸如发起人取胜、响应者 取胜、最后版本取胜、最早版本取胜的规则或偏好的加权可以成为考虑因素。或者，还可以预先定义两个服务之间指定采用哪个安排版本的协议。所有安排 参与者对随后在经过安排的会话中的所有消息都使用相同的安排。这使得安排 可以在不需要将整个网络中的所有服务都升级的情况下来发展。这就是所谓的 安排版本互操作。该互操作的实现不依赖于用于描述该安排的语言，而取决于 从名称理解安排含义的服务。
图2和图3示出两种选择安排版本或发现服务版本的方法。在图2中，消 息用于在第一服务201和第二服务202之间交换关于版本的信息。该方法可以 扩展到多于两个服务，其中将第一消息发送到所有其它服务，或将附加的第一 消息从第二或随后的服务发送到其它服务。例如在安排中，安排的不同变形和 版本中的第一消息211实际上都是相同的。由于文档版本的考虑，消息可能有 轻微差别，可以允许第一消息中的其它次要变形，而第一消息仍然保持与所有 安排版本兼容。当所采用的安排在第一消息中选择之后，在服务之间任一方向 上的所有后来消息都是该安排的一部分。在选择了安排版本之后，后来的消息 212-224都遵循所选择的安排。在图3中，引用一个或多个记录来发现关于由 第一服务和第二服务支持的版本的信息。发现过程本地的服务可以在方法321 可以访问的第一记录331中存储版本信息。远程服务则在方法323可以访问的 第二记录332中存储版本信息。在一些情况下，远程服务的信息在第一记录331 中，并且可以由方法322访问。例如，如果第一和第二^^务都在同一团体中并 依靠同一记录。或者，如果第一和第二服务近来有过接触，并且第一服务在第 一记录中緩存了第二服务的信息。关于由两个服务都支持的版本的信息由版本 选择逻辑311考虑。
因此，本发明的方面可以按照若干方式组合，以动态确定一些或所有文档 版本、服务版本和安排版本。根据本发明来实施，web服务实际上可以得到更 新，并与还没有得到类似更新的其它服务保持互操作性。
本发明的其它发面以所谓的对等交互或协作交互实现了将在互联网或其 它网络上的分布的协作web服务之间定义和执行的复杂安排和商业过程。其还 支持在继承web服务实施中常见的标准客户机/服务器交互(或非协作交互)。 在对等交互中，安排支持将服务之间交换的相关消息进行相关，并将返回地址 包括在会话消息中。
协作服务可能具有与非协作web服务或其它应用界面之间的虚拟会话。原 则上，这两个服务相互之间使用客户机/服务器交互，并且在绑定之外知道返回
10地址。这些服务采用检查消息有效载荷的应用逻辑来将消息相关。
协作服务具有o个或更多相关的语境。新语境由一个或多个触发操作创建。
或者，语境还可以自发地初始化(从收发消息的观点来看)。后面的非触发操作 初始化受该语境的约束。过程流实例是所引用的语境。 一个操作开始(kick Off) 该过程实例和所有涉及该实例的后来消息。该语境有助于与发起者进行双向会 话以及与其它由该语境驱动的服务进行双向会话。对于非协作服务，每个操作 本身就是完备的，发起者可以是任意程序，而不需要是服务，并且独立于服务 中每个其它操作的调用。
总之，在部件之间存在两类消息交互。对等消息通常与安排关联。在对等 交互中，提供一些附加信息。提供返回地址，通常标识发送CP、服务定义和活
动定义。提供消息相关数据，例如会话ID和安排ID和对ID的引用。返回地 址标识被调用服务应当在何处响应。为进一步帮助该服务，用于该交互的可应 用安排可以在该会话中返回到每个消息上的两个服务。在两个服务之间，会话 ID对该会话中的每个消息都具有相同的值。这允许服务方便地将相关的消息相 关联。安排ID在第一消息上选择，并对该会话保持原样。对ID的引用是指响 应消息的消息ID。 一个消息可以具有多个响应。
第二种消息交互是客户机/服务器交互(也称为非协作交互)。在客户机/ 服务器交互中，通常不存在发送服务/活动。请求和可选的一个响应通常结束该 交互，随后的客户机/服务器与该交互没有关联。
客户机/服务器的一个特殊方面是在请求/响应调用中对响应的转换支持。 在对等交互中，发送服务在其界面上提到它希望哪个文档响应。但对于客户机/ 服务器来说不是这样，请求者必须在请求中提到它希望哪个文档响应。如果请 求者不为 一个部件指定期望的文档，则响应者产生的文档不经任何变换就被发 送。
服务可以包括多个文档交换活动界面。文档交换活动界面可以定义为服务 定义的一部分，和当登录该服务实例时(定制)。活动由其界面和策略描述。 UI服务例如将它们的活动记录到用于特许确定、和其它访问控制信息(例如在 web代理上的单个签名)和资源路径的寄存器中。
活动可以有4种类型，如图4所示。请求/响应411:该活动接收请求并进 行响应。恳求/响应412:这是请求/响应的反界面。恳求响应活动可以调用另一 个服务实例中的请求/响应活动。单向414:这是接收异步消息的活动。通告413:
ii这是单向的反界面。通告活动调用在另一个服务实例中的单向活动。这些定义
与WSDL—致。
向活动的输入或输出称为消息。消息由多个部件组成。部件按照如下方式 描述。部件名称是该部件的唯一名称，对于每个来自/去往针对该部件的活动的 消息都可以重新^使用。部件类型可以是XML部件，或由MIME类型描述的部 件。如果该部件没有定义的MIME类型，则该部件的MIME类型可以在运行时 由调用者提供。部件位置指定该部件是位于体内还是一个附件。或者，还可以 在消息标题内或在消息外部，并且消息只是引用它。部件可以是必要的或可选 的。根指示器在该消息中应当有一个根部件。这通常是消息的主题，且通常 是XML部件。根部件表明要找到其它部件的横跨的起始点。根部件可以包括 对其它部件的引用，但不一定所有的部件都能通过从根部件横i夸来发现。消息 还可以包括文档ID列表。任何部件(XML或非XML )都可以属于一个文档系 列。与一个文档系列的成员(称为文档Id)相关的是描述符信息，还可以是图 解，或者来自/去往该成员的各种类型的可选转换映射。文档系列元凝:据独立于 服务而被记录。
在安排的服务中，过程流可以用于协调在界面相对一侧上的活动。用设计 工具定义并由定义在过程引擎中执行的过程流的概念已在其它语境中使用。例 如Commerce One具有称为CPM的过程流解决方案。过程定义了具有潜在分支 点以及并行执行线程的流。过程实例与语境关联，并由某个事件初始化，且持 续时间;f艮长。该语境贯穿由其它事件触发的一系列状态变迁，并且该过程本身 可以初始化作为该流的部分的事件。这些事件可以包括UI交互、文档交换事件 (发送或接收具有文档有效载荷的消息)、语境状态或相关数据库状态的变化、 或业务逻辑的调用。
图5示出活动和内部过程之间的交互。活动411至414与过程流5 21至5 2 5 交换消息。过程流步骤在它们自己之间传递消息。在另一个例子中，过程流可 以包括分支和过程的并行执行。
在过程引擎中执行的内部过程流也可以用于构建集中管理安排的安排代 理，如图6所示。安排可以通过使所有的消息流经过安排代理610来被集中管 理，该安排代理本身作为安排web服务出现，并采用内部过程流612。适用于 安排代理，从服务630到服务640的消息改变为从服务630到中间服务610的 消息，该中间服务610将消息转发到服务640。从服务640返回服务630的异步响应改变为从服务640到中间服务610的消息，该中间服务610将消息转发 到服务630。安排代理601包括界面611、 613、 614,通过它们来传递消息。内 部过程流612可以用于跟踪一个或多个安排的状态。 一些或所有内部过程流步 骤可以在事务返回日志中存储信息，该信息用于安排的消息交换在没有完成的 情况下就终止的情况。可以添加界面，以支持查询通过安排代理协调的一个或 更多安排实例的状态。同样，活动统计可以在安排协调期间编辑，并通过界面 报告。该集中化允许为了跟踪而查询安排的状态。错误处理和错误补正行为可 以更为容易地实施。当中间服务实施为过程流时，安排可能是全局正确的，因 为内部过程流遵循过程定义。为正确起见而提供了对安排的全局检查。
在过程引擎中执行的过程流获得触发事件的消息，并发送消息作为处理事 件的一部分。这些消息可以用诸如WSDL的标准web服务定义语言来描述。这 些描述可以用诸如UDDI的标准记录轻易发现。因此这些消息可以被分组成web 服务。消息系统可以将发给该服务的活动的消息路由到执行该流的连接器。一 些操作可以具有开始一个新过程实例的语义。发给这些操作的消息会产生新的 过程实例。对其它到达消息，连接器中的调度器通过基于有效载荷内容、过程 实例的状态(如果该过程实例处于等待发往特定操作的特定消息的步骤上)或 在消息包络中的消息相关数据(当到达消息是对先前送出消息的异步响应时很 有用)来推断出该实例，可以将该消息链接到现有的过程实例。
按照分布方式在多过程引擎610、 620、 630、 640中执行的过程流可以被 看成一组相互交互的协作服务，其中这些过程引擎在它们之间传递其内部状态。
本发明的另一个方面是可选的在^皮调用之前请求订购服务。在服务订购期 间，对于协作服务，可以选择其中一个可能的安排，并由消费者和提供商协商 其使用。该服务的其它方面可以在订购时协商，如访问控制。
面向服务的访问控制具有3个关键概念，它们一起工作来提供可管理性并 加强对服务和服务中的活动/操作的访问服务可见性、服务订购和服务优先级 或授权。服务可见性允许服务提供商指定谁能发现该服务，并允许发现机制来 基于该可见性限制发现。服务可见性规则可以包括任何人可见、管理员/操作 员可见、团体中的指定团队可见、团体中的指定角色可见、网络中的任意团体 可见、或网络中的指定团体可见。可见性也可用于协作团队(有时称为贸易团 队或伙伴)。当一个团队登录到该团体时，默认情况下该团队在该团体中可见。 另外，该团队可以对网络中的任意团体可见，或者对网络中的指定团体可见。服务和团队信息还可以基于指定的可见性规则推入公共UDDI记录中。
对于每个服务活动，还可以在订购时(或默认)建立一组优先权。对于每 个服务，应用可以指定作为优先权组的服务角色。对于一个优先权，可以指定 附加的细节，例如"该优先权是否支持特定组织单元的范围"和"该优先权是 否只能用作服务角色"等等。服务可以指定是否请求在某人使用它之前进行某 种订购。例如，供应商可以指定在一个订购管理力良务中，买家只能在订购之后 向该服务发送订单。订购过程允许服务提供商接收关于订购团队的信息，以及 需要时订购服务的能力。基于这些消息，服务提供商可以选择赞成或拒绝该订 购。
一旦团队管理员订购了服务，他们就在他们自己的组织内通过分组服务角
角色,A 、^ 、 、 、，、' 、
另一个支持经过安排的交互的主要挑战是后台办公系统。使用服务合成代 理可以针对与后台办公系统综合关联的问题。后台办公系统通常不理解支持经
过安排的会话的SOAP扩展，包括支持消息相关和返回地址描述的扩展。因此， 使合成代理展示双向映射到后台办公系统的简单web服务界面的协作web服务 界面是有用的，如图7所示。合成代理通过对照有效载荷执行规则将相关消息 相互关联，并从来自应用的对等调用消息中推导出应用的返回地址。后台办公 系统不同地展示他们的功能，从而通常对每个后台办公系统都存在一组不同的 服务定义。合成代理通过将多个升级的后台办公系统放在一个界面上而简化了 对该多个升级后台办公系统的跟踪。合成代理选择正确的后台办公服务和行为。 后台办公系统当它们被用EAI界面扩展时支持多种XML文档定义。例子包括 xCBL、 IDOC、 OAGI等等。本发明的方面允许将这些采用该多种定义语言定 义的文档看作一个文档系列的成员。可以调用翻译逻辑，以便在文档系列成员 之间来回转换消息。至后台办公系统的EAI界面通常不支持精确的安全性、可 靠消息发送等。合成代理可以支持它本身和查询服务之间的安全性、可靠性等。 合成代理可以采用较少鲁棒和安全的方案，它们能用于后台办公系统和最后一 个本地连接器之间的最后一次跳跃(hop),或采用特殊的安全和可靠措施。
合成代理服务可以对与后台办公系统之间的、包括由后台办公系统启始的 会话支持逻辑路由(通过有效负荷检查和/或记录查找的目标地址选择)。图7 示出消息关联。非安排使能的系统710 (例如后台终端系统)与使能过程或合 成的代理720通信。部分通过在合成代理721、 722、 723接收的消息内指定字段来配置通信。消息相关逻辑724可以用于将消息与新的或正在进行的安排725 相关联。该安排可以如上所述模式化为内部过程。相关逻辑724可以定位在消 息流中，以按照其被接收的样子来处理每个来自后台终端系统的消息。或者相 关逻辑可以是过程流725中的过程步骤可以访问的资源。相关逻辑724的定位 比其如下行为次要检查由后台办公应用界面产生的消息，并使用字段的描述 将后台办公消息与安排实例相关联。相关逻辑可以扩展到由后台办公系统初始 化的会话。当该相关逻辑确定消息源总是初始化会话，或确定不存在与消息中 的指定字段相关的会话时，相关逻辑可以告知需要创建新会话实例。相关逻辑 还可以使用指定字段来确定应当调用哪个安排。例如，后台办公系统可以初始 化供应商订单。供应商名称字段可以用于标识正确的CP和该CP用来接收新订 单的服务。可以调用与该服务关联的安排。将合成代理720通过标准界面726、 727展示给可以进行安排的服务730。 一个或多个服务可以通过服务界面与合成 代理交互。合成代理和关联逻辑跟踪经过安排的会话的状态，并将与后台办公 系统710交换的消息关联到用于与其它服务730交换的消息中的合适会话ID。 本发明的另 一方面通过由主机特许的多个别名将一个主服务展示给服务 经销商。和实物贸易中的经销商不同，不期望这些经销商对主机的身份进行广 告。在某种意义上，这些服务经销商更像OEM商品中的专有标签。被特许的 服务可以记录，以便与其它服务交互，或者路由到主机支持的一个或多个后台 办7>系统。
图8和图9帮助区分常规非特许的服务和特许服务。在图8中，两个服务 811、 812出现在服务810的记录中。在非特许的情况下，这些记录项提供对应 于同一服务逻辑的两个不同实例831和832的逻辑地址。服务逻辑的这些实例 就像在两个不同web服务器上运行的两个得到许可的服务器基础设施软件的拷 贝。在图9中，3个特许服务911、 912、 913出现在服务910的记录中。这些 特许服务具有不同的逻辑地址。所有逻辑地址都逻辑地连接到主服务921,后 者没有按照与特许服务相同的方式通过记录来展示。发送到不同逻辑地址的消 息在不同的语境中，对应于3个特许服务的经销商。利用由特许服务911、 912、 913和主服务921之间的逻辑关系设置的语境，特许主服务921的特许商可以 采用主逻辑931的一个实例，而不是对每个注册的服务都运行逻辑831、 832 的实例。
考虑其中市场操作员主办订单管理应用(服务的集合)的用例。 一组供应商特许该主服务包来管理所有订单。在这种情况下，发往经销商的消息指向
<franchisee CP>、 <service definition)、 <activity definition〉。 UI和文才当交牙灸月良务 都被特许。在实际术语中，实施特许服务的一个实施例包括如下步骤l.创建 服务的主实例。2.通过收集一组主服务创建主包。该主实体是该包的拥有者。 同样该包受到其中驻留实际实施例的连接器的制约。3.将主包与经销商订购的、 允许该经销商处理所接收文档的一组服务关联。这允许一个或多个经销商特许 该主包。步骤1和2在某些环境中应当由团体管理员完成，而步骤3可以由服 务供应商完成。
特许协作服务可选地可以将记录中的授权委托给主服务CP。这么做的一 个原因是经销商不希望采用经销商的证件，因为该经销商不希望完全表明它本 身的身份。在这种情况下，对于来自该服务的所有消息，经销商将授权委托给 主CP。
特许服务类似于"穿过(pass-through)"服务，其设置语境并允许所有信 息简单地流向主服务并由该主服务进行处理。特许服务将引用该主服务，并通 常会从该主服务那里继承实施能力和策略，根据业务需要收取一些佣金。优选 地，不存在直接受特许服务约束的实现。如果需要定制，优选提供多个主服务 变形。或者，多个安排可能得到一个主服务和为特定的特许服务而受支持的安 排的子集的支持。发给经销商的消息指向<franchisee CP> 、 <service defmition> 、 <activitydefinition>,就像该经销商正在操作一个孤立的服务。服务消费者可以 相互交换地订购，并使用常规或特许服务。与经销商交互的服务消费者不会看 见特许和非特许服务之间的任何差异。
主服务包由通常通过主应用来实施的所有服务组成。单个主应用可以公布 多个主包。在多数情况下，主应用会公布一个主包。绑定主服务包的服务可以 分组为两种类型。 一类主服务包是代表经销商"再提供"为特许服务。另一类 包括由经销商用于处理通过特许服务接收的信息的门户(或UI)服务，但并不 再提供或展示在该经销商之外。例如，订单管理包可以具有基于"接收的订单" 服务的标准，还具有诸如"查看订单"、"订单报告"、"批准订单"等等的其它 UI服务。当经销商签约以特许该订单管理包时，他需要不仅能通过基于文档交 换服务的标准接收订单，而且能查看并批准这些订单等等。主包具有成为该包 中每个发送或接收消息的服务的默认连接器的包连接器。
启动经销商和主供应商之间的业务过程，以便允许该经销商在需要时利用
16在线批准过程在线地特许主包。当服务供应商特许该主包时，自动创建一个特 许服务并向该包中的每个主服务记录为"穿过"。此外，当经销商登录时，该经 销商还自动订购(并因此被授权使用)该包中的其它订购服务。
可选地，特许服务可以将授权委托给主服务，如前所述。在一个实施例中，
涉及将授权委托给主服务的实际步骤可以包括l.创建服务的主实例(通常只 有文档交换服务)。2.创建将会被经销商用作包的一部分的常规服务。3.创建主 包以及指定将会作为由经销商提供的而被启动的主服务集合。4.关联为主服务 发送/接收消息的主包的连接器。5.关联由经销商订购的一组服务，该服务允许 该经销商处理所接收的文档。6.主供应商可以对该包指定请求特许时是否需要 批准。7.主供应商可以指定是否对该包允许委托授权。在经销商那里l.经销商 请求特许主包。如果由主供应商请求则触发批准过程。2.主供应商接收通知来 批准该请求，或者批准或者拒绝该请求。3.如果主供应商批准该请求，则系统 创建一个特许包、对该包中订购服务的订购、以及用于该包中能被特许的服务 的特许服务。
为便于理解特许服务，考虑面向提供商的订单管理系统。对于这里的讨论， 该系统称为SOMS(提供商订单管理系统)。SOMS提供可以被提供商用于从买 家那里接收订单的订单管理系统。在一个实施例中，以下步骤可以包含在设计 和设置SOMS中。设计者将待公布的服务分为将被经销商特许的服务组(例如 接收订单、检查订单状态等等)、将被经销商使用(或消费)的服务组(例如查 看订单、批准/拒绝订单、订单统计/报告等等)以及其中应用提供给诸如集成 了其它应用或后台办公系统的A2A (应用到应用)的集成的服务组。(例如集 成了用户管理系统、公共登录、目录系统等)设计者判定是否所有经销商都将 具有相同的服务集或是否将来需要不同的子集。基于该需要识别一个主服务包 或多个主服务包，或者，识别多个相同服务的安排。主服务包应当包含"待特 许，，的服务和"由经销商使用"的服务。其它用于集成的服务通常记录为常规 服务，具有作为应用的cp或主供应商。在团体环境中，主供应商通常是团体搡 作员，但他也可以是该团体中的任意协作团队。在设计时应当注意，"待特许" 服务实际上是代表多个服务供应商接收和发送的消息。因此应用业务逻辑需要 将该消息中的地址用作处理这些消息的语境。主服务实现应当查看到达的消息， 以找出接受者CP并触发/映射到合适的业务过程。对于被UI触发的业务过程， 主服务应当将经销商CP看作过程语境的输入，并将该CP用于该过程内的委托
17策略。
在设计和编码之后，至少在一些实施例中需要记录样本SOMS服务。在附 图中用若干建立屏幕示出记录被特许的服务、记录被经销商使用的服务、以及 记录主服务包本身。记录的一部分是记录待特许的主服务。在一个实施例中， 记录管理器UI用于为该服务创建一个新服务定义(如果不存在)。然后验证连 接器是否可用于应用。这可以是可用于经销商的默认连接器，也可以是记录到 该经销商应用的单独连接器。同样验证是否在记录中加载了任何所需要的文档
标识符。然后如下创建主服务。图10是管理主包屏幕。点击"Register New" 1001 (新记录)。图11示出记录新主服务的部分。选择服务定义1101。选择操 作符party作为"Providing Party"(提供团队)1102或使用另 一个团队作为合适 团队。指定服务信息1103,保持"Application Instance Name"(应用实例名) 和"Application Service Identifier"(应用服务标识符)空白。可选地，指定应当 与该服务关联的任意服务类1104。选择受该服务1105支持的安排，以及优先 顺序。将visibiliry (可见性)1106设置为默认设置，即"Visible to All Parties in Community"(团体中的所有团队都可见)。选择所支持的文档交换活动1107， 并使用图12的屏幕来编辑该活动。创建优先权1201。保持"Messaging Policies" 1202 (收发消息策略)为默认，除非应用需要特殊的发送接收处理。对于输入 1210和/或输出1220消息，将输入和加密策略1213、 1223设置为"需要"。编 辑所需要的部件1214、 1224,并指定受支持的文档标识符的有序列表。添加可 能公布在记录中的可选消息部件。利用诸如图13的屏幕，验证或修改如下策略 将异步发送接收1301设置为"是"。将"授权模式"1302设置为"文档单签名 (single sign-on)"。将"授权机制"1303设置为"用户名/密码"。然后可选地， 指定任意服务角色1304。点击"提交/存储 "1305来记录该服务。
记录的另一部分是记录由经销商使用的常规服务(与主服务相对)。这以 web服务开发常见的方式进行。
利用图14的屏幕还记录主服务包。在"记录新主包"屏幕，指定包名1401 和描述1402。
指定应用名1403。将操作符party拾取为"主服务供应商"1404,或使用 另一个团队作为合适团队。指定服务信息(保持应用实例名和应用服务标识符 为"空")。如果特许该包需要获得批准则进行指定1405。如果为"是"，则当 CP特许该包时将触发批准过程。指定应用连接器1406。如果允许经销商将授权委托给主服务供应商则进行指定1407。在由主服务供应商提供的主服务列表
之外选择由经销商特许的服务1408。在由主服务供应商提供的常规服务列表之 外选择由经销商订购的服务列表1409。点击"存储"1410来记录该主服务包。 经销商还记录选择新包来从图15的屏幕中进行特许。通过选择单选按钮 1501和点击"选择"1502来选择一个或多个主包。图16的屏幕变成可以访问。 经销商的选项有限，因此设置是简单的。在另一个实施例中，经销商具有涉及 可提供和/或可订购的服务的选项，尤其是在经销商再提供了该服务的情况下。 决定授权是否使用经销商的证件或委托给主人1601。编辑一个或多个待提供的 服务1602,以满足所指示的对编辑的任意需要1603。选择"提交"1604来为 处理提交该特许。
当编辑服务详情时，图17的屏幕变成可访问。在一些实施例中，所呈现 的很多细节都只能由主人(host)编辑，而不是经销商。这可以通过将图17与图 11和图13进行比较看出。所呈现的一些细节按照主人将该细节用于经销商的 相同方式用于下游用户，其中服务将再提供给这些下游客户。图11的描述通用。 此外，如上所述可以建立哪个组优先的服务角色。
经销商可能订购的一些服务是门户服务。门户服务(UI服务)是通过门户 访问的服务。这些就是通过应用展示的、使得用户可以与应用交互的服务。这 允许用户面向il良务地查看应用。特定用户可以与来自不同应用的服务交互，还 可以与/不与来自一个应用的所有服务交互。在任何情况下，管理员对整个应用
的经验、访问控制/优先权、单签名、导航等等都是一样的，并且基于服务模板。 门户服务可以没有服务定义(还不存在标准。虽然本实施例没有要求门户 服务具有服务定义，但可以预想将来门户服务将有服务定义)。门户服务具有都 可以通过门户访问的记录活动的列表(需要时还具有URL)。对于活动，使得 可以访问该活动的优先权列表也被指定。此外，诸如web代理和加密资源路径 的单签名(SSO)信息也为服务或每个活动指定。通过将报告组/文件夹记录为 活动，也可以通过门户服务启动对报告的访问。
当UI服务标识为记录给应用时，考虑若干因素是很用的。考虑目标用户 或团队。应用界面被设计成可由不同的目标用户使用。例如，特定UI用于管理 员，特定UI用于买家，特定UI用于提供商等等。这些角色不同的UI应当是 单独的服务。考虑是否特定界面只针对特定提供商或买家。例如，你可能希望 只为高级提供商启动附加功能。将这些功能置于单独的服务中。如果你具有很多针对一个目标组(例如提供商)的服务，则考虑创建服务 订购包，以便为了方便用户而将这些服务分组。协作团队订购一个服务，在这 个团队中的用户被授以该服务内特定的优先权。这意味着整个团队的优先权和
活动不应当混合。例如，买家提交RFP而卖家响应RFP的优先权应当在两种不
同的服务中。
对于门户服务，可以关联特殊的显示目录。该显示目录在门户上为该服务 预留了一个标记。很多门户服务可以位于一个显示目录中。显示目录与应用指
定的服务室URL关联。通过记录该服务室URL,应用对服务如何在该标记内 提交给门户保留完全的控制。如果你希望自己的应用作为多显示目录提交，则 基于服务关联的显示目录来标识该服务。
优选地，服务、活动、优先权和web代理之间的关系如下l.服务可以具 有一个或多个活动。2.活动可以与零个或多个优先权关联。3.优先权属于服务并 且在该服务内是唯一的。4.优先权可以与同一服务内的一个或多个活动关联。 5.服务可以与处理单签名(SSO)的默认web代理以及可通过该服务访问的web 资源路径列表关联。6.该服务中的每个活动都可以与该服务web代理关联，或 者用另 一个web代理来代替。还可以指定对活动特殊资源路径的访问。
在标识UI服务中的活动和优先权时考虑若干因素是很有用的。l.一个服务 中的活动和优先权应当作为协作团队中的目标。这意味着整个团队中的优先权 和活动不应当是同一服务的一部分。此外，买家提交RFP而卖家响应RFP的优 先权应当在两种不同的服务中。2.不希望将应用中的每个链接都记录为UI服务 中的活动。如果需要访问控制，则这些可以记录为优先权。3.在简单的情况下， 门户服务可以只记录一个活动和一串优先权。例如，"拍卖投标"服务具有一个 活动"投标"，具有一组允许特定投标功能的优先权。基于分配给用户的优先权， 应用可以选择提交完全不同的页，或启动了不同选项的相同页。如果对这些活 动的链接由其它应用/服务启动，则用户可以能希望记录更细微的活动，包括 URL，从而这些活动可以通过记录来找到。例如，目录管理可能希望记录"搜 索目录，，活动，包括"管理目录"活动。"搜索目录"活动可以展示为在获得屏 幕、源屏幕、合同管理屏幕、以及管理目录屏幕上的链接。5.如果服务中的特 定链接驻留在不同的应用服务器或web服务器上并需要单独的web服务器来保 护，则这些链接或者分组为单独的服务，或者记录为同一服务中的不同活动。 (例如，可能在与其它目录服务活动不同的web服务器上运行的产品配置活动)。
虽然本发明通过参考上面详细描述的优选实施例而被公开，但应当理解， 这些示例是说明性的而不是限制性的。从前面的描述中，本领域的技术人员可 以知道从本发明的方面和部分中可以构建广泛的系统和方法。在所描述的实施 例中隐含计算机辅助处理。因此，本发明可以实现在用于计算机辅助处理的方 法中、包括逻辑来实现该方法的系统中、具有逻辑来实施该方法的介质中、具 有逻辑来实施该方法的数据流或计算机可访问的处理服务中。本领域的技术人 员可以设想在本发明的精神范围内的修改和组合。
2权利要求
1. 一种确定具有一个或多个与标准兼容界面的服务实体的版本的方法，该方法包括维护服务的服务版本，其中，所述服务版本向基本服务添加可选操作；维护标识由所述服务实体支持的服务版本的记录数据；访问该记录并确定由服务实体支持的服务版本；以及使用所支持的服务版本与服务实体进行消息交换。
2. 根据权利要求1所述的方法，其中，该方法适用于多个服务实体接 口定义i吾言。
3. —种确定具有一个或多个与标准兼容界面的服务实体的版本的方 法，该方法包括维护服务的服务版本，其中，所述服务版本向基本服务添加可选操作； 向不依赖于由服务实体支持的服务版本的服务实体发送第 一消息； 从该服务实体接收标识其支持的服务版本的响应；以及 使用所支持的服务版本进行与该服务实体的消息交换。
4. 根据权利要求3所述的方法，其中，所述服务实体的各个版本基本 上使用同一第一消息。
5. —种用于将由多个非安排使能的界面产生的消息与对应于一个安排 实例的会话标识符相关的机制，包括映射到多个产生缺少安排会话标识符的消息的应用界面的内部过程流;由该应用界面产生的消息中的字段的说明，用于将该消息与安排实例相关；以及检查在内部过程流接收的来自应用界面的消息、应用该字段说明、并 将消息与对应于安排实例的特定会话标识符相关的逻辑和资源。
6. —种用于将由多个非安排使能的界面产生的消息与对应于一个安排 实例的会话标识符相关的机制，包括在一个或多个安排使能的界面与多个产生缺少安排会话标识符的消息 的应用界面之间的映射；由这些应用界面产生的消息中的字段的说明，用于将该消息与安排实例相关；以及检查从应用界面接收的消息、应用该字段说明、将消息与对应于安排 实例的特定会话标识符相关、并在安排使能的界面上展示的逻辑和资源。
7. —种从缺少会话标识符的非安排的消息中组成包括会话标识符的安 排的消息的方法，该安排的消息展示在第一界面上，该非安排的消息在第 二界面上从多个第三界面接收，所述方法包括在由第三界面产生的消息中指定用于将由该第三界面产生的非安排的消息与安排实例相关的字段；在第二和第三界面之间交换消息时维护特定安排实例的状态信息；使用该字段说明和该状态信息来将在第二界面上接收的特定非安排的 消息与对应于特定安排实例的会话标识符相关；在该第一界面上展示该非安排的消息的至少一部分以及会话标识符。
8. 根据权利要求3所述的方法，还包括在运行时 确定中介代理和请求实体使用的消息安排的版本； 确定中介代理正使用的服务版本；以及确定在消息交换中由中介代理和请求实体使用的文档版本并在文档版 本之间进行翻译。
9. 一种将宿主服务别名为多个特许服务的方法，该方法包括 将一个或多个特许服务登记为具有不同逻辑地址的万维网服务； 提供一个包括逻辑来检查通过这些特许服务接收的消息的宿主万维网服务，以确定这些消息的语境；以及将这些特许服务配置为将接收的消息传递到宿主万维网服务。
全文摘要
本发明涉及一种展示过程流以及作为万维网服务的安排控制器，涉及支持文档交换安排(choreography)的基于计算机的设备和方法。具体地说，本发明的一些方面涉及便于通过安排版本、服务版本和文档版本的各种组合来升级系统的设备和方法。本发明提供采用安排代理的安排管理器，并向非安排使能的应用提供安排使能的界面。本发明的其它方面包括图形设计工具和将主机服务透明地别名为多语境设置特许服务。
文档编号G06Q10/00GK101471961SQ200810179599
公开日2009年7月1日 申请日期2003年8月21日 优先权日2002年9月18日
发明者拉古纳思·萨普拉姆, 拉姆申卡·文凯特, 文凯什·O·梅塔, 杰亚拉姆·R·卡西 申请人:开放创新网络有限责任公司