CN102262761B - 用于代理服务交付的服务交付管理 - Google Patents

Abstract

公开了一种代理消费者网关，该代理消费者网关可以与消费至少一个服务提供者的至少一个服务的计算设备的服务消费者接口，包括接收表单请求、提供表单、以及接收提交的表单。服务交付管理器可以交付至少一个服务。服务交付管理器可以包括：消费者会话管理器，其创建至少一个消费者会话以执行至少一个服务的至少一部分；消费者实例管理器，其创建至少一个服务的至少一个实例；以及服务协调器，其被配置成基于协调模型协调至少一个服务的交付，所述协调模型表现至少一个服务的特征，其中所述表单与至少一个服务的服务状态相关联，并且其中基于提交的表单执行在服务状态之间的转换。

Description

用于代理服务交付的服务交付管理

技术领域

本发明涉及代理服务(brokered service)交付。

背景技术

商品和服务的代理是一种历史悠久的促进商业的技术。尽管形式众多，但代理共享这样一种认识：商品和服务的提供者通常不愿或不能从事发起、处理或完成与一个或多个消费者交易所需的工作。例如，商品制造商可能宁愿关注于制造过程，因此可能与代理商订立契约，由代理商负责定位所制造商品的购买者并负责处理和完成对购买者的商品销售。当然，典型地，代理商为提供这些代理服务而收取购买价格的一定份额或其他一些费用或付款。这样，制造商(或其他提供者)和代理商可以专注于发展他们各自专长的领域。

在计算机、网络以及软件领域，代理(broker)已将这些一般概念用于例如通过因特网交付商品和服务。例如，代理可以提供一个市场(marketplace)，在市场中不同的提供者可以出售他们各自的商品和/或服务。例如，诸如书籍的“真实世界”物品的提供者(例如，出版社)可以利用代理来销售书籍。类似地，也可以存在帮助销售数字内容(例如，歌曲或电影)和/或帮助销售软件应用等等许多待售物品的代理。

然而同时，软件已经从单机的、集成的、单体的应用演进为离散的服务，所述离散的服务往往在按照需求的基础上提供特定的功能(或者进行组合以提供希望的功能)。从概念上讲，几乎任何软件功能都可以作为服务例如通过因特网或其他网络来提供。此外，不同的服务——可能是来自不同来源的不同服务——可以组合或一起销售，以用于例如提供聚合的功能和/或用于提供有竞争力的服务绑定，以吸引用户进行(额外的)购买。

从而，在理论上，代理和软件服务的交集(intersection)在概念上是简单明了的。也就是说，软件服务提供者(这里称为服务提供者)可能与其他提供者一样希望获得通过代理提供他们的(软件)服务所带来的好处。在一些情况下，例如当软件在概念上类似于离散的商品(如上面提到的数字歌曲或电影的例子)时，代理服务的实现也是简单的。具体地说，例如，代理可以获得销售所讨论软件的权利，并且可以定位该软件的客户，或者处理和完成销售。

然而，实际上，传统上许多服务很难或不可能作为代理服务交付方案的一部分来交付，至少无法以任何标准的或广泛应用的方式进行。例如，可能存在一种软件服务，其由市政府或其他政府实体提供给潜在的小型企业主，用于发起和注册某种业务许可。这些以及其他类似的服务可能是复杂的、长期的过程，需要很多天或更久时间来执行，并且可能由用户通过多个通道(例如，不同的用户设备)进行访问。此外，这样的多步骤服务可能在服务提供者的后端(例如，遗留)应用上执行，并且可能需要与服务提供者和/或其他利益相关者进行多次交互/接口。而且，当服务被组合或联合以交付给单个用户时，联合而成的整体或这些服务的交互可能由于各种技术上和/或商业上的考虑而十分复杂，特别是当要组合的服务由不同的服务提供者(例如，具有不同后端遗留系统的不同企业)提供时。

代理服务的服务交付包括实际运行时间、代理服务的执行、以及可能相关的功能(例如，付款收取)。在服务交付期间，服务代理可以充当简单的中介(intermediary)：提供对于所讨论的服务提供者所托管的(hosted)、用于执行服务的各种后端应用的中心访问点。这样的交付模型通常意味着对服务代理仅有最低要求，而将保证服务提供者各自服务的互操作性(彼此之间的互操作性以及与用户的互操作性)的责任留给了服务提供者。相反，服务本身也可以直接由服务代理托管；然而，由服务代理来适应和执行不同用户可能希望的全部各种服务(以及他们的组合)可能是不实际或不可能的。而且，当代理上面提到的那种多步骤、多提供者、长期的、复杂的服务时，这些困难可能特别尖锐。

简而言之，不存在能以平衡(leverages)所涉及各方的相关资源和专长领域的可行方式交付代理服务的令人满意的解决方案。因此，服务提供者使其服务商业化的能力降低，服务代理不太能够代理这样的服务，而消费者则需容忍他们想要使用的服务的市场较为受限且访问点较少。

发明内容

根据一个一般方面，包括存储在计算机可读存储介质上的指令的计算机系统可以包括：代理消费者网关，其被配置为使得至少一个处理器与消费至少一个服务提供者的至少一个服务的计算设备的服务消费者接口，包括接收表单请求、提供表单、以及接收提交的表单；以及服务交付管理器，其被配置为使得所述至少一个处理器交付所述至少一个服务。所述服务交付管理器可以包括：消费者会话管理器，其被配置为使得所述至少一个处理器创建至少一个消费者会话，在所述至少一个消费者会话期间执行所述至少一个服务的至少一部分；消费者实例管理器，其被配置为使得所述至少一个处理器在所述至少一个消费者会话内创建所述至少一个服务的至少一个实例，所述至少一个实例与所述至少一个服务的用户相关联，以及服务协调器，其被配置为使得所述至少一个处理器基于协调模型协调在所述消费者会话和所述消费者实例内的来自所述至少一个服务提供者的所述至少一个服务的交付，所述协调模型表现所述至少一个服务的特征，其中所述表单与所述至少一个服务的服务状态相关联，并且其中基于提交的表单执行在所述服务状态之间的转换。

根据另一个一般方面，一种计算机实施的方法包括执行存储在计算机可读存储介质上的指令，该方法可以包括：与消费至少一个服务提供者的至少一个服务的计算设备的服务消费者接口，由此执行所述服务到所述服务消费者的交付，包括接收表单请求、提供表单、以及接收提交的表单。所述方法还可以包括：创建至少一个消费者会话，在所述消费者会话期间执行所述至少一个服务的至少一部分，在所述至少一个消费者会话内创建所述至少一个服务的至少一个实例，所述至少一个实例与所述至少一个服务的用户相关联；以及基于协调模型协调来自所述至少一个服务提供者的并且在所述消费者会话和所述消费者实例内的至少一个服务的交付，所述协调模型表现所述至少一个服务的特征，其中所述表单与所述至少一个服务的服务状态相关联，并且其中基于提交的表单执行在所述服务状态之间的转换。

根据另一个一般方面，一种计算机程序产品有形地体现在计算机可读存储介质上，并且可以包括可执行代码，所述可执行代码在被执行时，被配置为使得至少一个数据处理装置：与消费至少一个服务提供者的至少一个服务的计算设备的服务消费者接口，由此执行所述服务到所述服务消费者的交付，包括接收表单请求、提供表单、以及接收提交的表单；创建至少一个消费者会话，在所述消费者会话期间执行所述至少一个服务的至少一部分；在所述至少一个消费者会话内创建所述至少一个服务的至少一个实例，所述至少一个实例与所述至少一个服务的用户相关联；以及基于协调模型协调来自所述至少一个服务提供者的并且在所述消费者会话和消费者实例内的所述至少一个服务的交付，所述协调模型表现所述至少一个服务的特征，其中所述表单与所述至少一个服务的服务状态相关联，并且其中基于提交的表单执行在所述服务状态之间的转换。

在附图和以下描述中详细地阐述一个或多个实施方式的细节。其他特征将从说明书和附图、以及从权利要求中变得清楚。

附图说明

图1是用于提供代理服务交付的系统的框图。

图2是示出图1的系统的示例操作的流程图。

图3是示出图1的系统的示例操作的第二流程图。

图4示出代理消费者网关接口的例子。

图5示出消费者会话管理器接口的例子。

图6示出可以由图5的消费者会话管理器管理的消费者会话对象的例子。

图7示出类图(class diagram)，该类图示出会话记录(logging)的例子。

图8提供服务组管理器接口的示图。

图9示出服务组对象，其被示出为类图，可以代表用户保存零或多个服务实例。

图10示出消息日志的例子。

图11是示出与服务实例管理相关的技术的框图。

图12是协调模型的框图。

图13是付款管理器接口的例子。

图14提供样本付款管理器接口，示出为类图。

图15是示出创建消费者会话的顺序图。

图16是示出用户请求新的服务实例的顺序图。

图17是示出服务实例要求用户认证的顺序图。

图18是示出为认证的用户添加新的服务组的顺序图。

图19是示出在服务组之间移动(movement)服务实例的顺序图。

图20是示出删除空服务组的顺序图。

图21是示出删除非空服务组的顺序图。

图22是示出与服务实例交互的顺序图。

图23示出处理消费者交互的框图。

图24是示出获得用户交互的表单的技术的顺序图。

图25是示出表单提交和相关动作的顺序图。

图26是示出为多个服务实例共同地处理服务付款的例子的顺序图。

具体实施方式

图1是提供对代理服务交付的服务交付管理的系统100的框图。在图1的例子中，服务提供者102表示服务提供者102希望通过服务代理104向一个或多个消费者计算设备106a、106b提供的一个或多个服务的拥有者、开发者、销售者、或者其他提供者。如这里详细描述的，服务代理104提供了用于服务交付管理的明确的、专用的平台，其实现了复杂的服务交付模型，从而支持长期的、多会话服务组的运行时代理(run-time brokerage)，所述服务中的一些或全部可以由不同的或者不兼容的服务提供者来托管。

更详细地，服务提供者102可以表示几乎任何希望销售或提供对服务的访问的实体，包括，例如，商务软件供应商、银行/金融公司、保健服务供应商、法律实体或者市政府或其他政府部门。服务可以表示用于例如单机消费品的例如可执行代码，诸如如这里所描述的可以经由因特网浏览器提供给购买者的单机消费品。在更具体的例子中，服务可以包括，例如，小型业务创建服务、财产转让服务、或者预订通行证(ordering passports)的服务，等等。可替换地，服务可以表示用作基础或组件服务的服务，即它们中的每一个将与其他服务相组合以提供合成的功能(composite functionality)，这种合成的功能被展示给消费者计算设备106a、106b。

在图1中，服务代理104可以利用业务流程外包(BPO，business processoutsourcing)提供者108以允许例如外包非核心操作或其他功能，以减少服务代理104的总体拥有成本。例如，BPO提供者108可以提供服务代理104所使用的服务，诸如收费/付款(billing/payment)服务，或者更加一般地，BPO提供者108可以提供服务代理104的硬件资源(例如，存储器、处理能力)的外包。以下，更详细地描述BPO提供者108的其他示例。

在实践中，服务提供者102可以在服务注册表110内注册和装载服务，这意味着，例如，服务的交付和执行可以通过服务代理104来进行。当BPO提供者108提供由服务代理104平衡的附加服务时，当需要时，这样的服务也可以在服务注册表110内注册和装载。

当以这种方式注册服务时，服务调节器112可以用来保证服务的服务接口以与服务交付管理器114的服务交付模型一致的方式来展示，这里将对此详细描述。一般而言，这样的服务调节可以包括从给定服务接口到状态和状态之间的转换的一般描述(genericdescription)的映射或者其他变换，其中所述状态被表现为将被消费者计算设备106a、106b的用户请求、填写以及提交的表单(和/或表单模板)。通过这种方式，如这里所描述的，服务交付管理器114可以中介(mediate)服务的交付，包括以服务生命周期的执行期间的任何给定点所需要的具体方式调用表单。

在这里描述的具体的例子中，服务调节器112可以使用所讨论的服务的服务接口的模型，来生成表示状态(表单)以及状态间转换的可扩展标记语言(XML，eXtensibleMarkup Language)文件，由此该文件允许以与下层服务一致的方式进行服务交付，包括防止所讨论的服务的死锁和/或活锁，即使在来自异类的(disparate)服务提供者的多个服务被结合、绑定(bundled)、或者以其他方式组合在一起时也是如此。

一旦服务已经以这种方式注册，服务交付管理器114变得可以将服务的中介供给(provisioning)提供给消费者计算设备106a、106b。如图1所示，服务交付管理器114可以提供代理消费者网关(BCG，broker consumer gateway)116，其可以被配置成经由相应的通道118a、118b与消费者计算设备106a、106b通信。在这个上下文中，术语通道可以包括通信的任何模式或类型，并且举例来说，可以例如通过消费者计算设备106a、106b的类型(例如，智能电话、台式计算机、膝上型计算机或上网本、或者他们的具体的品牌/型号)来定义，或者可以通过居间的计算机网络的性质来定义，或者可以通过在消费者计算设备106a、106b上执行的软件(例如，特定的操作系统)来定义，或者可以通过消费者计算设备的用户的偏好来定义，等等。

在图1的例子中，浏览器120被示出为由消费者计算设备106a执行。服务消费者122表示服务交付管理器114的一个方面或由服务交付管理器114使用的组件，服务交付管理器114通过代理消费者网关116促进服务的中介(mediation)或其他交付，以便实现应用124的(增强的)执行。更具体地说，服务消费者122了解代理消费者网关116的具体的消息接口(messaging interface)，从而服务消费者122和代理消费者网关116一起提供了对于下层服务的代理服务器(proxy)，从而去除或减轻了浏览器120、应用124、或服务注册表110内的其他服务对相关知识的要求。以下提供代理消费者网关116的详细示例以及在代理消费者网关116和服务消费者122之间的消息接口的详细示例。

在具体示例中，服务提供者102可以包括不动产公司和抵押/贷款提供者，它们可以是分离的企业，分别托管自己的后端版本的相关服务，这些服务可以通过因特网或其他网络提供。不动产公司可以提供给其服务做广告的网站，并且可能希望联合其已有网站提供申请住房贷款的服务。在图1的系统100中，贷款服务可以在浏览器120内提供给用户，例如，体验为应用124，在应用124中，用户提交各种类型的相关信息并接收作为答复的关于可能的住房贷款的信息。

当然，已经存在众多与提供住房贷款有关的服务的例子，并且这些服务通过因特网上提供，例如，直接由抵押/贷款提供者本身提供，可能是在它们自己的网站上。然而，系统100提供在服务代理104的上下文中的、用于将住房贷款服务与不动产公司提供的服务整合的技术。因此系统100提供上述平台，用于以直接的、一致的、可靠的方式明确的支持代理服务交付，并且考虑了服务的代理(特别是由异类的服务提供者提供的长期的、有状态的(stateful)服务)不同于其他商品代理的各个方面。

在这种情况下，服务交付管理器114包括消费者会话管理器126，消费者会话管理器126可以被配置成创建和维持与消费者计算设备106a的用户相关联的会话。在一些实施方式中，关于会话的信息可以被存储在会话日志(log)128中，从而，例如，如果用户暂时结束或中止会话，用户也可以稍后继续进行对所讨论的服务的消费。例如，第一会话可以被保存到会话日志128，稍后，同一用户的第二会话可以被创建，并且自动地链接到该第一会话。如以下详细描述的，消费者会话管理器126可以用来提供或促进用于服务的特定实例的执行环境和/或用于在会话内一起执行的服务组的执行环境，以及用于付款及在这个例子中与消费者计算设备106a的用户相关的其他相关代理功能(可能由BPO提供者108提供)的执行环境。

在提供这样的执行环境时，服务协调器130可以用来使用相应的协调模型132跟踪(和推进(advance))每个服务，例如，每个正在执行的服务实例，的当前状态。也就是说，如上面提到且以下将详细解释的，每个服务可以例如被服务调节器112表示为XML文档和/或统一建模语言(UML，Unified Modeling Language)图表或服务的其他适当的表达，可以被表示为协调模型，在该协调模型中给定服务的展示的接口可以被表示为多个状态以及状态之间的转换，并且在该协调模型中多个状态对应于作为执行所讨论的服务的一部分而要与用户交换的表单。以下例如参考图11、12和23提供服务协调器130以及协调模型132的具体例子。

在提供其中一个或多个服务根据相应的基于状态的协调模型被执行的消费者会话时，服务交付管理器114可以包括表单中介器(forms mediator)134，除了其他可能的资源，表单中介器134可以使用多个表单模板136，以便与用户，例如与服务消费者122，交换服务表单。也就是说，表单可以以通用的方式并且结合表单模板来存储或引用，表单模板管理表单的表示逻辑(presentation logic)。然后，在所讨论的服务的执行期间，表单中介器134可以例如基于当前通信通道118a、或基于用户偏好、或基于各种其他因素，实例化通用表单和相关联的模板。例如，通信通道118a可以使用运行特定操作系统的膝上型计算机来表征。表单中介器134在没有具体通信通道118a的先验知识的情况下，仍可以通过消费者122提供适当的表单。此外，如果消费者计算设备106a的用户结束当前会话，然后使用消费者计算设备106b(例如，特定品牌或类型的智能电话)开始随后的会话，则表单中介器134可以在随后的会话内继续执行服务，但是现在是使用适合于新的通信通道118b的表单。因此系统100在代理服务交付的上下文内平衡表单中介，以便结合相关联的协调模型的每个前进的(advancing)服务状态来提供实时的或及时的表单变换。

实例管理器138可以被配置成与服务协调器130和表单中介器134，以及这里所描述的其他实体，在消费者会话管理器126的给定会话内进行交互，以便提供服务注册表110的一个或多个相应服务的一个或多个实例。例如，当执行给定服务的代理服务交付时，第一服务实例可以由实例管理器138使用服务协调器130来创建，该服务实例可以根据具有十个连续状态的相应的协调模型来进行。在第一消费者会话中，第一实例可以进行全部的十个状态并且完成，然后第二服务实例可以被实例化，第二服务实例可以在当前消费者会话结束之前只进行到第五状态。此时，包括处理中的实例的消费者会话可以被存储在会话日志128和/或实例日志140内。稍后，用户可以开始第二消费者会话，在此期间，第二服务实例可以推进到其第十个以及最终的状态，并且完成。因此，更一般地说，在给定消费者会话内，根据相应的协调模型，服务(或者可能的相关服务)的一个或多个实例可以执行到定义的状态，或执行到完成。

在一些实施方式中，服务中介器141可以用来提供对从代理消费者网关116接收的消息的附加翻译，以便与在服务提供者的远程的、后端系统上运行的具体服务通信，所述服务例如没有(完整地或部分地)装载在服务代理104内，和/或对于给定服务实例为了期望的功能而要求单独调用。

付款管理器144可以被配置成添加付款功能(例如，作为提供服务的交换，生成应付金额并收集款项)。就它们自身而言，用于针对通过网络提供的商品和服务收集付款的技术当然是已知的，在这里不进行详细地描述。然而，在代理服务的交付管理领域，收集付款的多个方面还是充满问题的。例如，在传统的电子商务设定中，商品或软件应用可以如此购买：作为支付付款的交换，同意进行一次的或重复的(recurring)交付。在传统的购物车方案中，商品可以累积，并且可以计算一些或全部物品的总额。

然而，在交付一个或多个长期的、有状态的、多步骤的代理服务期间，付款通常不是这样的分立的功能。例如，接收相同服务的不同用户可以以不同的方式体验服务，并由此导致不同的费用。而且，这些服务的不同的组合或分组可以因此导致更加复杂的付款方案。在长期的代理服务中，可能随着时间而接收部分的付款，因此部分付款必须被跟踪，以避免过度计费或计费不足。

以下描述附加的付款方案，但是，总体来说，应当理解付款管理器144以及相关功能代表了设定代理服务的交付管理时所需考虑的附加事项。具体来说，正如刚刚提到的，这些考虑事项可能在以集合、组合、绑定或其他分组的形式提供这些代理服务时出现。

因此，在服务交付管理器114中可以包括服务组管理器142，服务交付管理器114可以被配置成提供这样的服务组的管理和用于这样的服务组的管理，从而可以使用服务组日志148来跟踪和存储所述服务组。例如，服务组管理器142可以在一个或多个消费者会话内或者跨越一个或多个消费者会话来为用户管理这样的服务组，包括例如为特定服务组添加、更新或去除服务实例，或者添加/删除作为整体的服务组。更一般地说，服务组管理器142可以负责实施(enforcing)服务组的许多不同的组级别(group-level)属性，诸如调整与作为整体的服务组相关的用户认证级别。以下将更详细地描述服务组管理器142和服务组日志148的其他方面和特征。

因此，在图1的系统100中，代理服务交付可以以标准化的且可广泛应用的方式来管理，这种方式保证了交付的完整性和一致性，并允许服务提供者102和服务代理104从事他们各自偏好和专长的领域。例如，服务提供者102可以专注于开发和改进其服务，同时允许服务代理104负责交付服务。同时，服务代理104可以相对较少地涉及服务的具体业务方面，而是从事交付服务以及以其他方式使服务商业化方面的工作。

图1还示出了用于代理服务交付管理的示例系统和方法。交付管理提供多通道服务访问、服务实例管理、服务交付配置、对服务的分组访问、收费/付款功能、以及各种安全级别(例如，用户认证)。以下讨论这些以及其他特性，接着是例如在图1的示例的上下文中的用于实现这些特性的具体的示例和技术。

如上所述，对多通道服务访问的需要反映了这样的事实：代理服务交付往往与大容量、广泛受众基础、以及对于新的和无法预期的机会的灵活市场渗透相关联。受众和消费群体的越广，通过其访问服务以及服务与之交互的设定越多样化。不同的设定意味着更多的不同业务通道(例如，用于消费者访问服务的业务应用出口(outlets))。由于不同的设备以及不同地理空间和时间的访问点，不同的设定还需要用来访问服务的不同的技术通道。

为此，所描述的示例以如下方式构建：即，例如使用图1中的表单中介器134及相关结构和功能，允许所述示例的用户接口适应于不同的业务和技术通道。以允许针对不同通道进行灵活变换的方式规定(specified)服务的用户接口——不仅从通道的技术(设备)表现方面，而且从通道的业务语义方面也是如此。如上所述，对于诸如业务形成的交易的服务，与用户的交互可能是长期的，例如，从数天到数月。为了促进与服务的灵活交互，实现了不同的通道，例如，从基于标准浏览器的通道到移动和语音通道。因此，服务用户界面的适用性(adaptation)是动态的，取决于用户交互涉及哪个通道。

在多种多样的设定中多通道服务消费的其他方面涉及与通道相关联的不同环境、平台和语言。对于与支持第三方居间人(intermediary)的系统交互的消费应用而言，对于消费者应用的软件适用性要求被保持在最低限度。例如，服务消费者122可以被部署为进入通道环境的代理服务器，以包含服务交互逻辑以及与居间人的消息通信，由此将消费应用从这些细节中解脱出来。由此，这样的代理服务器允许在服务交互期间智能地确定哪里应当进行用户接口变换。例如，针对业务通道约束和要求的重量级的业务语义的变换可以在服务交付管理器114处进行，而相对轻量级的设备特定的变换可以通过消费者环境进行，例如，在服务消费者122中进行。

如上所述，实例管理器138在代理服务的交付期间提供服务实例管理。关于这一点，可以理解，在服务代理104上展示的给定服务/服务提供者102的服务逻辑的范围(extent)可以由许多因素来确定，包括例如服务的复杂度、在宿主环境(hostedenvironments)中的业务对象状态与服务之间的依赖性、以及在服务提供者与服务代理之间的信任程度。对于通过不同会话访问的长期服务而言，图1的系统100根据需要/期望能够管理和存储它们的(数据)状态。

也就是说，对于代理服务交付的简单方案而言，可以在后端服务应用中保留这样的状态信息，从而使服务提供者对服务编排逻辑保持完全的控制，同时服务代理104提供对服务的访问，并且服务代理104可以仅仅进一步涉及记费/付款。然而，即使服务在这个意义上被适配(例如，为了记费/付款)，在这样的方案中的交互也可以在被适配之前通过代理并被传递到服务应用，从而使状态仍然包含在后端服务应用中。在这样的方案中，一些状态信息，诸如服务进展(progress)，可以通过服务代理104传回(pass back)，然而在很大程度上，对后端服务应用而言，在这样的方案中代理中的服务的角色仍然主要是无状态的代理服务。

如这里所描述的，对于例如系统100所能够执行的更加复杂的服务交付，部分服务状态和执行工件(artifacts)(例如，代码验证和表单)能够被展示在服务代理104上。通过提供用于有状态访问路由的更加详细的编排逻辑，服务代理104能够提供用于增值服务交付的在服务中的业务应用，例如，对消费者选择进行记录以作为客户关系管理(CustomerRelationship Management，CRM)的一部分、管理在线结算、以及履行服务(包括通过运输和物流服务提供资产转移)。对于有状态的服务，包括实例管理器138的服务交付管理器114可以允许用户看到在服务的生命周期中所涉及的活动，并且可以自己编排各个步骤(状态)，包括允许表单被填写和提交，以及确定响应于表单的填写和提交而在后端服务应用上调用的相关动作。

服务组管理器142允许以集合的形式订购服务，所述集合例如为能够提高需求的价格有竞争力的提议(offer)，共享共同目的的功能上相关的组，或者能够提供客户便利并进行单一付款的单一订单。服务绑定是第一种形式的例子，其中服务被组合到一个提议中，虽然它们不一定相关的或交叉编排。信用卡账户、股市报告以及通过附属联盟的库存订货，是可以与业务形成服务绑定在一起的服务的示例，但是这些对于实际许可规定(licenseprovisioning)并不是决定性的。通过服务市场创建的合成业务是第二种形式的示例。服务的电子商务购物车是第三种形式的示例。这里所讨论的业务形成示例具有第一和第二中形式两者的特征。

如上所述，服务的分组可能在表面上看与从电子商务市场成组地订购货物具有相同的特点，但是这里存在着细微但重要的区别。例如，与商品不同，服务具有相互作用的执行模式，这需要对分组的概念进行细化。此外，个体服务的执行会导致与作为组的一部分的其他服务相关的特定数据状态。因此组中的服务共享可变的状态即是这样的一个区别。此外，当服务执行时，可能出现对于其他服务的引用，例如，为了业务许可规定要求(businesslicense provision requirement)，可能需要未预料的服务来向已经运行的服务提供信息。

因此，服务组管理器142可以提供向组中动态添加服务，以及从组中动态去除服务。在考虑去除服务时，可以禁止任意去除仍在执行的服务，从而只有异常或正常终止的服务可以被去除。对于复杂的绑定要求，支持对于能从绑定以及绑定的嵌套中选择的内容(例如，其中一个服务或全部服务)的约束。因此，服务组管理器142支持对服务的分组访问，这准许有关于选择绑定中的服务、共享状态、以及插入和去除要管理的服务的不同的业务约束。服务的分组可以被保持，直到所有服务都被交付，之后，组可以被去除。

服务中介与电子商务商品市场的另一个区别是认证(authentication)。商品订单要求客户表明自己的身份并提供付款方式和货运地址，以便完成采购过程。服务无法按照这样的单一安全策略来处理，并且服务涉及不同程度的安全敏感度。

例如，提供可自由获取的信息的服务不需要任何用户识别。对于它们而言，匿名访问是可接受的。在另一极端，高度敏感的服务，例如获得业务许可或申请通行证，与个体和实体的身份具有重大关联，这涉及到被访问的服务，身份欺诈的风险以及其他相关的风险。对于这些服务，用户需要被认证到最高的识别级别的程度，以确保个人的身份反映在用户访问服务时提供的凭证和/或署名的详细资料中。

当然，对于其他服务，安全问题可能在这两个极端之间。这样的服务尽管已在其他地方假设或建立了用户、提供者以及中介之间的一定级别的信任，但仍要求身份详细资料。在其他实施方式中，可能仅仅要求用于非敏感方面的识别级别，例如将材料传送到收费地址(这类似于在传统因特网市场中所需的身份的级别)。

因此，服务交付管理器114可以被配置成保证对服务的访问符合该服务所要求的认证的级别。对于在相同的会话上下文中访问服务的情况，其中通过该会话建立了身份，认证对于通过该会话访问的其他服务的其他认证需求可以是合格的。除非特定服务需要，否则可以避免对于通过同一会话访问的每个服务进行重复认证。可以使通过后续会话进行的认证遵从服务的安全要求。

可以支持各种其他特征和组件。例如，服务代理104可以向最终用户(end user)出示使用历史，例如，已经执行的服务实例的列表。服务代理还可以允许用户访问已结束的服务实例的细节，例如数据，包括访问在交付期间为服务实例创建的账单，或者访问服务实例的付款收据，所述付款收据记载了哪些账单已支付以及哪些账单未支付。

图2和图3是示出图1的系统100的示例操作的流程图200和300。虽然图2和图3是顺序地示出的，但是应当理解，这样排序方式仅仅是出于例示的目的，而并不一定意味着这样的次序是必须的，实际上，图2中的各种操作可以以不同的次序执行，和/或部分地执行或重叠的执行。

在图2的示例中，可以与消费至少一个服务提供者的至少一个服务的计算设备的服务消费者接口，由此执行向该服务消费者的服务交付，包括接收表单请求、提供表单、以及接收提交的表单(202)。例如，代理消费者网关116可以与服务消费者122接口，以交换由服务调节器112创建的表单，所述表单对应于服务注册表110的一个或多个服务的状态。

可以创建至少一个消费者会话，在消费者会话期间执行所述至少一个服务的至少一部分(204)。例如，消费者会话管理器126可以创建以相关用户唯一识别的消费者会话。

可以在至少一个消费者会话内创建至少一个服务的至少一个实例，所述至少一个实例与所述至少一个服务的用户相关联(206)。例如，实例管理器138可以被配置成创建这样的关于用户的用户实例，所述用户实例可以在单个消费者会话内开始和完成，或者可以在第一消费者会话期间开始，被存储在实例日志140中，并在第二消费者会话期间完成。

可以基于协调模型协调来自至少一个服务提供者并且在消费者会话和消费者实例内的至少一个服务的交付，该协调模型表现至少所述一个服务的特征，其中表单与至少一个服务的服务状态相关联，并且其中基于提交的表单执行在服务状态之间的转换(208)。例如，服务协调器130可以被配置成构造和存储相应的协调模型，如刚刚提到的，在该协调模型中至少一个服务的状态被表示为表单，从而服务协调器130可以通过在代理消费者网关116与服务消费者122之间交换空白的和完成的表单来继续执行至少一个服务的交付，并且通过与每个表单交换相关联的相应的转换来推进协调模型的状态。

因此，图2描述了通过服务代理104将至少一个服务交付给消费者的示例操作。在图3中，示出了附加的或可替换的示例，其中至少两个服务(即，服务组)被交付给消费者。

在图3的示例中，可以接口消费包括至少两个异步执行服务的服务组的计算设备的服务消费者，由此执行到服务消费者的服务组交付，包括接收表单请求、提供表单以及接收提交的表单(302)。例如，代理消费者网关116可以与服务消费者122接口，以交付来自服务注册表110的服务的组。如上所述，所述组内的这些服务可以是异步的，例如，可以包括来自一个或多个服务提供者的服务，除了协调模型所规定的服务间的协调之外，所述服务相互独立地操作。

可以基于协调模型来协调服务组的交付，协调模型表现了服务组的特征，其中表单与服务组中的至少两个服务的服务状态相关联，并且其中基于提交的表单执行在服务状态之间的转换(304)。例如，如刚刚提到的，协调模型可以利用协调模型库来存储，并由可以被服务协调器访问，以便按照相应的服务状态推进服务组内的服务的组合，直至完成，如这里所描述的。

可以在协调模型内识别同步状态，在所述同步状态允许在交付期间变更服务组的组级别属性(306)。例如，服务组管理器142可以被配置成在协调模型内识别准许或期望改变服务组的组级别属性的状态，所述组级别属性诸如例如认证级别、付款属性或服务组的服务成员的身份或其他特性。

例如，消费者可以订购相互结合的两个服务。第一个服务可以允许匿名交互，而第二服务可能要求用户名/口令认证。可以构造这样的协调模型：其协调作为服务组的两个服务的交付，即，其包括状态和状态之间的转换。在本例中，给定状态可以用作这样的同步状态：在该同步状态可以请求用户提供用户名/口令。

在该状态之后，组级别认证被提高。因此，例如，如果第三服务被添加到所述要求用户名/口令的组中，则用户将不必重新输入这一信息。如果之后第四服务被添加，该第四服务在随后的同步状态要求附加的认证(例如，提供数字证书)，则认证级别的组级别属性可以再次提高到那个级别。

类似地，可以存在可以更改其他组级别属性的同步状态。例如，在交付上例中的组的前两个服务期间，用户可能希望进行与所述两个服务相关的付款，因此可以包括在该处可以申请付款的付款同步状态。如这里所描述的，付款管理器144可以被配置成最优化对于组协调模型内的在该处应当发生付款的同步状态的选择/包括。

可以在同步状态改变的另一个组级别属性是服务组内的服务的组成(composition)。例如，如下面将更详细描述的，可能有必要或希望添加服务或去除正在执行的或(有意地或无意地)终止的服务。在不正确的时间改变服务组成可能是不希望的或有害的，例如当给定服务仍在执行时，或者当服务的希望的功能完成之前去除该服务时。因此，如上所述，服务组管理器142在组协调模型内定义了同步点，在所述同步点准许添加/去除服务，或者以其他方式改变服务组的组成。

在上述描述中，以及在以下描述中，术语“消费者交互管理”是指用于允许消费应用(consuming application)(例如，应用124)与服务代理104进行交互的所有必需的功能。也就是说，消费应用，包括服务通道、按需服务等等，可以被理解为展示服务以及允许最终用户或其他应用与所述应用进行交互。表现为与通过服务代理104可获得的服务之间的请求-响应(request-responses)的形式的这些交互可以被谨慎地编排，从而使服务代理104可以处理这些交互，并且在需要时调用服务提供者102的后端应用或托管的应用。

为了便利消费应用与服务代理104之间的可互操作性，如上所述，可以以代理消费者网关116的形式提供单点接口，其展示了全部必需的服务代理功能，由此使消费应用无需要求服务代理组件(以及关于这些组件的方法)的内部知识。如以下更详细描述的，图4示出了代理消费者网关接口400的具体示例，其可以实现为基于Web服务描述语言(WSDL，WebServices Description Language)的接口(或者，在其他示例中，可以通过语言实现为远程接口)。

代理消费者网关接口400可以允许消费应用执行各种功能。例如，如上面所描述的，其可以允许用户匿名访问服务，以及以不同的识别级别为服务提供认证。其可以允许对于消费者(例如，用户和/或帮助用户的操作者)通过用于访问服务代理功能的通道具有的不同的“登录”(login)会话进行会话管理。

消费者会话(本文将通过更多示例描述，例如，参考图6)允许涉及服务代理功能的与通道的消费者活动被记录(logged)和跟踪。可以通过不同的消费者会话和/或服务，跨越多个“登录”会话来访问服务。代理消费者网关接口400可以允许与支持不同电子商务工件(例如购物筐、服务绑定和服务合成(services composites))的用户的服务组中的服务进行交互。代理消费者网关接口400可以允许在服务组的上下文中创建和删除服务实例，并且允许例如通过请求显示表单、请求提交已填写的表单以及通过表单的动作来与服务实例进行交互。再例如，代理消费者网关接口400可以允许以下方面的付款交互：对于各个服务实例或被分配为整个付款组的服务实例的集合，创建付款、进行付款、退还付款、或者取得和结算付款。

图4的示例代理消费者网关接口400被示出为统一建模语言(UML，unifiedmodeling language)类图。在该示例中，要求作为操作输入的关键数据被明确地表示为输入参数，而详细数据可以被编码在(XML)RequestDetails消息中。在该上下文中，这样的RequestDetails消息可以用作与代理消费者网关接口400的不同操作相关的特定消息请求的包装(wrapper)。在实践中，所有数据都可以被编码在该消息中。因此，代理消费者网关接口400可以提供对于来自服务代理104内部的类的各种方法的代理服务。

如上面参考图1所描述的，为了进一步便利与用于消费者的服务代理104的整合，服务消费者122可以部署在消费者的环境中，以与代理消费者网关116/400交互。服务消费者122从消费应用(例如应用124)取得输入请求消息，将这些整理(marshals)成在代理消费者网关116/400上特定方法调用，并返回来自服务的响应。因此，服务消费者122减轻了消费应用对于合并(assembling)和分解(de-assembling)在消费应用的表单交互逻辑中的表单数据的需要，并且减轻了消费应用对代理消费者网关116/400进行调用的需要。

消费应用的表单交互逻辑由服务消费者122偏移(offset)，服务消费者122准备能够通过服务代理104处理的格式的消息，隐藏了关于消费应用的更高级别的复杂性。服务消费者122还准许特定操作发生在客户端侧，由此引入潜在的性能优化。例如，用于在具体设备上显示而进行的表单的变换(例如，使用表单中介器134)可以完全或部分地由服务消费者执行，而非通过服务代理104来执行。在这种情况下，服务消费者122可以，例如，把设备专用(device-specific)的表单数据翻译为请求消息的一般参数化的数据。对应地，服务消费者122可以将来自代理消费者网关116/400的响应消息的一般参数化的数据变换为设备专用的数据，该设备专用的数据能够在消费者的设备上通过表单表示。

为了支持对于消费者的会话管理，以及特别地，为了允许通过服务代理104发生的各种用户交互被记录、跟踪以及审计，图1的系统100支持消费者会话，例如，使用消费者会话管理器126和会话日志128。图5和6提供了示例消费者会话管理器(ConsumerSessionManager)500和消费者会话(ConsumerSession)对象600的例子，如以下所述。

例如，自助服务的用户(例如，客户)和/或业务通道操作者(例如调用中心或前台操作者，代表客户进行操作)可以在消费者会话中被涉及。服务的表现(presentation)通过不同的消费者应用设定中的通道发生。然而，消费者会话可以通过服务代理104创建以通过服务代理104管理和监控交互。应用到用户交互的上下文的数据，例如，地理位置，可以存储在消费者会话中(例如，在会话日志128中)，由此允许这样的信息通过在该特定会话中与服务交互而被使用。这样，消费者应用免于为用户提供这样的会话管理的需要。

如上所述，不同于电子商务应用以商品/信息作为焦点，被认为对于服务重要的特殊要求是跨越多个会话与服务交互。换句话说，服务可以通过不同会话来访问，潜在地通过不同的技术通道(例如，与不同类别的设备类型相关联的技术通道)来访问。这对涉及多个表单并且涉及与不能限制于一个“登录”会话的机构(agency)进行交互的服务是重要的。消费者会话允许通过单一对象句柄(object handle)访问来自先前会话的“开放”(open)服务、它们的组、以及跨越被访问的全部服务的相关的其他数据。

因此，示出为UML类图的图5的消费者会话500，提供了示例的消费者会话管理器接口。消费者会话管理接口500可以用来提供对消费者会话对象(例如，图6的消费者会话对象600)的管理，例如，允许在每次创建、更新和/或删除消费者会话时记录/计量(meter)消费者会话，以及维护用户和他们的消费者会话之间的关联。

由消费者会话管理器支持的功能可以包括创建消费者会话和维护用户和他们的消费者会话，获取消费者会话(例如，为消费应用或操作者(代表用户)提供用于确定在像审计或服务辅助的情形下需要被引用的消费者会话的部件)，和/或删除消费者会话(例如，当用户注销(log out)或会话超时发生消费者会话的删除)。

消费者会话对象，比如图6的消费者会话对象接口600，可以用来提供具体会话上下文，在该具体会话上下文中用户在特定“登录”期间通过通道与服务代理交互。消费者会话对象接口600可以用于访问服务组、服务实例、以及其他通过服务代理104和用户交互管理的对象。在这个上下文中，与消费者会话相关联的“用户”是用户(例如，身份和位置与服务中的相应数据相关的最终消费者)和/或通道操作者(代表最终消费者进行动作)。自助服务的用户可以匿名“登录”，然后根据所请求和访问的服务的安全要求，以不同的识别级别来识别他们自己。一旦用户已经被识别，细节即可为通过该消费者会话可获得的其他服务可用。

因此通过消费者会话可以支持各种功能。例如，可以执行用户认证，用户认证作为初始登录的一部分而发生，或者在访问保证与特定认证级别相应的(更强)识别的特定服务期间被执行。一旦用户被认证，可以使用户信息即对通过该会话访问的其他服务可用。在会话完成之后，认证的用户信息可以自动地对随后的会话可用，也可以不自动对随后的会话可用。消费者会话对象600还提供在用户被认证时将用户分配到服务组。也就是说，用户分配可以基于可能是不同认证级别的用户身份。当这些改变时，例如，由于在访问安全敏感的服务时要求更强的认证而改变时，用户的身份将改变。此时用户的全部服务组可以作为再分配的一部分而改变。

消费者会话对象接口600还便利服务组的创建和删除，例如，允许对服务绑定、购物筐、以及将被作为一组进行管理的其他形式的服务集合和合成的一般支持。这可以便利获取服务组的句柄；例如，获取特定服务组或获取用户的全部服务组。后者被用于例如将服务组再分配给用户。消费者会话对象600可被用来获取和/或设置用户的默认服务组，因为用户可能具有多于一个服务组。

消费者会话对象接口600可以作为在创建/删除服务实例、和/或在向服务组添加和从服务组中去除服务实例、以及在服务组之间移动服务时的工具。因此，可以支持订购、去除、以及管理服务的不同阶段。例如，如这里所描述的，当订购服务绑定时，服务组可以被创建以管理该服务绑定。然后，在绑定中的原始服务已经被访问之后，服务实例可以被添加到该服务绑定。同时，如果服务不再需要，则可以要求去除服务实例。然而，应避免在服务实例的生命周期的处理阶段去除该服务实例。

消费者会话对象接口600允许与服务实例进行面向消费者的交互。这样的交互可以包括获取表单以便能够填写关于服务中的一步的数据，或者提交请求关于服务的动作的已填写的表单。为了简化交互，消费应用(例如，124)只需传递具有包含在请求消息中的细节的请求。请求的实际性质可以由服务消费者122、代理消费者网关116、或由消费者会话来确定。

图6中的UML类图提供了样本消费者会话接口，其可以用于上述及其他功能(例如，付款功能)，如图所示。图6的消费者会话接口600可以作为本地接口来使用，并且不需要直接远程访问。

如上所述，消费者会话执行的操作，如图6所描述的，可以使用会话日志128来记录。表1标识了可以为消费者会话日志记录收集的信息。

表1

因此，会话日志128从消费者会话对象接收消息，并为其接收的每个消息生成数据库日志项。图7示出UML类图，该UML类图示出会话记录的例子。具体地说，付款日志消息(PaymentLogMessage)702、服务日志消息(ServiceLogMessage)704、会话日志消息(SessionLogMessage)706、以及服务组日志消息(ServiceGroupLogMessage)708可以用来创建日志消息(LogMessage)710，如图所示，并且使用用于输入的接口(Interface)712传递到会话日志128。从而，SessionLogMessage(会话日志消息)对象710被作为消息主体传递到会话记录器(logger)。

图8提供了与图1的服务组管理器142相关联的服务组管理器(ServiceGroupManager)接口800的示图。如上所述，利用服务市场、服务目录、业务网络、及其他形式的服务生态系统/集散中心(hub)的服务通道118a、118b以及消费应用(例如，124)允许服务以集合或以组来订购和访问。示例包括服务绑定、电子商务购物筐、和类似业务过程的合成服务。服务的分组还对共享公共数据、可以对组执行的公共交互例如付款、以及服务激励例如分派折扣和奖金有重要意义。对于在服务代理104管理服务的一般容器或组的要求使消费应用不再必须提供该功能。

因此服务组管理器接口800为在服务代理104内创建的服务组提供了单点管理。它记录并管理哪些服务组与用户相关联，并用作用于创建、定位和删除服务组的窗口向客户端隐藏了服务组实现方式的可能的变化。服务组被跨越消费者会话保持，所以当用户“登录”并且消费者会话被创建时，那个用户的服务组可以通过那个会话被访问，并且将具有与其离开先前消费者会话时相同的状态。

被图示为UML类图的服务组管理器接口800提供了许多不同的功能。例如，其支持服务组的创建和删除。关于这一点，服务组可以在消费者会话被创建时被默认创建，用作在该会话期间订购和访问的服务实例的默认容器。当服务实例被创建时，其被分配给默认服务组，直到其明确地被用户分配到另一个服务组。当服务实例是合成业务(例如服务绑定)时，服务组也被自动地创建。最后，服务组可以被显式地创建。服务组可以是其他服务组的一部分。服务组的删除可以避免其包含活动的服务实例(即尚未到达终止状态的服务)。

服务组管理器接口800还可以被配置成检索用户的一个或全部服务组，将服务实例添加到服务组或从服务组中去除一个或全部服务实例，或者将一个或全部服务实例从一个服务组移动到另一个服务组。如果用户具有多于一个服务组，服务组管理器接口800可以获取/设置(get/set)用户的默认服务组，并且当用户被认证时可以将用户分配到服务组(因为用户分配可以基于用户身份，而用户身份可以处于不同的认证级别)。

图9示出了服务组(ServiceGroup)对象900，其被图示为UML类图，服务组对象可以代表用户保存零或多个服务实例，从而以某种相关方式提供对订购和访问服务的便利的管理。关于这一点，不同类型的用户可以具有对服务组功能的不同子集的访问权限。访客(Guest)、或者尚未“决定加入”(opted-in)或正与服务代理104匿名交互的用户，可以在任何给定时间被限制到一个服务组，而具名的/已认证的用户可以具有一个或多个(具名的)服务组。

服务组对象900支持的功能可以包括将服务实例添加到服务组，或从服务组中删除一个或全部服务实例。当前“活动的”的服务实例可以被要求在他们被从服务组中删除之前到达终止状态，虽然这样的要求不会禁止服务实例被服务组管理器142/接口800移动到另一个服务组。服务组对象900还可以与获取和设置与服务组相关的属性、获取服务组的一个或全部服务实例、或者去除服务实例对服务组的一个或全部引用相关联。关于后者，去除引用并不删除服务实例，而是简单地去除服务实例与服务组的关联。这个功能可以结合删除服务实例、服务组、或在服务组之间移动服务实例使用。

对服务组执行的动作可以使用服务组日志148来记录。这些动作可以以一般意义来记录，以向用户提供对他们的每一个购物筐执行的动作或其他活动的历史记录。表2标识了可能为服务组级别的记录收集的信息。

表2

服务组日志148从服务组管理器142/接口800以及相关联的服务组对象900接收消息，然后为其接收的每个消息生成数据库日志项。类似图7，图10的UML类图示出了这样的消息，如付款日志消息(PaymentLogMessage)1002、服务日志消息(Service Log Message)1004、以及会话日志消息(SessionLogMessage)1006，它们被与要传递到日志消息(LogMessage)1010中、并最终通过接口(Interface)1012传递到服务组记录器中作为消息主体的服务组日志消息(Service Group LogMessage)1008相关联地提供。从而至少服务组管理对象1008的信息可以被用来产生适当的日志信息。

图11是示出与服务实例管理相关联的技术的框图1100。具体地说，如上所述，当通过服务代理104发布和管理服务时，服务可能需要许多对象以便通过服务代理104来交付。图11示出为在为了执行用户交互而处理服务(即，用于处理相关联的服务实例)时涉及的关键类(key classes)的UML类模型。

服务的根(root)是服务1110，包含与其通过服务代理104的发布和访问相关的所有相关信息和源。因此，服务1110提供了对于服务的关于类型级别的全部描述、工件、配置和约束的“单点”引用。通过它，全部服务相关的信息、执行类和其他工件都可以在服务代理104中被生成、征用(enlisted)、部署、或以其他方式使用，从而服务可以被发现、订购和实例化。服务对象1110通过服务包(service package)来创建，服务包来自其服务供应(provisioning)环境，并作为服务部署的一部分而被部署到服务代理104上。

服务1110可以包含服务描述符(其存储在服务注册表110中以供搜索/发现)，以及任何展示的执行步骤(以及用于与这些步骤交互的表单)。服务1110可以包括数据集和代码，它们被部署以允许有效地访问验证(validation)步骤，而无需要求调用远程托管的后端服务应用。例如，可以准许用于服务中使用的数据查找(look-up)的本地验证，其可以通过服务代理104来执行。

类似图1的服务中介器141，服务中介器(ServiceMediator)1104可被用于服务1110，从而可以对消息进行翻译以便与在远程的、托管的环境中运行的(例如，服务提供者102所使用的)后端服务应用进行通信。多少类似地，类似图1的表单中介器134，表单中介器(FormsMediator)1106可以用来将表单变换到特定通道(例如，设备特定的表示，表单字段的重新表示(re-presentation)，或广告)。

当用户(User)1114请求服务时(例如，通过消费应用)，服务实例(ServiceInstance)对象1108被创建，例如，由实例管理器138创建。服务实例可以在用户订购的全部实例之间被唯一地标识，并且将一直存在直到服务完成或删除为止。除了在服务被执行时存储和跟踪服务的全部实例专用的(instance-specific)信息，服务实例1108还通过服务代理104利用支持其执行的许多对象和数据文件。这些都是在创建服务实例时为了其使用服务而创建的。服务实例部署描述符可以用来定义作为与用户进行订购谈判的结果而被创建的服务的不同交付配置和约束、以及对具有服务执行的各种细节的相关工件的链接。

相对于如上所述的通过服务代理104管理的其他类，在关系和约束方面，服务实例可以具有以下特性。例如，服务实例可以属于一个用户，虽然用户1114可能已经订购了多于一个服务实例。服务实例是从一个服务(类型)实例化得到的，但服务可以具有一个或多个服务实例。可以通过一个或多个消费者会话(ConsumerSession)1116与服务实例交互，并且消费者会话可以涉及零或多个服务实例。消费者会话只有一个用户，而用户可以具有零或多个消费者会话。服务实例只被分配给一个服务组，而服务组可以具有一个或多个服务实例。服务组1112属于一个用户，而用户可以拥有零或多个服务组。服务实例可以被分配给付款组(PaymentGroup)1118，而付款组具有一个或多个服务实例。服务实例可以具有如这里所讨论的例如服务协调器(ServiceCoordinator)1102、服务中介器1104、以及表单中介器1106的形式的支持性的执行组件。

包括通过服务代理104调用的用于交付的业务应用(例如付款)的服务实例的服务执行步骤的细节通过服务协调器1102来管理，服务协调器1102代表了图1的服务协调器130的功能。通过它，服务实例可以通过服务代理所支持的不同服务交付模型(例如，服务中介)来执行。编排的细节被存储在(协调模型132中的)协调模型中，通过服务协调器1102来管理。因此，服务协调器1102以及相关联的协调模型维护为服务1110管理的所允许的交互，这涉及到全部前端和后端动作，以及它们的可允许的执行次序。通过这种方式，服务步骤的执行次序可以是透明的，从而允许便利地更新交付配置(例如针对通过服务代理104收集的付款进行更新)、用于与其他服务聚合的功能扩展，以及在执行期间进行跟踪。交互可以例如与表单请求和动作以及请求服务动作的用户所提交的表单数据相关。在中介的交付模型中，服务代理104管理向后端服务应用的、用于执行动作的请求和返回的响应。

图12是协调模型的框图。在图12的示例中，协调模型1200被示出为据有限状态机适配而来，并且允许灵活的交互次序，所述交互例如通过网页来自用户的前端交互。然而，也可以使用基于流的业务过程模型。

在图12的示例中，协调模型1200被示出为具有状态(节点)1202、1204、1208、1212、1216、以及1220的集合，以及包括转换1204a、1204b、1208a、以及1212a的转换(节点之间的链接)，如图所示。服务的每个状态表示在服务执行期间的离散点，在那里一个或多个交互可以前进(proceed)。状态包括标准的启动和终止状态1202以及1220，以及在这些状态之间的服务专用的(service-specific)状态1204、1208、1212和1216。例如，旅馆预订服务可以具有“启动”、“保留”、“预订”、“付账离开”以及“取消”的状态。在“启动”状态中，服务可以根据发生的交互而进展到“保留”、“预订”或者“取消”。

在图12中用户交互如图所示使用表单1203、1206、1210、1214以及1218、通过服务的用户接口和表单交互进行。在给定状态中，客户应当能够针对所请求的动作获得表单、填写表单、并提交表单。动作的结果是将服务进展到下一个相关的状态。最终通过用户交互，服务应当进展到终止状态1220。

因此，用户交互可以通过表单来进行，所述表单可以从后端服务应用检索，或者可以作为协调模型1200的一部分在服务实例中高速缓存(cached)。对于需要从后端服务应用检索的表单，可以调用所述应用。对于高速缓存的情形，状态可以与表单模板(如图1中表单模板136所示)相关联，其定义了表单的结构，该表单与要被呈现(rendered)以作为服务被表现为给用户的用户界面(UI)的方式的一部分的状态相关联。例如，如果三个表单需要填写用户细节以便进行旅馆预订，则表单数据将根据表单模板来构造。表单模板被独立于具体的UI技术来定义，以允许服务被表现给将针对服务表现(service presentation)而进行平衡的各种各样的UI技术(例如，网络浏览器或不同品牌/类型的智能电话)。这样，为了使交互前进，可以将用于服务的特定状态的相关表单发送给用户。例如，在一些实施方式中，表单模板可以使用基于XML的XForm表单来构造。

因此，用户交互可以涉及被填写的一个或多个表单，以及被选择和提交给服务的动作。例如，在旅馆预定的示例中，为了旅馆服务，用户可以在通过三个表单填写了客户细节之后选择“预订”动作。通过由用户输入的表单，可以选择除了所述动作之外的选择。例如，可以请求“预订”或“取消”动作，虽然从用户的角度看每次只能向服务请求一个动作。因此，通过所提供的表单，对于给定的服务状态，可以展示多于一个动作。当动作被选择并提交给服务时，动作可以被传递(中介)到(实现服务的)后端应用。应用可以以不同的方式来应答，例如，对旅馆的预订可以被接受或被拒绝。

关于服务的动作请求和响应被建模为协调模型1200中的转换。当在给定服务状态中由用户请求动作时，由该动作标记(labeled)的一组转换中的一个是相关的。例如，在图12中，当服务处于状态“状态m”1204时，“动作y”转换1204a、1204b中的一个是相关的。在这个示例中，只有一个“动作y”1204a、1204b可以被用户选择。一旦为了对应于动作的操作而调用服务时，即通过返回的响应选择了具体的转换。因此，对于服务的“状态m”1204，根据响应“响应1”或“响应2”中的哪一个被选择，来选择两个引出的(outgoing)转换中的一个。

因此，执行协调模型1200意味着当到达服务的给定状态(除了终止状态)时，相应的表单模板被选择并被用来生成发送给用户的表单(即表单和它们的序列)。从那个状态引出的转换中的一个被选择作为用户所请求的动作的结果，以及后端服务应用进行响应(例如，标记为“<动作名>/响应名>”(<actioin-name>/response-name>))。结果，到达链接到所选择的转换的随后的状态，并且重复整个过程。在“终止”状态中，不再进行进一步的转换，服务被终止。此时，服务实例可以被删除。

图13是代表图1的付款管理器144的功能的付款管理器(PaymentManager)接口1300的示例。如参考图1所述，付款要求可以抽象为付款条件，而不管应用到服务的价格模型是什么。付款条件可以应用到服务的生命周期的特定部分，特定是执行步骤，例如，收集部分付款以便进行服务的下一个步骤。对付款和其他服务交付实体的一致性和完整性的检查可以通过语义推理(semantic reasoning)自动地进行。例如，如果对于一个步骤进行部分地付款，则可以强制在服务的随后的步骤中进行剩余的付款。如图所示，付款管理器1300可以实现包括创建、删除、或检索付款组的功能，并且还可以负责向付款组添加服务或从付款组去除服务，以及负责授权付款。

付款对象允许满足一个或多个服务的付款要求。分配给付款对象的服务实例可以来自一个服务组或不同的服务组。

对不同合伙人的付款费用的贷项和借项分摊(credit and debit apportioning)也可以通过付款对象来管理。例如，服务代理可以要求代理费用，登广告者可以补贴一部分服务成本，提供者可以要求服务的核心交易成本，并且消费者可以支付服务成本减去补贴。因此，具有不同的贷项/借项交易的付款日程应当通过付款对象来创建和执行。来自消费者及其他合伙人(例如登广告者)的服务成本的偿还以及给服务合伙人的服务成本的支付通过不同的过程来进行。

当付款对象将付款请求传递到服务代理应用，而服务代理应用将这个请求传递给付款引擎时，可以执行付款。付款引擎的选择基于指定的付款方法来选择。请求被处理，并且返回的响应可以确定付款对象的付款条件是否满足。如果是，则服务的下层状态推进到下一个状态，例如从而可以前进到交易阶段。

付款管理器1300负责付款对象的创建和定位，以及能够履行由服务代理发出的交易请求。如刚刚提到的，由付款组管理器接口1300支持的功能包括创建和删除付款组(付款组在消费者会话中被创建和删除)，获取和设置付款组以便它们的细节可以被更新或它们可以被删除，向付款组添加和从付款组删除服务实例，以及设置付款组的授权细节(例如，当从账单/收据系统接收到付款响应消息时，允许消费者会话设定授权号，或者给消费者会话提供更新付款组的机制。这样的号码可以用来履行记录以及与付款功能相关联的审计要求)。图13中的UML关系图提供了作为样本的付款管理器接口。它应当只可作为本地接口使用，因为其不能直接远程访问，而是通过消费者会话访问。

付款组，例如，使用付款组(PaymentGroup)接口1400实现的付款组，在逻辑上代表覆盖一个或多个服务实例的单一付款，并且其可以包含来自多于一个服务组的服务实例。这支持付款组能被使用的不同方式。用户可能希望只为单一服务付款。这个服务被直接添加到付款组。更一般地说，用户将选择许多服务(一个或多个)来付款，然后触发付款动作。全部这些所选择的服务可以在组构建时被添加到付款组。可替换地，用户可以在付款组已经被创建之后异步地将服务添加到付款组。付款组可以为了审计目的(例如跟踪负责对付款动作进行动作的用户和操作者)而与付款组在其中被创建的消费者会话相关联。

由付款组接口1400支持的功能可以包括向付款组添加和从付款组去除服务实例，以及获取和设置付款组的付款细节(例如设置付款组的付款方法，或进行付款)。有关付款的动作可以通过设置付款细节来进行，而服务代理104的付款管理器(接口)144/1300负责按照安排的动作作出动作，例如执行与付款动作相关联的转账。而且，付款可以根据需要取消/退还，可以对于给定付款组获得交易总额。图14中的UML类图提供了作为样本的付款管理器接口。

对付款对象执行的全部动作可以被记录，为用户提供他们已经进行的付款的历史记录。表3标识了需要为这样的付款记录收集的信息。

表3

在图15-26中，给出了可以由服务代理104的服务交付管理器114实现的示例方案的示例。所述方案通过表示为UML顺序图的交互来示出。方案的列表是说明性的，非限定性的，和非穷尽性的(exhaustive)。

图15是示出消费者会话的创建的顺序图1500。如上所述，当用户/操作者利用服务代理功能通过消费应用(在服务通道)“登录”时，或者当首次通过消费应用启动服务代理动作时，例如，当查询被提交给服务代理的发现系统时，消费者会话可以被自动地创建。

因此，在图15中，服务消费者1502、代理消费者网关1504、消费者会话管理器1506、以及消费者会话1508如所示出和所描述的那样进行通信。具体地说，消费应用请求创建消费者会话(1510)。尽管示出了明确的方法createConsumerSession()，但可以使用更一般的包含创建消费者会话请求的processRequest()。

创建请求通过代理消费者网关1504通信到服务代理。代理消费者网关1504创建消费者会话管理器1506，其中可以调用预先存在的消费者会话管理器(1512)。

消费者会话1508可以通过消费者会话管理器1506来构建(1514)。消费者会话的句柄被传递到服务消费者(1516)。如这里所描述的，作为创建消费者会话的一部分可以要求认证，但是这里没有示出，因为对于所示示例假设用户已匿名连接。

图16是示出对于新的服务实例的用户请求的顺序图1600。如上所述，用户/操作者可以匿名地请求服务实例，例如，依照服务发现或者对消费应用的直接服务请求。对此不必进行用户识别/认证。服务实例可以通过询问用户姓名和其他细节来在内部识别用户，这可以被认为是在服务代理的认证机制之外的。

用于(直接由自助服务用户或帮助用户的操作者)为匿名用户创建新的服务实例的UML顺序图1600假设发生在消费者会话已经被例如如图15所示创建之后。在图16的示例中，之前没有请求过服务，因此假设用户没有可用的服务组。

然后，服务消费者1502可以请求服务组服务(1608)。所述请求可以是隐式的(implicit)，而不是通过用户/操作者明确地进行，因为即使未命名，但所请求的服务仍可能包含在服务组中。创建服务组的请求由代理消费者网关1504传播到消费者会话1508(1610)，其已经被如图15所示创建。然后，消费者会话1508向服务组管理器1602请求创建服务组(1612)。在这个示例方案中，服务组管理器可以假设是预先存在的，并且因此可用作用于创建服务组的工厂。

服务组管理器1602创建临时(不具名的)服务组1604，以隐式地包含匿名用户/操作者的服务实例(1614)。如果还有其他服务被请求，则所述服务也被包含在这个服务组中。最多为每个消费者会话、每个单一用户创建一个临时服务组。在这个示例中，一旦消费者会话结束，服务组将被删除，删除包含在其中的服务实例，即使它们还没有完成执行也是如此。为了保存服务实例，用户可以以充分的级别表明自己的身份，以便服务组能够与那个身份相关联，以便在随后的消费者会话中使用。

然后，分别通过服务消费者和代理消费者网关请求服务实例(1618，1620)。消费者会话1508通过构建新的服务实例来处理该请求(1622)。消费者会话1508请求通过服务组管理器1602将服务实例1606添加到服务组1604(1623)。服务组管理器1602将服务实例1606添加到临时服务组1604(1624)。之后，用户/操作者可以与服务实例1606交互(例如，消息1616、1626)。

图17是示出服务实例要求用户认证的顺序图1700。接着图16的方案，图17的示例示出了新的服务请求如何被处理，其中用户需要被认证。当具有提高的安全敏感度的服务步骤正被使用或新的服务被请求时，可以要求认证。例如，匿名用户可以请求关于可用游览胜地和服务的旅游信息服务，然而，当请求预订时，用户即需要被识别。因此，图17的顺序图1700示出了作为中间消费者会话交互的、为匿名用户/操作者的新服务实例的创建。

在示例交互中，需要进行用户认证，在认证之后，匿名地创建到用户1702的临时服务组中的全部服务实例被传送到明确命名的服务组1703中。从而，例如，那些服务实例可以被保持，并在可以在日后为用户访问。交易被从临时服务组中移动到用户新创建的并且成为现在(自动)默认的服务组中。

因此，假设通过消费者会话1508从匿名用户发起了服务请求。从消费者会话1508向服务组管理器1602请求临时服务组1604(1704)。服务组管理器1602构建临时服务组1604(1706)。通过消费者会话1508创建服务实例1606(1708)。由消费者会话1508向服务组管理器1602请求将服务实例1606添加到服务组1604(1710)。服务组管理器1602将服务实例1606添加到服务组1604(1712)。

因为在消费者会话1508中创建的服务实例1606的服务交互需要认证，因此产生了用户认证需求。对新的服务的请求也可能要求认证(在图17中未示出)。对用户进行认证(1714)。消费者会话1508不再是匿名的，并且现在具有对用户1702的访问权限。

消费者会话1508定位用户的默认服务组(1716)，并且消费者会话1508向服务组管理器1602请求将服务实例1606从临时服务组1604移动到用户的默认服务组1703中(1718)。

服务组管理器1602影响服务实例1606从临时服务组1604的去除(1720)。服务组1604删除(与其相关联的)服务实例(1722)。服务组管理器1602将服务实例添加到用户的默认服务组1703(1724)。先前三个操作(1720、1722、1724)可以对用户匿名时创建的全部服务实例进行重复。最后，临时服务组1604分别通过消费者会话请求和服务组管理器动作(1726，1728)而被消灭。

图18是示出为认证的用户添加新的服务组的顺序图1800。具体地说，继续图17的示例，图18的示例示出了新的服务组可以被添加，其中用户已经被认证。例如，当在先前的服务和其他可能的服务绑定已经被请求之后预订服务绑定时，可以要求新的服务组。

新的服务组可以如先前参考图17所描述的那样被创建(1802、1804)。用户可选地给服务组指定名称以便于引用(1806)。消费者会话1508向服务组管理器请求将服务组1604分配给用户1702(1808)。然后，服务组管理器执行所述分配(1810)。

图19是示出服务实例在服务组之间移动的顺序图1900。也就是说，给定可以存在通过若干消费者会话访问的、用户的若干服务和组，用户可能希望将不同的服务实例重新组织到不同的服务组中。这在与导致进一步的服务指引或对服务绑定的进一步请求的服务交互的情形中特别有用。随着订购的服务越来越多，用户可能需要在不同的组内重新组织服务。

用户的已有服务组分别通过从消费者会话1508到用户1702和服务组管理器的请求(1906、1908)来识别和访问。消费者会话1508请求通过服务组管理器1602将一个服务组1902的服务移动到另一个服务组1904(1910)。

服务组管理器1602由从源服务组去除全部服务实例开始(1912)。源服务组1902删除其每个服务实例(只删除与其自身的关联)(1914)。然后，服务组管理器1602将全部服务实例添加到目标服务组1904(1916)。然后，每个服务实例均与服务组1904相关联(1916)。

图20是示出删除空的服务组的顺序图2000。当服务组为空时或者当服务组包含执行已经到达完成的服务实例时，可以删除该服务组。用户可以发起服务组的删除，虽然也可以存在其中服务代理发起全系统的“清理”(包括删除空的服务组)的示例方案。

消费者会话1508启动从用户拥有的那些服务组中对服务组1604的取消分配(unassignment)(2004)。由于服务组(除了临时组以外)总是被分配给用户，从用户取消分配将导致其被删除。消费者会话1508向服务组管理器1602请求删除服务组(2006)。然后，服务组管理器1602删除服务组2002(2008)。作为这个操作的一部分，可以进行检查以确定服务组2002是空的。

图21是示出删除非空服务组的顺序图2100。也就是说，对于删除服务组示出了在服务组为非空并且包含执行已经到达完成的服务实例时另一个示例方案。

在图21的特定示例中，服务组2102包含两个服务实例2104、2106。消费者会话1508向服务组管理器1602请求去除服务组2102(2108)。服务组管理器获取服务组中的全部服务实例，以检查是否能够准许进行删除(2110)。

服务组2102检查第一服务实例2104，以查看其是否能够被删除(2112)。如果其不能被删除，则整个删除服务组操作可能失败。类似地，服务组2102检查第二服务实例2106，以查看其是否能够被删除(2114)。服务组2102删除第一服务实例2104(2116)。然后服务组2102删除第二服务实例2106(2118)。服务组管理器1602删除(现在为)空的服务组2102(2120)。最后，消费者会话1508从用户1702取消分配服务组2102(2122)。

图22是示出与服务实例的交互的顺序图2200。也就是说，在以下描述中设想了与服务实例交互的细节，包括通过消费应用发起的对服务动作的请求、通过服务代理的中介、以及在托管环境中对后端服务应用的操作的调用。为了示例的目的，假设服务已经被发现、订购，并且通过服务实例的创建及其相应的支持类(例如如上所述的服务协调器)可用于交互。在图22的示例中，通过消费应用来直接请求服务实例，或者依照用户通过其选择服务的服务发现来请求服务实例。

在图22中，服务消费者1502通过代理消费者网关1504传递创建服务实例的请求(2206)。可替换地，可以用通过RequestDetails(请求细节)消息传递的所请求服务的参数来调用更加一般的processRequest()方法。代理消费者网关1504将请求传播到消费者会话(2208)。消费者会话1508使用所提供的参数构建新的服务实例(2210)。

服务实例创建其支持类(2212、2214)；例如，服务协调器2202、表单中介器2204和服务中介器，其中，服务协调器2202用于确定和跟踪服务执行步骤的顺序，表单中介器2204用于将以独立于技术通道/设备的方式表示的表单变换为技术通道/设备专用的方式，并且服务中介器针对具体的服务实例绑定了为了与后端服务应用进行通信而由服务代理所要求的具体适配器(adaptor)。

一旦服务实例已经被创建，并被分配到服务组，即可以通过消费应用与其进行交互。从面相消费者的视角看，通过各个步骤与服务进行交互，所述步骤涉及各个步骤的服务表现的工件或表单。表单代表了数据字段的集合。每个步骤的处理涉及确定需要什么表单，以便用户能够填写数据并选择动作，提交与其对应的信息以及获得响应(例如，验证数据已经被输入，或者执行所请求的动作)。

关于这一点，表单以及动作请求/提交所要求的功能可以对应于协调模型的单一转换。因此，每个转换的逻辑动作通过状态机自我捕获(itself captured)，例如，如图23中的示例所描绘的。

具体地说，图23示出了用于处理消费者交互的框图。以下详述协调模型2300如何被用来编排服务的执行步骤的示例细节。

如上所述，用户交互使用表单进行，表单对应于用来交付服务的协调模型的状态。当在消费者会话中服务第一次被访问时可以获得表单。这可能是服务实例第一次被访问，或者是自从服务被访问的上一次会话之后第一次被访问。图24是示出用于获得用于用户交互的表单的技术的顺序图，并且图24会在下文中对图23的讨论中被参照。

图23的示例示出了如参照协调模型2300所讨论的、处理请求以获取表单的细节。在图23中，如所示和所描述的，状态之间的相关联的转换被列举出来。

如图所示，从开始状态2302开始的转换(1)可以包括接收请求以便在状态2304获得表单。这可以导致执行本地FormGet(表单获取)动作(即，在服务消费者对象本地)以找到相应的表单模板(2)的转换(2)，其导致状态2306，在状态2306中表单模板被选择。用于生成表单的转换(3)导致状态2308，在状态2308中生成了抽象版本的表单。转换(4)执行到信道专用版本的表单变换，这导致状态2310，在状态2310中已经变换成具体的表单。转换(6)执行对用于(在本例中)应答表单获取请求的响应消息的准备。然后，如图所示，可以到达状态2312，在该状态中表单已经发送，包括其中适当的响应消息被发送的转换(5)。

在另一个示例中，初始的表单获取请求可以在状态2304被接收，并通过作为Remote Form Get(远程表单获取)过程的转换(7)被执行，从而导致状态2314，在该状态中应用请求被准备，如以下在接收表单提交请求的上下文中更加详细地描述的那样。具体地说，转换(8)可以对应于对提交的表单的接收和状态2316，在状态2316中接收到对FormSubmit(表单提交)的请求。与所提交的表单相关的动作可以在转换(9)中确定，这导致状态2318，在该状态中选择和/或锁定了相关动作(例如，以避免与相同或不同应用服务的相关应用操作的死锁)。

如果在转换(10)中可获得本地动作，则可以到达状态2320，在该状态中本地验证被调用(例如，邮政编码或其他静态信息的本地验证)。然后，转换11可以更新服务状态以到达服务状态被更新的状态2322。此时，转换(17)确定对于所提交的表单的响应的结果，这导致回到状态2306，在该状态中获得了用于呈现响应结果的表单的表单模板，因此如上所述可以到达状态2308、2310以及2312。

另一方面，如果在状态2318之后对于所选择/锁定的动作而言本地验证不可用，则在转换(12)中可以确定远程应用请求，并且可以到达适当的应用请求被选择的状态2323。转换(13)准备用于远程动作请求的动作提交消息，以到达应用请求被准备好的状态2314。

如图所示，因此，状态2314对应于已经接收到远程表单获取请求的状态，或对应于已经接收到远程动作请求的状态。在任一情况中，转换(14)可以进行，在该转换中对外调用被调度，并且应用请求消息被发送，以到达状态2324。在转换(15)中，对应用请求的响应被接收到，以到达状态2326。转换(16)更新服务状态以到达状态2322，状态2322如上所述导致回到适当的表单的生成和发送(2306-2312)。

更详细地，并且在图24的顺序图中反映协调模型2300的这个过程的部分：服务消费者1502在消费环境中执行，负责与服务代理消费者网关1504交互，其通过formGet()调用来请求表单，生成(XML)FormGet请求消息(2402)。formGet()调用通过服务实例的代理消费者网关1504、消费者会话1508、以及服务协调器2202传播(2404，2406)。

如上所述，表单可以通过服务协调器进行本地检索或通过服务的托管环境进行远程检索。在本地检索的情况下，表单由服务协调器2202从协调模型中选择。表单可能与每个状态相关联(除了，例如，终止状态)。为了获得表单，如上所述，为当前服务状态选择相应的表单模板。

表单可以使用表单模板和相关联的数据状态(表示为变量阵列)以及表单中介器2204来生成。表单中介器2204使用(例如，通过来自服务消费者对象的formGet()请求消息传递的)表单模板和用户的技术通道类型作为输入。表单中介器2204创建FormGet响应消息以返回给服务消费者。FormGet消息是表单模板的实例化。其包含使用来自数据状态的数据变量填写的表单。表单模板可以以希望的方式映射到个体表单以及数据状态变量。技术通道被用来变换表单以供用户的设备的显示。

服务协调器能够在将表单发送给服务消费者(2410)之前，将表单翻译为适于在技术通道类型上显示的格式(2408)。如上所述，可以存在本地变换，transformForm()(变换表单)。可替换地，服务消费者可以在发送表单的抽象表示已经被创建时执行这样的翻译。不管怎样，表单中介器将FormGet响应消息传回服务协调器，并且服务协调器2202将这个消息发送到服务消费者1502，从而更新协调模型2300(例如，图23的formGetResponse()(表单获取响应)调用)。

然后，服务消费者1502从FormGet响应消息提取要显示的表单，并且如果需要则进行通道专用的变换。当通过服务消费者1502显示表单时，由于正在进行的数据通知，可能到达能够在表单上表示的来自服务协调器的进一步通知。因此，在这样的协调模型的状态中，可以发生“安静的”(silent)转换，以允许单向通知。允许“安静的”转换的状态可以被相应的配置以指示这一点。服务协调器将不生成新的FormGet响应消息，但是会发送InForm通知消息，该通知消息将呈现在所显示的已有表单上。

如上所述，本地表单检索的一个替代是从托管环境的远程表单检索。为此，可以准备远程FormGet请求消息，如图23所示。处理远程表单请求的其余步骤如下所述依照对托管环境的动作提交请求进行。一旦已经获得表单，即执行如上所述的发送响应到服务消费者的步骤(2308-2312)。检索表单模板的一个原因是因为通道服务的表单的表示，例如，字段的表示次序，可能不同于托管环境，并且广告可能被配置为(通道)服务的一部分。

图25是示出表单提交和相关动作的顺序图。在图25中，也可以参考图23的相关转换和状态。通常，如已经描述的，在用户已经填写表单并请求动作之后可以提交表单。因此，图25示出为了获取表单而调用的对象。

在图25中，由用户填写的表单和请求的动作被通过formSubmit()(表单提交)调用从服务消费者提交到服务协调器2202，涉及formSubmit请求消息(与状态2316相关联)。这例如在用户已经填写表单并选择了表单的动作时发生。用户完成表单交互步骤并且表明对关于服务的动作的请求。要进行的动作通过所提交的表单来确定。如图12所示，不同的动作可以与特定状态相关联(例如“状态m”1204具有“动作x”1204a和“动作y”1204b)。由服务消费者生成的FormSubmit请求消息包含填写的表单、请求的动作、以及用户已经通过其请求动作的技术通道类型。

一般的processRequest()调用作为FormSubmit()被通过代理消费者网关1504(2504)传播到(服务实例的)消费者会话(2506)和服务协调器(2508)。服务协调器检查所请求的动作相关于来自协调模型2300的当前状态的可允许的动作，如在如上所述的到状态2318的转换(9)中所示。所允许的动作是关于协调模型的引出转换的动作。如果允许，则服务协调器2202锁定当前状态并选择所请求的动作的操作。对于所请求的动作的操作的细节被存储作为协调模型的一部分。允许可能对于多于一个服务的多于一个操作(因为代理服务可以支持对多于一个服务的交付)。

如上所述，动作可以在机构处远程地执行或本地执行。这个信息可以隐含在协调模型中的操作的配置信息中。如果操作被本地执行，可以使相应的接口对要执行的相应的操作本地可用。本地动作操作被执行，并且服务状态需要被更新，如图23的状态2320、2322的转换(11)、(12)所示。此后，可以确定执行的结果，如上所述(转换(17)到状态2306)，接着将结果传送给用户，也如上所述(状态2306-2312和相关联的转换)。

远程操作的执行可能要求确定远程动作操作(2510)，参考图23的到状态2323的转换(12)，以及用供应的输入参数适配的ActionSubmit(动作提交)请求消息2512的相应的创建，参考图23中到状态2314的转换(13)。本地服务中介器2502可以用于这个目的。

然后，服务代理的入站/出站(inbound/outbound)网关2503、2513的出站服务可以封装RemoteFormGet(对于远程表单获取请求)或ActionSubmit请求(对于远程动作请求)消息(例如，图25中的2512)。也可能影响应用请求所需要的服务参数的消息发送质量，这是由于与托管环境和后端应用的不同的连接质量和通信要求。

出站服务调度对于ApplicationRequest(应用请求)请求消息的消息发送动作，其可以包括发送和记录关于ApplicationRequest消息的细节，如到状态2324的转换(14)那样。出站服务与位于服务的托管环境的入站/出站网关2503、2513进行通信。当服务应用应答时，入站/出站网关2503、2513进行必要的消息编码，并使用入站服务将其发送回服务代理的入站/出站网关。

入站服务接收ApplicationRequest响应消息并对其接收进行记录，如图23中到状态2326的转换(15)所示。入站服务将消息传递到服务协调器2202。服务协调器2202使用来自该消息的数据更新服务状态，如图23的到状态2322的转换(16)中所示。

来自服务应用的响应可能带来不同的结果。例如，从状态的每个转换都与动作和响应相关联。例如，对于预订请求的响应可能是接受请求、由于保留时间已过或者请求仅仅是在与服务应用通信期间已经超时而拒绝请求。无论应用远程执行(2510/2512)还是本地执行(2514-2520)，服务协调器2202都会确定产生哪个结果。该结果被与动作所关联的状态的不同转换进行匹配，并且触发转换。当转换匹配时，服务协调器释放当前状态，并将当前状态设定为作为所选择的转换的目标的状态。根据结果，服务协调器可以：改变状态、不改变状态(因为发生错误)并且重新发出请求(或替代的请求)、或改变状态(因为发生错误)并且不重新发出请求(或替代的请求)。

结果可以被传送给用户(2522、2524)，如上参考图23的转换(3)-(6)和状态2306到2312所述。有可能还从应用发送通知。这些可以被看作是流响应(streaming responses)，其被允许作为单一结果(并因此转换)的一部分。换句话说，在这样的示例中，通知不需要改变服务的状况。

图26是示出对于多个服务实例(2602、2604)集中地处理服务付款的示例的顺序图。为此，如上所述，服务的付款条件可以应用于服务的不同步骤。可以使用付款组管理一个或多个服务实例的付款处理。服务实例可以被分配给付款组，然后付款组可以管理这些服务的付款。付款动作(例如，验证付款方法，进行部分付款，进行全部付款)可以对服务个别地执行或集中地执行。

在图26中，获得第一服务实例2602的表单(2606)。消费者会话发现这是交易阶段并识别要求的价格。然后，获得第二服务实例2604的表单(2608)。消费者会话也发现这是交易阶段并识别要求的价格。

创建付款组2610(2612)。代理通常将在允许进行到两个服务的下一步之前收集付款。然后，第一服务实例2602被放在付款组中(2614)，然后第二服务实例2604被放在付款组中(2616)。付款组指示已经付款的第一服务实例2602(2618)，并且指示已经付款的第二服务实例2604(2620)。然后，完成第一服务实例2602的下一步骤(2622)，然后完成第二服务实例2604的下一步骤(2624)。

当服务在已经收集付款之后失败，可能发生补偿情形。例如，这可能在(在已经接收到付款之后调用的)formSubmit失败时发生。尽管在收集付款之前进行了检查，这个失败仍可能发生。例如，formSubmit中的参数可能是不正确的。可替换地，购买的商品可能变得无法获得，比如当付款正被收集时另一个客户已经购买了那个物品时。

在这些情形中，代理退还所收集的钱并启动补偿程序。如果代理负责付款收集，则其通常也将负责退款。退款机制可以通过由服务提供者部署的服务来定义。

补偿程序可以包括消费者会话向付款组指出哪个服务实例已被退款。然后，付款组可以指出不再处于已付款状态的服务实例，从而服务协调器更新其协调模型。可以对失败并被退款的所有服务实例重复这两个步骤。付款组中的服务实例可以被个别退款，而不必作为一个整体退款。一些服务实例可以维持已付款。

在上述各种实施方式中的一些实施方式的具体示例中，可以考虑这样的方案，其中创建一站式的居民/委托人服务代理(作为服务代理104的示例)，以简化对于政府机构和私营部门利益相关者提供的大量服务的访问。许多通道链接到代理，以提供各种应用，所述允许对通过代理公布的服务进行一般的搜索/发现/访问，或者对特定服务的有有目的的访问。这些通道是政府机构专用的，来自于整个政府或私营部门。由提供者公布的服务大都被转换为商品，从而它们能够应用潜在的开放式集合的通道。一种特定的提议是业务实体在进行与周围环境中的人们和其他实体的交互之前所必需的业务形成。

为了获得业务许可，申请人需要满足与许可规定(例如工作场所健康和安全法案，贩酒法案)相关联的义务，包括付款。这些在公共部门中通过不同的机构来规定。过去，公共部门要求申请人通过与不同的机构交互来单独地获得不同的规定。在规定通过之前，每个机构则具有需要满足的要求(例如运输、电信、环境)。这些要求中的一些导致与其他机构的交互，包括公共机构或私人机构(例如运输、电信和环境部门)。

为了使冗长的过程(长达数月甚至数年)变得通畅，如这里描述的，可实现服务代理。然后，在操作过程中，当选择服务时，许可申请人被识别(名称和联络方式)。申请人的居住状态被通过公共部门管辖服务进行验证，以对特定状况限制创建许可类型。许多检查被执行，以识别要求了哪种业务许可类型。对于预期拥有者所进行的给定的复选集合，列出一个或多个许可类型，并做出选择。

对于给定选择，识别对于该许可类型的不同规定。对于每个规定，启动与许可提供服务的交互。交互涉及许多与申请人的环节：通过服务指定要求条款；由申请人提供对于每项条款的响应，包括支持性的文档和到已履行服务的链接；对所提供的信息作出评估并将其发送给申请人；等等，直到要求被认为已履行或未履行。交互日期和条款之间的依赖关系被捕获，包括可能由交互所产生的新的条款。对于业务许可的业务许可申请表单可以在任意阶段生成。

当所有规定的所有条款都被满足，服务代理可以将代理的服务移动到预结算(pre-settlement)阶段。获得对于许可类型的总额付款(分配给提供许可的不同机构)，并且通知其他的结算的条件。申请人约定结算条件(领取文件和材料)并进行付款。当结算条件已经被约定并且付款已经做出，服务移动到结算阶段。

上述过程从常规角度描述了业务形成。随着对消费者和相邻市场需求的进一步了解，可以为了提高客户便利性和实用性扩展常规服务。服务聚合的一条线路涉及如何拓宽业务形成的市场而不改变服务。可以允许搜索业务机会，这不仅针对决定开发支持业务的申请人，而且还可针对开始寻找市场机会的人。

为了扩展常规服务的经济效益，可以包括以下几类服务。例如，允许公布业务机会(例如开放商店租期)的服务可以以各种方式收集，例如，允许用户注册已有机会(作为注册的一部分，业务机会的细节通过调用进一步的服务来验证)，允许用户注册希望的服务(即社区驱动的业务识别)，搜索已知包含机会的公共可用的服务(例如不久将期满的业务租期，建筑中的空闲店铺)，以及允许服务提供者注册机会意义上的专家服务(例如对于社区和建筑的开发计划，申诉已有业务的轨迹，存在财务问题的业务)。可以提供基于地图的服务，其允许基于地理空间的上下文、业务指数、位置、人口统计等搜索业务机会。

而且，使申请人能够进行具体业务的可行性分析的服务线可以包括人口统计分析、土地使用、环境承诺、本地供应链、资金支持或策划、财政生存能力、以及财政选项。增添价值的另一种途径来自于对服务生命周期的考量。例如，对服务的主要阶段进行结算，其中执行交易以及颁布(enact)业务许可的文件和材料的正式传送。进一步的服务可以在结算这些服务的增添价值之前、期间、以及之后被添加而不额外增加公共部门的成本。

因此，服务代理104可以被公共部门利用以允许业务形成服务的复杂服务绑定通过能够访问服务的代理的储存库的第三方来创建以及快速地创建服务绑定。首先，来自不同机构的有贡献的服务也可以在代理上公布。第三方BPO提供者可以从事于服务以通过特定通讯标准和社区交互，例如，用于与联邦和州相关税务机构交互的征税标准。在获得操作许可之后，云计算(Cloud)提供者可用于提供小型业务的托管。各种通道都可以利用业务形成服务绑定，如以上间接提及的(政府通道、私营部门通道、社区通道等)。其他示例和变化将是清楚的。

本说明描述了用于在服务网络应用中提供服务交付的平台的专用运行时组件的要求和逻辑设计规格，诸如，例如，服务市场和业务服务网络目录。服务交付管理被定位为在通过服务网络的服务储存库发现、预订和访问服务之后要求的专用处理。在这个上下文中，服务交付的本质根据在传统平台中软件组件的运行时间而改变，诸如应用服务器和中间件、业务过程管理、以及传统服务交付平台。

因此，为了允许多状态的、多级的、长期的业务服务通过服务交付管理器、多通道服务交付、服务实例管理、以及用于展示服务协调模型的交付配置提供技术被部署、配置和执行，其中所述服务协调模型展示了要通过服务代理编排的服务步骤。任意的消费应用(例如，各种业务和技术)可以以最小化它们与代理内部工作的依赖性的方式、以及服务被建筑以便通过代理来编排的方式，与服务代理进行交互。协调模型允许服务为了服务交付的目的通过代理来编排，例如，发送表单给消费应用，接收包含用于执行的动作的提交的表单，修改和调用后端服务应用、以及将来自后端应用的响应发送给消费者，包括及时的表单变换，从而它们能够在请求进入的技术通道中表示。

而且，服务可以以关注使用服务的用户的更广的上下文中交付。对服务的成组访问、服务的不同安全级别、测量、以及付款/收费，和使用历史/审计被启动和提供。这样的因素可以暗示，对于要代理的服务，它们需要与关注在服务之间的交付考虑的其他交付管理组件进行交互。这些包括消费者会话，许多服务在多个“登录”会话之间被访问，其中在会话层面上的用户交互被保持，服务组(为了支持电子商务购物车和服务绑定)和付款组(用于在不同服务之间整合的收费)。

这里描述的各种技术的实施方式可以以数字电子电路、或以计算机硬件、固件、软件、或以它们的组合来实现。实施方式可以实现为计算机程序产品，即，有形地体现在信息载体中的计算机程序，例如，在机器可读存储设备中或在传播信号中，用于由数据处理装置执行，或者控制数据处理装置的操作，例如可编程处理器、计算机、或多个计算机。计算机程序，比如上述计算机程序，可以以任何形式的编程语言来编写，包括编译或解释语言，并且可以以任何形式来部署，包括作为独立程序或作为模块、组件、子程序、或者适于在计算环境中使用的其他单元。计算机程序可以被部署以便在一台计算机或者在一个地点或分布在多个地点并通过通信网络互连的多台计算机上执行。

方法步骤可以由一个或多个可编程处理器执行，所述可编程处理器运行计算机程序，以便通过对输入数据进行操作并生成输出来执行功能。方法步骤也可以由专用逻辑电路来执行，并且装置可以实现为专用逻辑电路，例如，FPGA(现场可编程门阵列)或ASIC(专用集成电路)。

适于运行计算机程序的处理器包括，作为示例，全部通用和专用微处理器，以及任何种类的数字计算机中的任何一个或多个处理器。通常，处理器将从只读存储器或随机存取存储器或两者接收指令和数据。计算机元件可以包括运行指令的至少一个处理器和用于存储指令和数据的一个或多个存储设备。通常，计算机还可以包括，或操作地耦合到用于存储数据的一个或多个海量存储设备，以便从其接收数据或向其传送数据或两者，例如，磁盘、磁光盘、或光盘。适于体现计算机程序指令和数据的信息载体包括所有形式的非易失性存储器，作为示例，包括半导体存储设备，例如，EPROM、EEPROM和闪存设备；磁盘，例如，内部硬盘和可移动磁盘；磁光盘；以及CD-ROM和DVD-ROM盘。处理器和存储器可以由专用逻辑电路补充或结合在专用逻辑电路中。

为了提供与用户的交互，实施方式可以实现在具有显示设备的计算机上，例如，阴极射线管(CRT)或液晶显示器(LCD)监视器，用于向用户显示信息，以及键盘和指定设备，例如鼠标或跟踪球，用户提供它们为计算机提供输入。其他种类的设备也可以用来提供与用户的交互；例如，提供给用户的反馈可以是任何形式的感觉反馈，例如，视觉反馈、听觉反馈、或触觉反馈，并且，来自用户的输入可以以任何形式接收，包括声音、语音或触觉输入。

实施方式可以在包括后端组件或包括中间件组件或包括前端组件的计算系统中实现，或者在包括这样的后端、中间件、前端组件的任意组合的计算系统中实现，后端组件例如数据服务器，中间件组件例如应用服务器，前端组件例如具有图形用户界面或Web浏览器的客户端计算机，通过图形用户界面或Web浏览器，用户可以与实施方式进行交互。组件可以通过任何形式或介质的数字数据通信来互连，例如通信网络。通信网络的例子包括：局域网(LAN)和广域网(WAN)，例如因特网。

虽然如这里所描述的已经示出了所描述的实施方式的某些特征，但是本领域技术人员现在将想到很多修改、替换，变化或等同物。因此要理解的是，所附权利要求意图涵盖落在实施例范围内的所有这样的修改和变化。

Claims (15)

1.一种计算机系统，包括存储在计算机可读存储介质上的指令，该计算机系统包括：

服务调节器，其被配置为使得至少一个处理器将至少一个服务提供者的至少一个服务的服务接口变换成服务状态以及服务状态之间的转换以创建协调模型，所述服务状态对应于作为所述至少一个服务的执行的一部分而要与用户交换的表单，所述转换表示关于所述至少一个服务的动作请求和响应；

代理消费者网关，其被配置为基于所述协调模型，使得所述至少一个处理器与消费所述至少一个服务提供者的所述至少一个服务的计算设备的服务消费者进行接口，所述服务状态中的每一个表现为经由所述计算设备的服务消费者与用户相关联的被请求、填写、以及提交的至少一个表单；以及

服务交付管理器，其被配置为使得所述至少一个处理器中介利用所述至少一个服务的协调模型建模的服务状态中的每一个、经由所述代理消费者网关、到所述计算设备的服务消费者的交付，所述代理消费者网关在所述至少一个服务的执行期间为所述服务状态中的每一个调用至少一个表单，所述服务交付管理器包括：

消费者会话管理器，其被配置为使得所述至少一个处理器与用户相关联地创建至少一个消费者会话，在所述至少一个消费者会话期间执行所述至少一个服务的至少一部分，包括根据所述协调模型通过所述至少一个服务的服务状态中的一个或多个进行转换；

消费者实例管理器，其被配置为使得所述至少一个处理器在所述至少一个消费者会话内创建所述至少一个服务的至少一个实例，与所述至少一个服务相关联的所述至少一个实例包括利用经由所述计算设备的服务消费者与用户相关联的被请求、填写、以及提交的至少一个表单来表现所述服务状态中的每一个；以及

服务协调器，其被配置为使得所述至少一个处理器在所述至少一个消费者会话和所述至少一个服务的至少一个实例内的来自所述至少一个服务提供者的所述至少一个服务的交付期间，协调和跟踪所述服务状态中的每一个，所述服务协调器还被配置为使得所述至少一个处理器使用所述协调模型跟踪和推进每个执行服务的当前状态到下一个服务状态，

所述协调模型表现所述至少一个服务的特征，其中所述表单中的每一个与所述至少一个服务的服务状态中相应的一个相关联，并且其中基于在每个服务状态期间与服务消费者交换的所述至少一个表单执行在所述服务状态之间的转换。

2.如权利要求1所述的系统，其中，所述服务交付管理器被配置为使得所述至少一个处理器，响应于由所述用户对所述至少一个消费者会话的终止，在所述至少一个实例和所述至少一个消费者会话内保持所述协调模型的当前状态。

3.如权利要求1所述的系统，包括表单中介器，其被配置为使得所述至少一个处理器在所述交付期间基于与所述服务消费者相关联的交付通道格式化所述表单。

4.如权利要求1所述的系统，其中，所述至少一个服务包括在服务组内的第一服务和第二服务，第一服务和第二服务是异步执行的服务，其中除了由所述协调模型提供的协调以外，第一服务和第二服务彼此独立地操作，所述系统包括服务组管理器，其被配置为使得所述至少一个处理器在所述协调模型内识别同步状态，所述同步状态是所述协调模型内的点，在所述同步状态允许所述服务交付管理器在所述交付期间变更所述服务组的组级别属性。

5.如权利要求4所述的系统，其中，所述组级别属性包括与所述服务组和所述用户相关联的认证级别。

6.如权利要求4所述的系统，其中，所述系统包括付款管理器，其被配置为执行对所述交付的至少一部分的付款收集，并且其中，所述组级别属性包括与所述同步状态中的同步状态关联执行的付款。

7.如权利要求4所述的系统，其中，所述组级别属性包括在服务组内的至少两个服务的合成，并且其中，所述服务组管理器被配置为在所述同步状态中的同步状态向所述服务组添加服务或从所述服务组去除服务。

8.如权利要求1所述的系统，其中，所述服务状态包括在服务执行期间所述表单上的一个或多个交互能够前进的离散点，并且所述服务调节器被配置为使得所述至少一个处理器将所述至少一个服务的服务接口映射成所述服务状态和所述服务状态之间的转换的描述。

9.如权利要求1所述的系统，其中，所述服务调节器被配置为使得所述至少一个处理器将所述服务状态与相应的表单模板相关联，所述表单模板用于将其实例化为所述表单，所述表单模板被独立于具体的用户界面(UI)技术来定义。

10.一种计算机实施的方法，包括执行存储在计算机可读存储介质上的指令，包括：

将至少一个服务提供者的至少一个服务的服务接口变换成服务状态以及服务状态之间的转换以创建协调模型，所述服务状态对应于作为所述至少一个服务的执行的一部分而要与用户交换的表单，所述转换表示关于所述至少一个服务的动作请求和响应；

与消费所述至少一个服务提供者的所述至少一个服务的计算设备的服务消费者进行接口，由此执行所述至少一个服务到所述服务消费者的交付，所述服务状态中的每一个表现为经由所述计算设备的服务消费者与用户相关联的被请求、填写、以及提交的至少一个表单；

与用户相关联地创建至少一个消费者会话，在所述消费者会话期间执行所述至少一个服务的至少一部分，包括根据所述协调模型通过所述至少一个服务的服务状态中的一个或多个进行转换；

在所述至少一个消费者会话内创建所述至少一个服务的至少一个实例，所述至少一个实例与所述至少一个服务的用户相关联；以及

在所述至少一个消费者会话和所述至少一个服务的至少一个实例内的来自所述至少一个服务提供者的所述至少一个服务的交付，协调和跟踪所述服务状态中的每一个，以及使用所述协调模型跟踪和推进每个执行服务的当前状态到下一个服务状态，所述协调模型表现所述至少一个服务的特征，其中所述表单中的每一个与所述至少一个服务的服务状态中相应的一个相关联，并且其中基于在每个服务状态期间与服务消费者交换的所述至少一个表单执行在所述服务状态之间的转换。

11.如权利要求10所述的方法，其中，所述协调包括：

检测所述至少一个消费者会话的终止；以及

响应于所述终止，在所述至少一个实例和所述至少一个消费者会话内保持所述协调模型的当前状态。

12.如权利要求11所述的方法，其中，所述协调包括：

接收对于与所述协调模型的当前状态相关联的表单的表单请求；

获得所请求的表单的表单模板；以及

在所述交付期间，基于与所述服务消费者相关联的交付通道格式化所请求的表单。

13.如权利要求10所述的方法，包括

将所述至少一个服务的服务接口映射成所述服务状态和在所述服务状态之间的转换的描述。

14.如权利要求10所述的方法，其中，所述至少一个服务包括在服务组内的第一服务和第二服务，第一个服务准许匿名交互，第二服务要求用户名/口令认证，并且其中所述协调所述交付包括在所述协调模型内识别同步状态，所述同步状态是所述协调模型内的点，在所述同步状态允许在所述交付期间变更所述服务组的组级别属性。

15.如权利要求14所述的方法，其中，所述组级别属性包括与所述服务组和所述用户相关联的认证级别。