专利名称：用于服务组的代理服务交付的服务交付管理的制作方法
技术领域：
本发明涉及代理服务(brokered service)交付。
背景技术：
商品和服务的代理是一种历史悠久的促进商业的技术。尽管形式众多，但代理共享这样一种认识商品和服务的提供者通常不愿或不能从事发起、处理或完成与一个或多个消费者交易所需的工作。例如，商品制造商可能宁愿关注于制造过程，因此可能与代理商订立契约，由代理商负责定位所制造商品的购买者并负责处理和完成对购买者的商品销售。当然，典型地，代理商为提供这些代理服务而收取购买价格的一定份额或其他一些费用或付款。这样，制造商(或其他提供者)和代理商可以专注于发展他们各自专长的领域。在计算机、网络以及软件领域，代理(broker)已将这些一般概念用于例如通过因特网交付商品和服务。例如，代理可以提供一个市场(marketplace)，在市场中不同的提供者可以出售他们各自的商品和/或服务。例如，诸如书籍的“真实世界”物品的提供者(例如，出版社)可以利用代理来销售书籍。类似地，也可以存在帮助销售数字内容(例如，歌曲或电影)和/或帮助销售软件应用等等许多待售物品的代理。然而同时，软件已经从单机的、集成的、单体的应用演进为离散的服务，所述离散的服务往往在按照需求的基础上提供特定的功能(或者进行组合以提供希望的功能)。从概念上讲，几乎任何软件功能都可以作为服务例如通过因特网或其他网络来提供。此外，不同的服务——可能是来自不同来源的不同服务——可以组合或一起销售，以用于例如提供聚合的功能和/或用于提供有竞争力的服务绑定，以吸引用户进行(额外的)购买。从而，在理论上，代理和软件服务的交集(intersection)在概念上是简单明了的。也就是说，软件服务提供者(这里称为服务提供者)可能与其他提供者一样希望获得通过代理提供他们的(软件)服务所带来的好处。在一些情况下，例如当软件在概念上类似于离散的商品(如上面提到的数字歌曲或电影的例子)时，代理服务的实现也是简单的。 具体地说，例如，代理可以获得销售所讨论软件的权利，并且可以定位该软件的客户，或者处理和完成销售。然而，实际上，传统上许多服务很难或不可能作为代理服务交付方案的一部分来交付，至少无法以任何标准的或广泛应用的方式进行。例如，可能存在一种软件服务，其由市政府或其他政府实体提供给潜在的小型企业主，用于发起和注册某种业务许可。这些以及其他类似的服务可能是复杂的、长期的过程，需要很多天或更久时间来执行，并且可能由用户通过多个通道(例如，不同的用户设备)进行访问。此外，这样的多步骤服务可能在服务提供者的后端(例如，遗留)应用上执行，并且可能需要与服务提供者和/或其他利益相关者进行多次交互/接口。而且，当服务被组合或联合以交付给单个用户时，联合而成的整体或这些服务的交互可能由于各种技术上和/或商业上的考虑而十分复杂，特别是当要组合的服务由不同的服务提供者(例如，具有不同后端遗留系统的不同企业)提供时。代理服务的服务交付包括实际运行时间、代理服务的执行、以及可能相关的功能(例如，付款收取)。在服务交付期间，服务代理可以充当简单的中介(intermediary)提供对于所讨论的服务提供者所托管的(hosted)、用于执行服务的各种后端应用的中心访问点。这样的交付模型通常意味着对服务代理仅有最低要求，而将保证服务提供者各自服务的互操作性(彼此之间的互操作性以及与用户的互操作性)的责任留给了服务提供者。相反，服务本身也可以直接由服务代理托管；然而，由服务代理来适应和执行不同用户可能希望的全部各种服务(以及他们的组合)可能是不实际或不可能的。而且，当代理上面提到的那种多步骤、多提供者、长期的、复杂的服务时，这些困难可能特别尖锐。简而言之，不存在能以平衡(leverages)所涉及各方的相关资源和专长领域的可行方式交付代理服务的令人满意的解决方案。因此，服务提供者使其服务商业化的能力降低，服务代理不太能够代理这样的服务，而消费者则需容忍他们想要使用的服务的市场较为受限且访问点较少。
发明内容
根据一个一般方面，计算机系统可以包括存储在计算机可读存储介质上的指令， 并且可以包括代理消费者网关，其被配置为使得至少一个处理器与消费包括至少两个异步执行服务的服务组的计算设备的服务消费者接口，包括接收表单请求、提供表单、以及接收提交的表单。计算机系统可以包括服务交付管理器，其被配置为使得至少一个处理器执行服务组到服务消费者的交付。服务交付管理器可以包括服务协调器，其被配置为使得至少一个处理器基于协调模型来协调服务组的交付，协调模型表现服务组的特征，其中表单与服务组的至少两个服务的服务状态相关联，并且其中基于提交的表单执行在服务状态之间的转换(transition)；以及服务组管理器，其被配置为使得至少一个处理器在协调模型内识别同步状态，在协调模型允许服务交付管理器在交付期间变更服务组的组级别属性。根据另一个一般方面，计算机实施的方法可以执行存储在计算机可读存储介质上的指令，并且该方法可以包括与消费包括至少两个异步执行服务的服务组的计算设备的服务消费者接口，以便由此执行服务组到服务消费者的交付，包括接收表单请求、提供表单、以及接收提交的表单；基于协调模型协调服务组的交付，协调模型表现服务组的特征， 其中表单与服务组的至少两个服务的服务状态相关联，并且其中基于提交的表单执行在服务状态之间的转换；以及在协调模型内识别同步状态，在协调模型允许在交付期间变更服务组的组级别属性。根据另一个一般方面，计算机程序产品可以有形地体现在计算机可读存储介质上，并且可以包括可执行代码，当执行所述可执行代码时，其被配置为使得至少一个数据处理装置执行以下操作与消费包括至少两个异步执行服务的服务组的计算设备的服务消费者接口，以便由此执行服务组到服务消费者的交付，包括接收表单请求、提供表单、以及接收提交的表单；基于协调模型协调服务组的交付，协调模型表现服务组的特征，其中表单与服务组的至少两个服务的服务状态相关联，并且其中基于提交的表单执行在服务状态之间的转换；以及在协调模型内识别同步状态，在协调模型允许在交付期间变更服务组的组级别属性。以下参考附图和描述详细地阐述一个或多个实施方式的细节。其他特征将从描述和附图、以及从权利要求中清楚地看出。
图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提供了用于服务交付管理的明确的、专用的平台，其实现了复杂的服务交付模型，从而支持长期的、多会话服务组的运行时代理(rim-time brokerage)，所述服务中的一些或全部可以由不同的或者不兼容的服务提供者来托管。更详细地，服务提供者102可以表示几乎任何希望销售或提供对服务的访问的实体，包括，例如，商务软件供应商、银行/金融公司、保健服务供应商、法律实体或者市政府或其他政府部门。服务可以表示用于例如单机消费品的例如可执行代码，诸如如这里所描述的可以经由因特网浏览器提供给购买者的单机消费品。在更具体的例子中，服务可以包括，例如，小型业务创建服务、财产转让服务、或者预订通行证(ordering passports)的服务，等等。可替换地，服务可以表示用作基础或组件服务的服务，即它们中的每一个将与其他服务相组合以提供合成的功能(composite functionality)，这种合成的功能被展示给消费者计算设备106a、106b。在图1中，服务代理104可以利用业务流程外包(ΒΡ0，business process outsourcing)提供者108以允许例如外包非核心操作或其他功能，以减少服务代理104的总体拥有成本。例如，BPO提供者108可以提供服务代理104所使用的服务，诸如收费/付款(billing/payment)服务，或者更加一般地，BPO提供者108可以提供服务代理104的硬件资源(例如，存储器、处理能力)的外包。以下，更详细地描述BPO提供者108的其他示例。在实践中，服务提供者102可以在服务注册表110内注册和装载服务，这意味着， 例如，服务的交付和执行可以通过服务代理104来进行。当BPO提供者108提供由服务代理104平衡的附加服务时，当需要时，这样的服务也可以在服务注册表110内注册和装载。当以这种方式注册服务时，服务调节器112可以用来保证服务的服务接口以与服务交付管理器114的服务交付模型一致的方式来展示，这里将对此详细描述。一般而言， 这样的服务调节可以包括从给定服务接口到状态和状态之间的转换的一般描述(generic description)的映射或者其他变换，其中所述状态被表现为将被消费者计算设备106a、 106b的用户请求、填写以及提交的表单(和/或表单模板)。通过这种方式，如这里所描述的，服务交付管理器114可以中介(mediate)服务的交付，包括以服务生命周期的执行期间的任何给定点所需要的具体方式调用表单。在这里描述的具体的例子中，服务调节器112可以使用所讨论的服务的服务接口的模型，来生成表示状态(表单)以及状态间转换的可扩展标记语言(XML，extensible Markup 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 —起提供
7了对于下层服务的代理服务器(proxy)，从而去除或减轻了浏览器120、应用124、或服务注册表110内的其他服务对相关知识的要求。以下提供代理消费者网关116的详细示例以及在代理消费者网关116和服务消费者122之间的消息接口的详细示例。在具体示例中，服务提供者102可以包括不动产公司和抵押/贷款提供者，它们可以是分离的企业，分别托管自己的后端版本的相关服务，这些服务可以通过因特网或其他网络提供。不动产公司可以提供给其服务做广告的网站，并且可能希望联合其已有网站提供申请住房贷款的服务。在图ι的系统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中可以包括服务组管理器146，服务交付管理器114 可以被配置成提供这样的服务组的管理和用于这样的服务组的管理，从而可以使用服务组日志148来跟踪和存储所述服务组。例如，服务组管理器146可以在一个或多个消费者会话内或者跨越一个或多个消费者会话来为用户管理这样的服务组，包括例如为特定服务组添加、更新或去除服务实例，或者添加/删除作为整体的服务组。更一般地说，服务组管理器142可以负责实施(enforcing)服务组的许多不同的组级别(group-level)属性，诸如调整与作为整体的服务组相关的用户认证级别。以下将更详细地描述服务组管理器146和服务组日志148的其他方面和特征。
因此，在图1的系统100中，代理服务交付可以以标准化的且可广泛应用的方式来管理，这种方式保证了交付的完整性和一致性，并允许服务提供者102和服务代理104从事他们各自偏好和专长的领域。例如，服务提供者102可以专注于开发和改进其服务，同时允许服务代理104负责交付服务。同时，服务代理104可以相对较少地涉及服务的具体业务方面，而是从事交付服务以及以其他方式使服务商业化方面的工作。图1还示出了用于代理服务交付管理的示例系统和方法。交付管理提供多通道服务访问、服务实例管理、服务交付配置、对服务的分组访问、收费/付款功能、以及各种安全级别(例如，用户认证)。以下讨论这些以及其他特性，接着是例如在图1的示例的上下文中的用于实现这些特性的具体的示例和技术。如上所述，对多通道服务访问的需要反映了这样的事实代理服务交付往往与大容量、广泛受众基础、以及对于新的和无法预期的机会的灵活市场渗透相关联。受众和消费群体的越广，通过其访问服务以及服务与之交互的设定越多样化。不同的设定意味着更多的不同业务通道(例如，用于消费者访问服务的业务应用出口(outlets))。由于不同的设备以及不同地理空间和时间的访问点，不同的设定还需要用来访问服务的不同的技术通道。为此，所描述的示例以如下方式构建即，例如使用图1中的表单中介器134及相关结构和功能，允许所述示例的用户接口适应于不同的业务和技术通道。以允许针对不同通道进行灵活变换的方式规定(specified)服务的用户接口——不仅从通道的技术(设备)表现方面，而且从通道的业务语义方面也是如此。如上所述，对于诸如业务形成的交易的服务，与用户的交互可能是长期的，例如，从数天到数月。为了促进与服务的灵活交互，实现了不同的通道，例如，从基于标准浏览器的通道到移动和语音通道。因此，服务用户界面的适用性(adaptation)是动态的，取决于用户交互涉及哪个通道。在多种多样的设定中多通道服务消费的其他方面涉及与通道相关联的不同环境、 平台和语言。对于与支持第三方居间人(intermediary)的系统交互的消费应用而言，对于消费者应用的软件适用性要求被保持在最低限度。例如，服务消费者122可以被部署为进入通道环境的代理服务器，以包含服务交互逻辑以及与居间人的消息通信，由此将消费应用从这些细节中解脱出来。由此，这样的代理服务器允许在服务交互期间智能地确定哪里应当进行用户接口变换。例如，针对业务通道约束和要求的重量级的业务语义的变换可以在服务交付管理器114处进行，而相对轻量级的设备特定的变换可以通过消费者环境进行，例如，在服务消费者122中进行。如上所述，实例管理器138在代理服务的交付期间提供服务实例管理。关于这一点，可以理解，在服务代理104上展示的给定服务/服务提供者102的服务逻辑的范围(extent)可以由许多因素来确定，包括例如服务的复杂度、在宿主环境(hosted environments)中的业务对象状态与服务之间的依赖性、以及在服务提供者与服务代理之间的信任程度。对于通过不同会话访问的长期服务而言，图1的系统100根据需要/期望能够管理和存储它们的(数据)状态。 也就是说，对于代理服务交付的简单方案而言，可以在后端服务应用中保留这样的状态信息，从而使服务提供者对服务编排逻辑保持完全的控制，同时服务代理104提供对服务的访问，并且服务代理104可以仅仅进一步涉及记费/付款。然而，即使服务在这个意义上被适配(例如，为了记费/付款)，在这样的方案中的交互也可以在被适配之前通过代理并被传递到服务应用，从而使状态仍然包含在后端服务应用中。在这样的方案中，一些状态信息，诸如服务进展(progress)，可以通过服务代理104传回(pass back)，然而在很大程度上，对后端服务应用而言，在这样的方案中代理中的服务的角色仍然主要是无状态的代理服务。如这里所描述的，对于例如系统100所能够执行的更加复杂的服务交付，部分服务状态和执行工件(artifacts)(例如，代码验证和表单)能够被展示在服务代理104 上。通过提供用于有状态访问路由的更加详细的编排逻辑，服务代理104能够提供用于增值服务交付的在服务中的业务应用，例如，对消费者选择进行记录以作为客户关系管理 (Customer Relationship Management, CRM)的一部分、管理在线结算、以及履行服务(包括通过运输和物流服务提供资产转移)。对于有状态的服务，包括实例管理器138的服务交付管理器114可以允许用户看到在服务的生命周期中所涉及的活动，并且可以自己编排各个步骤(状态)，包括允许表单被填写和提交，以及确定响应于表单的填写和提交而在后端服务应用上调用的相关动作。服务组管理器142允许以集合的形式订购服务，所述集合例如为能够提高需求的价格有竞争力的提议(offer)，共享共同目的的功能上相关的组，或者能够提供客户便利并进行单一付款的单一订单。服务绑定是第一种形式的例子，其中服务被组合到一个提议中， 虽然它们不一定相关的或交叉编排。信用卡账户、股市报告以及通过附属联盟的库存订货， 是可以与业务形成服务绑定在一起的服务的示例，但是这些对于实际许可规定(license provisioning)并不是决定性的。通过服务市场创建的合成业务是第二种形式的示例。月艮务的电子商务购物车是第三种形式的示例。这里所讨论的业务形成示例具有第一和第二中形式两者的特征。如上所述，服务的分组可能在表面上看与从电子商务市场成组地订购货物具有相同的特点，但是这里存在着细微但重要的区别。例如，与商品不同，服务具有相互作用的执行模式，这需要对分组的概念进行细化。此外，个体服务的执行会导致与作为组的一部分的其他服务相关的特定数据状态。因此组中的服务共享可变的状态即是这样的一个区别。此夕卜，当服务执行时，可能出现对于其他服务的引用，例如，为了业务许可规定要求(business license provision requirement)，可能需要未预料的服务来向已经运行的服务提供信肩、ο因此，服务组管理器146可以提供向组中动态添加服务，以及从组中动态去除服务。在考虑去除服务时，可以禁止任意去除仍在执行的服务，从而只有异常或正常终止的服务可以被去除。对于复杂的绑定要求，支持对于能从绑定以及绑定的嵌套中选择的内容 (例如，其中一个服务或全部服务)的约束。因此，服务组管理器146支持对服务的分组访问，这准许有关于选择绑定中的服务、共享状态、以及插入和去除要管理的服务的不同的业务约束。服务的分组可以被保持，直到所有服务都被交付，之后，组可以被去除。
服务中介与电子商务商品市场的另一个区别是认证(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)。 例如，服务协调器136可以被配置成构造和存储相应的协调模型，如刚刚提到的，在该协调模型中至少一个服务的状态被表示为表单，从而服务协调器136可以通过在代理消费者网关116与服务消费者122之间交换空白的和完成的表单来继续执行至少一个服务的交付， 并且通过与每个表单交换相关联的相应的转换来推进协调模型的状态。因此，图2描述了通过服务代理104将至少一个服务交付给消费者的示例操作。在图3中，示出了附加的或可替换的示例，其中至少两个服务(S卩，服务组)被交付给消费者。在图3的示例中，可以接口消费包括至少两个异步执行服务的服务组的计算设备的服务消费者，由此执行到服务消费者的服务组交付，包括接收表单请求、提供表单以及接收提交的表单(302)。例如，代理消费者网关116可以与服务消费者122接口，以交付来自服务注册表110的服务的组。如上所述，所述组内的这些服务可以是异步的，例如，可以包括来自一个或多个服务提供者的服务，除了协调模型所规定的服务间的协调之外，所述服务相互独立地操作。可以基于协调模型来协调服务组的交付，协调模型表现了服务组的特征，其中表单与服务组中的至少两个服务的服务状态相关联，并且其中基于提交的表单执行在服务状态之间的转换(304)。例如，如刚刚提到的，协调模型可以利用协调模型库132来存储，并由可以被服务协调器访问，以便按照相应的服务状态推进服务组内的服务的组合，直至完成， 如这里所描述的。可以在协调模型内识别同步状态，在所述同步状态允许在交付期间变更服务组的组级别属性(306)。例如，服务组管理器142可以被配置成在协调模型内识别准许或期望改变服务组的组级别属性的状态，所述组级别属性诸如例如认证级别、付款属性或服务组的服务成员的身份或其他特性。例如，消费者可以订购相互结合的两个服务。第一个服务可以允许匿名交互，而第二服务可能要求用户名/ 口令认证。可以构造这样的协调模型其协调作为服务组的两个服务的交付，即，其包括状态和状态之间的转换。在本例中，给定状态可以用作这样的同步状态在该同步状态可以请求用户提供用户名/ 口令。在该状态之后，组级别认证被提高。因此，例如，如果第三服务被添加到所述要求用户名/ 口令的组中，则用户将不必重新输入这一信息。如果之后第四服务被添加，该第四服务在随后的同步状态要求附加的认证(例如，提供数字证书)，则认证级别的组级别属性可以再次提高到那个级别。类似地，可以存在可以更改其他组级别属性的同步状态。例如，在交付上例中的组的前两个服务期间，用户可能希望进行与所述两个服务相关的付款，因此可以包括在该处可以申请付款的付款同步状态。如这里所描述的，付款管理器144可以被配置成最优化对于组协调模型内的在该处应当发生付款的同步状态的选择/包括。可以在同步状态改变的另一个组级别属性是服务组内的服务的组成 (composition)。例如，如下面将更详细描述的，可能有必要或希望添加服务或去除正在执行的或(有意地或无意地)终止的服务。在不正确的时间改变服务组成可能是不希望的或有害的，例如当给定服务仍在执行时，或者当服务的希望的功能完成之前去除该服务时。因此，如上所述，服务组管理器142在组协调模型内定义了同步点，在所述同步点准许添加/ 去除服务，或者以其他方式改变服务组的组成。在上述描述中，以及在以下描述中，术语“消费者交互管理”是指用于允许消费应用(consuming application)(例如，应用124)与服务代理104进行交互的所有必需的功能。也就是说，消费应用，包括服务通道、按需服务等等，可以被理解为展示服务以及允许最终用户或其他应用与所述应用进行交互。表现为与通过服务代理104可获得的服务之间的请求_响应(request-responses)的形式的这些交互可以被谨慎地编排，从而使服务代理 104可以处理这些交互，并且在需要时调用服务提供者102的后端应用或托管的应用。为了便利消费应用与服务代理104之间的可互操作性，如上所述，可以以代理消费者网关116的形式提供单点接口，其展示了全部必需的服务代理功能，由此使消费应用无需要求服务代理组件(以及关于这些组件的方法)的内部知识。如以下更详细描述的， 图4示出了代理消费者网关接口 400的具体示例，其可以实现为基于Web服务描述语言 (WSDL, Web Services Description Language)的接口(或者，在其他示例中，可以通过语言实现为远程接口)。代理消费者网关接口 400可以允许消费应用执行各种功能。例如，如上面所描述的，其可以允许用户匿名访问服务，以及以不同的识别级别为服务提供认证。其可以允许对于消费者(例如，用户和/或帮助用户的操作者)通过用于访问服务代理功能的通道具有的不同的“登录”(login)会话进行会话管理。消费者会话(本文将通过更多示例描述，例如，参考图6)允许涉及服务代理功能的与通道的消费者活动被记录(logged)和跟踪。可以通过不同的消费者会话和/或服务， 跨越多个“登录”会话来访问服务。代理消费者网关接口 400可以允许与支持不同电子商务工件(例如购物筐、服务绑定和服务合成(services composites))的用户的服务组中的服务进行交互。代理消费者网关接口 400可以允许在服务组的上下文中创建和删除服务实例，并且允许例如通过请求显示表单、请求提交已填写的表单以及通过表单的动作来与服务实例进行交互。再例如，代理消费者网关接口 400可以允许以下方面的付款交互对于各个服务实例或被分配为整个付款组的服务实例的集合，创建付款、进行付款、退还付款、或者取得和结算付款。图4的示例代理消费者网关接口 400被示出为统一建模语言(UML，unified modeling language)类图。在该示例中，要求作为操作输入的关键数据被明确地表示为输入参数，而详细数据可以被编码在(XMDRequestDetails消息中。在该上下文中，这样的 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.一种计算机系统，包括存储在计算机可读存储介质上的指令，该计算机系统包括 代理消费者网关，其被配置为使得至少一个处理器与消费包括至少两个异步执行的服务的服务组的计算设备的服务消费者接口，包括接收表单请求、提供表单、以及接收提交的表单；服务交付管理器，其被配置为使得所述至少一个处理器执行所述服务组到所述服务消费者的交付，该服务交付管理器包括服务协调器，其被配置为使得所述至少一个处理器基于协调模型来协调所述服务组的交付，所述协调模型表现所述服务组的特征，其中所述表单与所述服务组的至少两个服务的服务状态相关联，并且其中所述服务状态之间的转换基于提交的表单执行，以及服务组管理器，其被配置为使得所述至少一个处理器在所述协调模型内识别同步状态，在所述同步状态允许服务交付管理器在交付期间变更所述服务组的组级别属性。
2.如权利要求1所述的系统，其中，所述组级别属性包括与所述服务组和用户相关联的认证级别。
3.如权利要求1所述的系统，其中，所述系统包括付款管理器，其被配置为执行对所述交付的至少一部分的付款收集，并且其中，所述组级别属性包括与所述同步状态中的同步状态关联执行的付款。
4.如权利要求1所述的系统，其中，所述组级别属性包括在所述服务组内的至少两个服务的组成，并且其中，所述服务组管理器被配置为在所述同步状态中的同步状态向所述服务组添加服务或从所述服务组去除服务。
5.如权利要求1所述的系统，包括消费者会话管理器，其被配置为使得所述至少一个处理器创建至少一个消费者会话，在消费者会话期间执行所述服务组的至少一部分。
6.如权利要求5所述的系统，包括消费者实例管理器，其被配置为使得所述至少一个处理器在所述至少一个消费者会话内创建所述服务组的至少两个服务中的每一个的至少一个实例，所述至少一个实例与所述至少一个服务的用户相关联。
7.如权利要求6所述的系统，其中，所述服务交付管理器被配置为使得所述至少一个处理器响应于所述用户对所述至少一个消费者会话的终止，在所述至少一个实例和所述至少一个消费者会话内保持所述协调模型的当前状态。
8.如权利要求1所述的系统，包括表单中介器，其被配置为使得所述至少一个处理器在所述交付期间基于与所述服务消费者相关联的交付通道格式化所述表单。
9.如权利要求1所述的系统，包括服务调节器，其被配置为使得所述至少一个处理器将所述至少两个服务的服务接口映射为对状态和状态之间的转换的描述。
10.一种计算机实施的方法，包括执行存储在计算机可读存储介质上的指令，该方法包括与消费包括至少两个异步执行的服务的服务组的计算设备的服务消费者接口，以便执行所述服务组到所述服务消费者的交付，包括接收表单请求、提供表单、以及接收提交的表基于协调模型协调所述服务组的交付，所述协调模型表现所述服务组的特征，其中所述表单与所述服务组的至少两个服务的服务状态相关联，并且其中服务状态之间的转换基于提交的表单执行；以及在所述协调模型内识别同步状态，在所述同步状态允许在交付期间变更所述服务组的组级别属性。
11.如权利要求10所述的方法，其中，所述协调包括接收对于与所述协调模型的当前状态相关联的表单的表单请求； 获得所请求的表单的表单模板；以及在所述交付期间，基于与所述服务消费者相关联的交付通道格式化所请求的表单。
12.如权利要求10所述的方法，其中，所述组级别属性包括与所述服务组和用户相关联的认证级别。
13.如权利要求10所述的方法，其中，所述组级别属性包括与所述同步状态中的同步状态关联执行的付款。
14.如权利要求10所述的方法，其中，所述组级别属性包括在所述服务组内的至少两个服务的组成，所述方法包括在所述同步状态中的同步状态向所述服务组添加服务或从所述服务组去除服务。
15.如权利要求10所述的方法，包括创建至少一个消费者会话，在消费者会话期间执行所述服务组的至少一部分。
16.如权利要求15所述的方法，包括在所述至少一个消费者会话内创建所述服务组的至少两个服务中的每一个的至少一个实例，所述至少一个实例与所述至少一个服务的用户相关联。
17.如权利要求16所述的方法，其中，所述协调包括 检测所述至少一个消费者会话的终止；响应于所述终止，在所述至少一个实例和所述至少一个消费者会话内保持所述协调模型的当前状态。
18.一种计算机程序产品，该计算机程序产品有形地体现在计算机可读存储介质上，并且包括可执行代码，当所述可执行代码被执行时，被配置为使得至少一个数据处理装置与消费包括至少两个异步执行的服务的服务组的计算设备的服务消费者接口，以便执行所述服务组到所述服务消费者的交付，包括接收表单请求、提供表单、以及接收提交的表基于协调模型协调所述服务组的交付，所述协调模型表现所述服务组的特征，其中所述表单与所述服务组的至少两个服务的服务状态相关联，并且其中服务状态之间的转换基于提交的表单执行；以及在所述协调模型内识别同步状态，在所述同步状态允许在交付期间变更所述服务组的组级别属性。
19.如权利要求18所述的计算机程序产品，其中，所述组级别属性包括与所述服务组和用户相关联的认证级别、付款收集、和/或在所述服务组内的至少两个服务的组成。
20.如权利要求18所述的计算机程序产品，其中，所述可执行代码使得所述至少一个数据处理装置协调所述交付包括接收对于与所述协调模型的当前状态相关联的表单的表单请求； 获得所请求的表单的表单模板；以及在所述交付期间，基于与所述服务消费者相关联的交付通道格式化所请求的表单。
全文摘要
公开了一种代理消费者网关，该代理消费者网关可以与消费包括至少两个异步执行服务的服务组的计算设备的服务消费者接口，包括接收表单请求、提供表单、以及接收提交的表单。服务交付管理器可以执行服务组到非消费者的交付。服务交付管理器可以包括服务协调器，该服务协调器基于协调模型来协调服务组的交付，该协调模型表现服务组的特征，其中表单与服务组的至少两个服务的服务状态相关联，并且其中基于提交的表单执行在服务状态之间的转换。服务交付管理器可以包括服务组管理器，该服务组管理器在协调模型内识别同步状态，在协调模型允许服务交付管理器变更服务组的组级别属性。
文档编号G06Q30/00GK102262767SQ20111013946
公开日2011年11月30日 申请日期2011年5月26日 优先权日2010年5月26日
发明者阿利斯泰尔.P.巴罗斯 申请人:Sap股份公司