本发明涉及协调一组服务器之间的动作的方法。更具体地说，本发 明涉及协调一组服务器上的客户授权、信息聚集、成组事务处理和多阶 段确认。本发明的优选实施例涉及在万维网(World Wide Web)上的 商业。

电子商业在成指数地增加，尤其在万维网上。许多商行在Web站 点上建立了虚拟商店，允许消费者联机地逛商店和购买产品。随着这些 单个虚拟商店的符合逻辑的上升，虚拟商场也开始出现在Web上。

如同真实商场的情况，虚拟商场提供既有利于商行又有利于消费者 的机会。商行潜在地从它们在商场的可见性得益。例如，虚拟商场上的 一个虚拟商店会吸引一个原来到商场从另一个商店购买货物的消费者 的注意。消费者会从可能汇集和协调商场上的货物和服务中获益。一个 虚拟商场可以提供，譬如说，许多虚拟商店货物和服务的一个集中目 录。另外，虚拟商场还可以为商场上所有虚拟商店提供一单个授权点。 一个虚拟商场或许还能协调涉及多个商店的成组事务处理。

至今，业已出现在Web上的虚拟商场已采取了2个解决方案中的 一个。第一个，一些商场提供一个具有至各个虚拟商店的超级链接的 Web页。第二个，一些商场已提供在相同Web站点内的多个虚拟商店。 这后一个商场已利用如IBM World Avenue系统(http：∥mer.shop. ibm.com)和Netscape Merchant系统(http：∥home.netscape. com/comprod/products/iapps/capps/mersys.html)。

这些解决方案的每一个都有缺点。第一个方案除了收集它们的 URLS(统一资源定位器)外不提供各个商店间的任何协调。第二个方 案，尽管提供各个商店间的协调，但在这方面是有限制的，即虚拟商店 必须在一单个Web站点内被执行和被管理。于是，为用第二个方案参 加虚拟商场，可能要求在这个Web上有已建虚拟商店的商行重大地改 变它的执行过程。

因此，需要一种协调可能被分布在多个Web站点上的多个独立虚 拟商店的方法。

本发明针对协调一组服务器之间的动作的方法。本发明的优选实施 例涉及协调在Web上的多个虚拟商店，但本发明也适用于其他形式的 连网通信。

本发明的一个目的是提供协调客户在一组商店间单一授权的方 法。因而一旦提示授权信息，客户就能在任何一个商店或任何子组商店 上执行事务处理不需要再提示授权。

本发明的另一个目的是协调来自多个商店的信息汇总。例如，希望 把在客户访问过的每个商店的售货筐里包含的物品汇总并为该客户提 供这个信息的单一显示。如另一个例子，希望允许客户规定检索关键 字，发送检索请求给商店的任何子组以及发送组合检索结果给客户。

本发明的另一个目的是协调涉及多个商店的对于成组事务处理的 请求。例如，一个客户可请求成组购置，这涉及一种从跨各商店的一组 细目的“所有的或没有的”购置。这样的一种购置涉及，譬如说，从不 同的商店配外套和裤子。这种类型的请求可以结合单一的或跨各商店的 多阶段委托。

本发明的体系结构是有包括一个或多个参与服务器和一个或多个 控者服务器的服务器组的客户服务器环境，其中每个参与服务器能与至 少一个控者服务器通信。在这个环境下，本发明针对协调服务器组中的 各服务器间的动作的方法。协调包括以下步骤：(1)为在客户和服务 器间传递状态信息，用有限制的或无限定的过程的协议，在一个客户和 至少一个服务器之间进行通信；(2)从客户到一个服务器传送一个动 作请求；以及，(3)在响应这个请求时，在至少一个控者服务器协调 至少这些服务器中的一些服务器的动作的条件下在许多服务器间进行 通信。

本发明的优选实施例包括协调在对话期间客户的授权和协调由一 个客户请求的一组事务。为协调在对话期间的客户授权，根据本发明的 一个优选方法包括以下步骤：(1)为在客户和服务器之间传递状态信 息，用有限制的或不确定的过程的协议在客户和服务器组中至少一个服 务器之间进行通信；(2)由客户发送第一个动作的请求到一个要求授 权的服务器；(3)由客户提供客户标识信息；(4)由一个或多个控 者服务器检验客户标识信息；(5)由一个或多个控者服务器产生客户 授权信息；(6)由一个或多个服务器保持客户授权信息；(7)由一 个或多个服务器利用一个方法保存在对话中的客户授权信息；(8)由 客户发送第二个动作的请求到要求授权的一个服务器；以及，(9)用 在对话中保存的客户授权信息和由服务器保持的客户授权信息对客户 授权。

为协调由一个客户请求的一组事务处理，根据本发明的一个优选方 法包括以下步骤：(1)为在客户和服务器之间传递状态信息，用有限 制的或不确定的过程协议在客户和服务器组中至少一个服务器之间进 行通信；(2)从客户到这些服务器中的一个服务器传送多个服务器要 求参与的动作的请求；以及(3)响应该请求，在至少一个控者服务器 协调多个服务器的动作的情况下，在服务器之间进行通信。

考虑下面的详细说明，附加的权利要求和附图，本发明的这些和其 他特征、方面和优点将成为较好被理解的。

图1是根据本发明的一个优选实施例所使用的总体系结构方框图；

图2是根据本发明的一个优选实施例的为协调客户授权的方法的方 框图；

图3是根据本发明的一个优选实施例的为协调参与服务器间的成组 事务处理的方法的方框图；

图4是根据本发明的一个优选实施例的另一个总体系结构的方框 图；

图5是在对话中保存的优选变量表；以及，

图6是为在万维网超级链接中动态嵌入状态信息的方法的方框图。

如在本说明书和附加的权利要求中所使用的，术语“客户”是向另 一个执行同命令有关任务的程序或应用程序(称为服务器)发出命令的 程序或应用程序。

如在本说明书和附加的权利要求中所使用的，术语“公共网关接 口”(CGI)是一种一个万维网客户供其能请求在Web站点上执行一 个程序的机制。这个Web站点运行CGI程序并发送这个程序的输出给 这个客户。

如在本说明书和附加的权利要求中所使用的，术语“继续”是客户 可以向一个服务器发送的一个新请求，它由服务器响应客户的上一个请 求所提供。超文本链接(或超级链接)是客户-服务器通信中继续的例 子。凡客户间服务器做请求时，这个服务器可以在它的响应中包括一个 或多个继续。虽然由这个服务器提供的继续应是任何有效请求，但是有 用的继续一般逻辑上与客户原来的请求有关。

如在本说明书和附加的权利要求中所使用的，术语“对话”是在客 户和服务器间通信的时序。按这个时序服务器用一组继续响应每个来自 客户的请求，并且客户总是从由这个服务器提供的这组继续接收下一个 请求。在万维网上，超文本链接是继续的例子，凡客户跟踪由服务器提 供的超文本链接时，这个客户参与同这个服务器的对话。较正式地，一 系列HTML Web页h1、h2…hn组成一个对话，如果：(1)页h1、 h2……hn全部被一个客户查看；以及，(2)对于如1＜i＜n这样的i， 页hi通过跟踪在页hi-1上的一个超文本链接得到。在一个不被中断的 对话中，这个客户不总逆跟踪而只跟踪从页h1到hn得到的n-1超文本 链接。在一个被中断的对话中，这个客户至少逆跟踪一次。逆跟踪系指 这样的进程，其中客户：(1)初始访问页hi，其中1＜＝i＜n；(2) 或者通过跟踪超文本链接，显然需要URLs，或者通过利用Web浏览 器的高速缓存来查看其他页；以及，(3)通过从内存(如从浏览器的 高速缓存)重装入hi返回到hi。

如在本说明书和附加的权利要求中所使用的，术语“引导页”是一 个目录表，它引导万维网用户到储存在Web站点上的信息。一个引导 页常常包含多媒体目录。

如在本说明书和附加的权利要求中所使用的，术语“超级链接”或 “超文本链接”是一种网络地址，如统一资源定位器，它被嵌入在字、 词组、图标或图画里，当有人选择它时它被启动。当一个客户启动一个 超级链接时，相应于这个超级链接的信息被返回到这个客户并用Web 浏览器显示。

如在本说明书和附加的权利要求中所使用的，术语“超文本标记语 言”(HTML)是被Web服务器使用的语言，用于创建和连接由Web 客户查看的超文本文档。超文本文档的其他用途在下列美国专利中被介 绍：美国专利NO.5,204,947，1993年4月20日发布，授权给Bernstein 等；美国专利No.5,297,249，1994年3月22日发布，授权给Bernstein 等；以及美国专利No.5,355,472，1994年10月11日发布，授权给 Lewis。所有这些专利被转让给国际商业机器公司并在这里被编入作为 参考。

如在本说明书和附加的权利要求中所使用的，术语“超文本传送协 议”(HTTP)是为在计算机间传送数据由万维网使用的一个协议。 HTTP允许客户或者通过请求一个文件或者通过调用一个CGI程序从 一个服务器取得数据。HTTP是个无状态协议，这意味着，每个从客户 到服务器的请求被独立处理。服务器没有任何同客户以前连接的记录。 在URL的一开始，“http”：表示所使用的协议是HTTP。

如在本说明书和附加的权利要求中所使用的，术语“因特网”是用 TCP/IP协议互相连接的一批计算机网络和网关。

如在本说明书和附加的权利要求中所使用的，术语“服务器”是执 行在另一个程序和应用程序(称为客户)的命令中的任务的一个程序或 应用程序。如在本说明书和附加的权利要求中所使用的，一个Web站 点可以是一个服务器。术语“服务器”与支持Web站点的Web服务器 不是同义的。

如在本说明书和附加的权利要求中所使用的，术语“事务处理”系 指客户对服务器所做的任何一个请求。

如在本说明书和附加的权利要求中所使用的，术语“传输控制协议 /因特网协议”(TCP/IP)是把数据分成包，经由网络路由包，并在目 的地重建包的一批协议。数据可以是从电子邮件的正文到影象的任何东 西。

如在本说明书和附加的权利要求中所使用的，术语“统一资源定位 器”(URL)是唯一标识或寻址Web上信息的一个方式。一个URL 能被看作是等效于一个电子邮件地址的Web。如果URL属于深埋在其 他文档内的文档，它们可能是麻烦的，但是它们可经常用超级链接访 问。URL的一个例子是：“http：∥www.arun.com：80/table.html”。

一个URL有四个部分，自左边开始，第一个部分规定所使用的协 议。它被一个冒号同URL的其余部分分开。下一个部分是目标主机的 主机名或IP(因特网协议)地址。这个部分在左边用“∥”定界，而在 右边用“/或一个冒号”定界。第三个部分是一个可选的端口号。当使用 这个部分时，它在左边用冒号定界，而在右边用“/”定界。第四个部分 是实际的文件名或程序名。

在上面给出的例子中，协议是“http”，主机名是 “www.arun.com”，端口号是“80”，以及文件名是“table.html”。 在这个例子中，“http”系指超文本传送协议，文件的扩展名“html” 系指超文本标记语言。

如在本说明书和附加的权利要求中所使用的，术语“Web浏览器” 是允许人们在万维网上显示超文本档的一个客户程序。Web浏览器起 因特网游览向导的作用，用图象桌面、目录和搜索工具完成，它可被人 们用于导航或“冲浪”因特网。

如在本说明书和附加的权利要求中所使用的，术语“万维网” (“Web”)是在因特网上的一批超文本文档。一个超文本文档包含 到其他文档的超级链接，人们可用它们在文件之间来回导航。实际上， 在因特网上查找信息的人们可使用Web通过选择超级链接在服务器之 间和在数据库之间来回切换，超级链接通常显示为文档中的高亮字或词 组。在Web上的资源经由统一资源定位器(URLs)访问。Web利用 超文本标记语言(HTML)显示相应于URLs的信息和提供一个至其 它URLs的指向-单击界面。

如图1所示，根据本发明的一个优选实施例所使用的一个总体系结 构由客户103和一个服务器组104组成。服务器组104包括参与服务器 101和控者服务器102。(为简洁起见，在本说明书中控者服务器102 将被简称为控制器。)参与服务器和控制器的物理位置是不重要的。每 个参与服务器101和控制器102可驻留在由网络连接的各个计算机上， 或者换过来，多个服务器可驻留在一单个计算机上。也可能，控制器和 /或一个或多个参与服务器同时驻留在几个计算机上。例如，如果控制器 和/或一个或多个参与服务器作为可缩放Web服务器实现，这种情况会 成立。(关于可缩放(scalable)Web服务器的资料，见D.Dias等，“可 缩放(scalable)和高度可用的Web服务器”，proceldings of COMPCON’96)。

控制器102保持客户帐号信息(例如，用户IDs用户名字、口令、 地址和电话号码)。如图1所示，每个参与服务器101能同控制器102 通信，而客户103能同每个参与服务器101和控制器102通信。控制器 和参与服务器可以用HTTP这样的标准协议互相通信。另外，它们还可 用一个专利协议通信。

客户103借助一个如HTTP这样的通信协议同参与服务器101和控 制器102通信。协议有为保持客户状态信息的限制的或非限定的过程。 为保持客户状态信息的限制的或非限定的过程意味着，对于利用协议在 客户和服务器之间的非空子集通信类型来说，难于或者说不可能利用由 协议规定的过程保存在对话中如客户的标识或客户的口令这样的状态 变量，因而状态变量在对话的剩余期间能被一个服务器器序地检索。

有二种参与服务器可以完成事务处理类型处理。第一种，参与服务 器可以完成一个简单的事务处理。一个参与服务器能代表与其他参与服 务器和控制器无关的客户完成简单的事务处理。因此，一个客户可以直 接从一个参与服务器请求一个简单的事务处理。第二种，一个参与服务 器可以完成成组事务处理。成组事务处理在控制器的协调下由一个或多 个参与服务器来完成。一个客户最好仅能从控制器请求一个成组事务处 理。

图2表示本发明的一个优选实施例。其中，控制器102在参与服务 器间协调客户103的授权。授权是客户103借其将自己识别给服务组104 中的一个服务器的进程。在这个优选实施例中，在对话期间只需要为客 户103提示一次标识信息，提示由在这个对话的剩余期间执行在这个服 务器组中的任何一个服务器上的事务处理的任何参与服务器或控制器 做出。

在步骤201，较可取的是控制器最好建立同参与服务器的开放连 接。相反，每当控制器需要同一个参与服务器通信时，控制器应建立一 个新的连接。然而，保持如在步骤201所示的开放连接多半导致比每次 都建立新连接要好的性能。

在步骤202，客户103不为自己授权就同服务器组交互。这个客户， 譬如说，可能还在浏览目录。

在步骤204，客户103企图进行第一个需授权对话的事务处理。

在步骤205，客户经由HTML格式输入用户ID401和口令。为了 保密，在客户和服务器组间传递的信息最好用如安全层(SSL)这样的 系统加密。(关于SSL的资料，见A.O.Frerier，P.Karpton和P.C. Kocher，“SSL协议版本3.0”，Internet Draft，1996年3月， httP：∥home.netscape.com/eng/ss13/ssl-toc.htme)。

在步骤207，被客户连接的服务器检查客户是否已输入有效的用户 ID401和口令。如果被客户连接的服务器是一个参与服务器，这个服务 器必须连接控制器以确认用户ID401和口令。如果客户还没输入一个有 效ID401和口令，错误处理在步骤206进行。

步骤206能用几个方式实施。作为第一个方案，能给客户一个新的 机会来输入用户ID401和口令。作为第二个方案，能给客户作为一个新 用户注册的机会。在这种情况下，会提示客户输入进一步的信息如名 字、地址和电话号码。作为第三个方案，对话会用一个出错消息终止。 最后一个方案是处理误差处理的优选方法。当然，其他方法也是可能 的。

如果在步骤207中已输入一个有效用户ID401和口令，则控制器在 步骤208产生一个会话ID402。会话IDS被用于在对话期间授权客户。 会话ID被从足够大的关键字空间随机地选择以便一个有恶意的用户不 可能猜出它。控制器把用户ID和会话ID保持在数据库中。(也可使用 其他存储方法，例如一个文件系统)。当前的会话ID改写特定用户ID 的任何以前储存的会话ID。

在步骤208，被客户连接的服务器将对话中的用户ID401和会话 ID402作为状态变量保存。如在本说明书和附加的权利要求中所使用 的，保存在对话中的状态信息意思是保存这些信息以便服务器组中的任 何一个服务器将能在对话期间同客户的未来通信中获得对这些信息的 访问。

在步骤208，服务器也以所访问节点状态变量403的形式编码它的 标识，以及保存对话中所访问节点状态变量。所访问节点状态变量403 包括表示自授权以来已被客户访问过的参与服务器的一个或多个状态 变量。有可能用一单个变量表示所有已被访问过的服务器。然而，合乎 需要的是，用多个变量表示较多的详细的信息，如在授权前已访问过的 参与服务器，在授权后被访问的参与服务器，以及在其中简单的事务处 理已被完成的参与服务器。

控制器为授权客户储存在它的数据库里的状态信息和在对话中保 存的状态信息不必相同。一个可以包含比另一个或多或少的状态变量， 然而，至少有一些储存在每个里的变量是相同的。例如，在我们的优选 实施例中，用户ID和会话ID变量既被储存在控制器的数据库里又在对 话中被保存。如在本说明书和附加的权利要求中所使用的，术语“客户 授权信息”系是一组既被服务器储存又在对话中被保存的变量。

为保存在对话中的状态变量的优选方法是动态变元嵌入。在动态变 元嵌入时，一个服务器递推地将状态信息嵌入到它发送给一个客户的继 续里。利用这个方法，凡客户选择一个继续时，它就将状态信息作为继 续的部分发回给服务器。服务器则按需要检查状态信息、处理请求、以 及再一次将状态信息嵌入下一组发送给客户的继续中。

在万维网的上下文中，动态变元嵌入修改保存状态信息的超级链 接。一般说来，为调用一个称为变元嵌入器的特殊程序，超级链接被改 变。变元嵌入器将保存在超级链接中的状态信息传递到Web站点上的 其它CGI正本。另外，变元嵌入器修改所有在得到的CGI正本的输出 中的超级链接以便调用它本身。于是，一个跟踪利用动态变元嵌入保存 状态的对话的客户被传递所有调用变元嵌入器的超级链接。

图6说明利用动态变元嵌入在Web上的超级链接中保存状态信息 的方法。在步骤601，一个客户调用一个Web站点上的CGI正本P1。

在步骤603，CGI正本P1确定状态变量X1、X2……Xn应被嵌 入对话中以便这些变量对在对话期间可被调用的所有CGI正本将是可 访问的。CGI正本P1为客户继续对话产生一个有超文本链接的HTML 页h。然而，不是直接将页h返回给客户，而是P1调用一个称为embed1 的变元嵌入器的模块。CGI正本P1将页h和状态变量X1、X2…… Xn传递给embed1。

在步骤605，embed1模块修改在页h中的所有超文本链接以便调 用另一个被称为embed2的变元嵌入器模块。被传递到embed2的变元 取决于在页h中的链接是到HTML文件还是到CGI正本。如果在页h 中的链接是到一个HTML文件，embed2对这个文件传递绝对参照和 所有状态变量。如果在页h中的链接是到一个CGI正本，embed2对 CGI正本传递绝对参照、对CGI正本传递原来变元传递一个定界原来 变量结束的参数以及状态变量。

例如，假定CGI正本P1同一个HTML页一起传递状态变量X1＝ 32和X2＝45到embed1，这个HTML页包含二个超级链接：

(1)“http：∥www.watson.ibm.com/mail.html”；以及

(2)“http：∥www.watson.ibm.com/cgi-bin/prog？arg1＝55”。

模块embed1将这二个超级链接分别转换到：

(1)“http：∥www.watson.ibm.com.cgi-bin/embed2？ url＝∥www. watson.ibm.com/mail.html&X1＝32&X2＝45”；以及

(2)“http：∥www.watson.ibm.com/cgi-bin/embed2？ url＝∥www.waston.ibm.com/cgi-bin/prog&arg1＝ 55&comma＝1&X11＝32&X2＝45”。

在第二个超级链接中的“comma＝1”字符串允许embed2从状态 变量X1和X2中区分出原来的变元arg1。任何唯一的变量名能被用作 定界符。如果有“comma”会同另一个同名变量冲突的危险，一个较 复杂的方法能被用于挑选一种唯一的定界符变量名。

在步骤607，embed1模块发送一个HTML页h′到由被修改的超 级链接组成的客户。在页h′中的所有超文本链接都是对embed2的调 用。

在步骤609，客户从页h′中选择一个超文本链接继续对话。这个超 文本链接调用模块embed2。

在步骤611，embed2处理请求。如果到embed2的变元包含一个 文件，则这个文件被取出。如果到embed2的变元包含一个对CGI正本 的调用，则CGI正本同原来的变元和一个状态变量一起被调用。利用 在上面给出的例子，如果第一个超级链接被客户选取，embed2将取出 文件“mail.html”。如果第二个超级链接被客户选取，embed2将用 具有原来变量arg1＝55和状态变量X1＝32和X2＝45的CGI正本 “prog”。

在步骤613，一旦适当的HTML文件被取出或CGI正本被调用， 则得到的输出和状态变量被传递给embed1。然后，过程返回到步骤 605，在这个步骤中，embed1修改在输出中的超级链接。(下列资料 中提供动态变元嵌入的充分讨论：“用无状态网络协议保存状态”，美 国专利申请号08/660,633，1996年6月7日申请。)

虽然动态嵌入是保存对话中的状态的优选方法，但也能使用 NETSCAPE“cookies”。NETSCAP“cookies”是非标准HTTP特 征，借助它把一个HTTP目标返回给客户的服务器，也可以发送一段客 户储存的状态信息。包括在状态信息中的有对其状态信息有效的URL 的范围的描述。如果一个客户支持NETSCAPE“cookies”，客户将 检查它发送的任何HTTP请求以便看一个请求的URL是否落在客户已 储存的任何未过期的cookies范围内。如果一个HTTP请求落在 “cookies”所规定的范围内，客户将包括对应于那个“cookies”的状 态信息同它的HTTP请求。(关于NETSCAPE“cookies”的全面讨 论，见“持久客户状态HTTP cookies”，Netscape通信公司，1996， http：∥home.netscape.com/newsref/std/cookie-spec.html.)

使用动态变元嵌入有超过NETSCAPE cookies的优点。通过使用动 态变元嵌入，所有状态信息的寿命同对话的寿命联系在一起。每次在客 户和服务器组之间开始一个新的对话时，都产生新的状态信息。使用 cookies，不可能将状态信息的寿命同对话的寿命联系在一起。cookies 的另一个缺点是，它们不是标准HTTP协议的一部分，因此不可能同所 有的客户和Web服务器一起工作。相对照地，动态变元嵌入同任何支 持HTTP的客户或Web服务器一起工作。动态变元嵌入的另一个优点 是，通过高速缓存对应于客户上的不同帐号的Web页，可以同时提供 对多个帐号的访问。

HTML表格也能用于保存状态。HTML表格被服务器用于嵌入隐 变量到表格中，当客户提交表格时表格被返回给这个服务器。然而， HTML表格的使用是有限制的又是麻烦的，这因为为保存整个对话期间 的状态信息，这个服务器必须总要响应具有动态生成的HTML表格的 客户。

在步骤300，进行事务处理。如果这个事务处理是个简单事务处理， 则参与服务器或控制器独自管理这个事务处理。如果被请求的事务处理 是来自控制器的成组事务处理，则处理按图3中的步骤来管理。

在步骤209，管理简单事务处理的服务器返回HTML页到具有用 于继续对话的超文本链接的客户。在这一页发送到客户之前，状态信息 可被包括在这一页中。例如，如果服务器组正在使用动态变元嵌入，那 么在这页上的超文本链接必须如上面所讨论的被修改。即使服务器组没 有使用动态变元嵌入，它也许有必要修改页中的超文本链接以便使系统 能跟踪自客户授权以来已被访问的参与服务器。例如，如果必要的话， 为调用将更新被访问节点状态变量403的一个CGI正本，在对应于未 在发送这页的参与服务器的页中的超文本链接应被修改。

在步骤210，一旦进行一个事务处理，并且一个响应页已被返回到 客户，客户通过从响应页中选择一个新的超文本链接继续对话(有可能 结合输入其他信息)。

在步骤211，如果在步骤210所选择的超文本链接指向一个参与服 务器，CGI正本确定这个服务器自授权以来是否已被访问过。通过检 查被访问节点状态变量403来确定。如果这个服务器自授权以来还未被 访问过，在步骤212中，这个服务器被加到被访问节点状态变量403上。

在步骤213，被客户连接的服务器确定客户是否已试图进行需要授 权的事务处理。如果客户还没有，在步骤300进行事务处理。

如果这个服务器确定需要授权的事务处理已被选择，在步骤214处 理继续。在这个步骤中，服务器检验用户ID40和会话ID402是有效的。 如果这个服务器是参与服务器，在一个优选实施例中，为检验用户ID 和会话ID的有效性，必须连接控制器。如果用户ID和会话ID不是有 效的，在步骤215进行错误处理，如以前关于步骤206所说明的，错误 处理能用几个方式管理，但较可取的是服务器通过响应于包含出错消息 的页来结束对话。如果用户ID和会话ID是有效的，如前面所述，在步 骤300进行事务处理。

如果被客户请求的事务处理是成组事务处理，按照图3中本发明的 优选实施例参与服务器间的协调被进行。

在步骤303，控制器构造一参与服务器缺省组，这组服务器由自授 权以来被访问过的所有参与服务器组成。这个信息被包含在被访问节点 状态变量403中。客户有这样选择：或者接受这个缺省组，或者用它自 己选择的参与服务器组代替这个缺省组。

成组事务处理可以分n个阶段进行，其中一些有限的n＞0。前n-1 个阶段被称为准备阶段。后面的阶段被称为委托阶段。步骤304确定是 否还需要进行任何准备阶段。如果继续要进行一个准备阶段，在步骤 306，控制器发送适当的准备消息到在步骤303中被规定的组中的所有 参与服务器。

在步骤307，控制器收集来自所规定组中的所有参与服务器的响应 并将这些响应加到来自以前阶段的响应上。参与服务器用确认的响应或 否认的响应来响应。如果参与服务器不能在超时期间内响应，则响应被 假定为是否认的。作为这些响应的一部分，参与服务器可以发送HTML 文本。因为HTML文本的格式是灵活的，所以每个参与服务器能发送 对成组动作的定制的响应，成组动作包括参与服务器选择的超文本链 接、图象和多媒体内容的组合。

在步骤309，控制器检查所有响应是否是确认的。如果任何参与服 务器的响应是否认的，处理转移到步骤311。在步骤311，控制器通知 在步骤309被确认响应的所有参与服务器准备阶段失败。

在步骤312，控制器将来自被确认响应的参与服务器的响应同一个 这样的信息一起合并成一单独页，即这个信息通知客户失败的准备阶段 和使准备阶段失败的参与服务器。返回到客户的这页也包含为客户继续 对话的超文本链接。

如果控制器在步骤309确定一个准备阶段在所规定组中的所有参与 服务器上成功，处理返回到步骤304。如果所有准备阶段都成功地完成， 处理进行到步骤305。在步骤305，控制器发送委托信息到所规定的组 中的所有参与服务器。

在步骤308，控制器收集来自在所规定组中的所有参与服务器的响 应。如上所述，参与服务器可以在它们的响应中包括HTML文本。在 步骤310，控制器通过合并若干项产生发送到客户的一单独页响应。首 先，控制器将在步骤308收到的所有响应同以前在步骤307从准备阶段 收集的响应合并。然后，控制器加上一个表示所有准备阶段已成功的消 息。如果一个参与服务器在步骤308不能在超时期间内响应，控制器也 可将这个信息加到响应页上。最后，包括允许客户继续对话的超文本链 接。还有，在这页被发送到客户之前，为保存状态信息或者为使系统能 跟踪以前访问的节点，这页的修改或许是必要的。

在上述实施例上可能有许多扩展和变种。一个可能的变种是限制会 话ID的寿命。当会话ID在步骤208被建立时，控制器可以记录每个会 话ID的寿命和建立时间(称为短暂会话ID)。凡在当前时间和建立时 间之间的差超过短暂会话ID的寿命时，短暂会话期ID届满。短暂会话 ID的届满能在步骤214被检查。如果客户试图一个具有届满的短暂会话 ID的事务处理，则在步骤215进行错误处理。处理届满的短暂会话ID 的优选方法是要求客户通过提交一个有效的用户ID和口令重授权它自 己。

另一个可能的变种是生成一个具有每个事务处理请求的新会话 ID。这样，每个会话ID只适合一个事务处理。这个方法会使存心不良 的介入者难以窃取会话ID和闯入帐号。为实现这个变种，步骤214可 被修改为使以前的会话ID失效、产生一个新的会话ID、记录这个新的 会话ID以及保存新会话ID到对话中。

另一个可能的变种是在会话IDS被发送到客户之前加密它们，并在 它们被控制器授权之前使它们解密。如果使用诸如动态变元嵌入或 cookies技术，则加密功能会根据会话ID被传递到的URL产生不同的 编码。因此，访问不同的URLs会需要不同的加密会话ID。存心不良 的介入者设法窃取加密的会话ID，他只能对于一个特殊的URL使用它 (并可能地只用一特殊组的变元)。这会限制这类人可能造成的损害。

另一个可能的变种是，控制器要求由于一个特殊的会话ID的所有 事务处理都来自与参加建立会话ID的授权过程的客户相同的IP地址。 为实现这个特点，当会话ID在步骤208中被建立时，客户授权自己的 IP地址被记录。在步骤214，只要作出请求的客户的地址与授权自己的 客户的地址相同，事务处理就将被允许进行。这个方法或许能防止一个 存心不良的用户从一个客户窃取会话ID和用这个会话ID从其他机器闯 入这个客户的帐号。然而，这是不安全的，因为不同的机器能出现有相 同的IP地址(例如，当这些机器在同一防火墙后面时)。如加密这样 的其他安全特点可与这个方法结合使用以减小闯入帐号的危险。

另一个可能的变种是，由控制器保持的客户授权和帐号信息(例 如，用户ID、口令和会话ID)被复制在一个或多个参与服务器上。这 样，对于每个授权，不需连接控制器。这个方法会减轻控制器上的负担 并能改进系统性能。然而，为保持在授权和帐号信息的多个拷贝之间的 一致性，会需要某个方法。

另一个可能的变种，能改进繁重工作负担的系统性能，是标定控制 器在多个服务器上运行。然而，标定控制器在多个服务器上运行的复杂 性之一是如何在多个节点上共用授权信息问题。授权信息能被复制在多 个节点上，但由于保持授权信息多个一致的拷贝的辅助操作和复杂性， 合乎需要的是只保持在步骤208记录的授权信息的一个拷贝。

为当一个控制器在多个节点上被标定时保持授权信息的一个解决 方法是分配一组所有会话ID(属于当前同服务器组通信的所有客户) 在控制器节点上。于是，任何一个特定会话器ID的只单独一个拷贝被 保持，但这组会话ID被分配在各控制器节点上。为实现这个方法，在 步骤208控制器会储存一个特定客户的会话ID信息在一个控制器节点 上。控制器节点n的标识则会被编码成同那个客户对话中的一个状态变 量。例如，会话ID变量402可被编码以便既储存实际的会话ID也储存 已储存客户的会话ID的控制器节点。凡在客户企图进行需要它的会话 ID授权的事务处理时，步骤214检查在同客户的对话中所保存的适当状 态变量以便确定哪个控制器节点包含这个客户的会话ID。然后，客户 的会话ID在适当的控制器节点上被检验。

如同在客户授权信息的情况下，客户帐号信息能被复制在多个控制 器节点上或者分配在多个控制器节点上。采取哪个方法的决定能被与哪 个方法被用于客户授权信息无关地做出。如果客户帐号信息被分配在多 个节点上，则上述方法能被使用。包含一个特定客户的帐号信息的控制 器节点的标识能被编码成一个如用户ID变量401这样的状态变量。

另一个可能的变种是允许客户执行一些通常由服务器组执行的功 能。利用如JAVA这样的语言，一些由服务器执行的功能能被客户下载 和执行。

另一个可能的变种，不是在对话中既保存用户ID状态变量又保存 会话ID状态变量，而是只保存会话ID状态变量。在这个执行中，服务 器将保持用户ID和会话ID间的对应性。然后，服务器将能够从会话ID 计算出用户ID。

另一个可能的变种是保持客户的口令作为状态变量，而不是产生会 话ID状态变量。但是，由于会话ID持续如同对话那么长时间，所以使 用会话ID而不使用口令的优点是一个被窃取的会话ID或许有可能比一 个被窃取的口令损害小。

另一个可能的变种是执行XA协议处理多阶段委托。(关于XA协 议的讨论，见J.Gray和A.Reuter，事务处理：概念和技术，Morgan kaufman，1993)。

在我们的优选实施例中，用于成组事务处理的缺省参与服务器组由 在授权时和成组事务处理被请求时之间已被访问的参与服务器组成。关 于选择一缺省组能容易地实现若干变化。一缺省参与服务器组可由以下 组成：(1)自对话开始以来已被访问的所有服务器；(2)自对话开 始以来已被介入的所有服务器；(3)自最后的成组事务处理以来已被 访问的所有服务器；(4)自最后的成组事务处理以来已被介入简单事 务处理的所有服务器；以及(5)参加最后的成组事务处理的所有服务 器。另外，以上缺省组的组合也是可能的。

一般地，缺省组能相对于事务处理类型、授权证类型和关键事件被 确定。事务处理可被分类成包括但不限于如下的组：(1)所有事务处 理；(2)简单事务处理；以及(3)成组事务处理。事务处理还可按 照授权类型被分类，如：(1)所有事务处理；(2)其中需要授权的 事务处理；(3)其中不需要授权的事务处理。关键事件是由事务处理 确定的对话期间中的时间点。例如，如下可以是关键事件：(1)一次 对话的开始；(2)客户最初提供有效标识信息的瞬间；(3)最后的 成组事务处理。缺省组可以相对于一关键服务器子集CS(i，j，k)来 规定。CS(i，j，k)是提供j型事务处理和k型授权的事务处理的自关 键事件i以来客户已同其通信的服务器子集。例如，利用上面规定的分 类，关键服务器子集CS(3、1、2)是在其上进行要求授权的事务 处理的自最后的成组事务处理以来客户已同其通信的服务器的子集。

另一个可能的变种是规定一种不依赖于被访问的参与服务器的缺 省组。在这个执行中，被访问的节点状态变量403不需要被保存，而且 不需要步骤211和212。

也有可能让一个参与服务器同多个控制器通信。如图4所示，也可 能有控制器的层次，在这里一个控制器协调发自它下面层中的控制器和 参与服务器的动作。

在我们的优选实施例的图3的步骤310和312中，控制器按一单独 HTML页发送所有信息到客户。如果信息量大，一个选择会是将信息分 成若干页。控制器一次发送一页。每页将含有允许客户看其他页的超文 本链接。按如下的(可能是几个)超文本链接，客户将能看到全部信息。 当然，这个技术不是新的。例如，在URL http：∥ww.lycos.com的Lycos 搜索引擎程序履行这个方法。

另一个可能的变种是用数字证书识别客户，代替揭示客户手工输入 标识信息。一个数字证书是一串标识信息，它可以被储存在客户的磁盘 或智能卡上。因为数字证书由比一个客户能被期待用手输入的信息字符 串长和复杂的信息字符串组成，所以，数字的使用可提供比让客户手工 输入标识信息更安全的识别客户的方法。另外，也可使用数字证书和手 工输入的组合。例如，一个客户可被要求输入个人标识号(PIN)激活 他或她的卡。

在上述的优选实施例中，客户帐号信息被服务器控制器保持。另一 个可能的变种是对控制器同管理当局通信以检验由客户提供的客户标 识信息。

虽然本发明已参照某些优选实施例被说明，但是其他实施例也是可 能的并对本专业技术人员来说是明显的。因此，附加的权利要求的精神 和范围不应被限于包含在本发明中的优选实施例。