深蓝海域KMPRO

bindingTemplate与Web服务调用

2002-08-23 08:32

bindingTemplate与Web服务调用




柴晓路 (fennivel@uddi-china.org)

Chief System Architect

2001年11月22日

本文通过介绍UDDI数据模型中的bindingTemplate数据实体，对如何使用bindingTemplate中的信息实施Web服务调用进行了讨论，阐明了利用缓存bindingTemplate加速服务多次调用的方法，也介绍了在灾难恢复的情况下如何再次缓存的方法。同时通过对hostingRedirector的功能的分析，介绍了简单间接模式和重定向模式对于非直接提供服务，而是由ASP供应商提供服务这一模式的重要性。

Web服务的技术描述是通过单独包含的bindingTemplate结构的实例来实现的。这些结构提供对决定技术入口点的支持，或者可选地支持远端主机宿主的服务，同时还提供一个轻量级的工具用于描述指定服务实现的唯一技术特征。技术和应用相关的参数和配置文件也同时被支持。

由于UDDI的主要作用是用来描述和发现Web服务信息，所以bindingTemplate被用来描述最令人感兴趣的技术信息。

每一个bindingTemplate结构都有一个单一的businessService逻辑父结构，并且该businessService也有一个单一的businessEntity逻辑父结构。

bindingTemplate结构规范














下层子结构说明

下面用粗体表示的字段是必要字段，必须出现。

字段名 描述 数据类型 长度
bindingKey 给定的bindingTemplate的唯一的键值。当保存一个新的bindingTemplate结构时，应当传入一个值为空的bindingKey值。上述操作将促使UDDI注册中心生成一个新的UUID值。为更新一个已经存在的bindingTemplate结构，应当传入与该绑定信息相对应的UUID值。如果数据是通过一个查询操作得到，bindingKey值可以不为空。 UUID 41
serviceKey 当bindingTemplate数据包含在一个已经完整表达信息的同时已经包含一个serviceKey值的businessService父结构时，这个属性是可选的。如果bindingTemplate数据被生成为XML文档，同时这个文档中没有包含一个具有serviceKey的businessService父结构，那么必须在bindingTemplate中提供父结构的serviceKey值。这种行为支持了以任何核心元素作为起点而进行浏览的行为，在这种情况下这样的数据描述能够轻松地处理核心元素给定的父/子关系。 UUID 41
description 可选的可重复元素。对技术服务入口点的具备国家语言代码修饰的零个或多个文本描述。 string 255
accessPoint 必要的由属性修饰的数据元素。本元素是用来描述为调用服务所需的合适入口点地址的文本字段。它可以是URL、e-mail地址，或者是一个电话号码。在对于该Web 服务的技术要求有所了解之前，不应当对该文本栏中出现的信息有任何的理解假设。 string w/attributes 255
hostingRedirector 如果没有提供accessPoint元素，那么本元素是必须的。这个字段是一个可重定向到另一个bindingTemplate的引用。如果你查询一个bindingTemplate并且在其中找到一个hostingRedirector的值，你就应该获取这个重定向的bindingTemplate，并且将该bindingTemplate取代原先那个包含hostingRedirector的bindingTemplate。 empty w/attributes
tModelInstanceDetails 本结构是一个tModelInstanceInfo的列表。这些信息的全体形成了一个可区别的技术指纹，可用于标识兼容的服务(具有相同技术指纹的可认为是兼容服务)。 structure


accessPoint和hostingRedirector子元素应当必须出现一种，并且仅能出现一种。

名为tModelInstanceDetails 的结构的内容可以在bindingTemplate结构中被发现同时是作为技术指纹服务于服务描述的。这一技术指纹是一系列对可唯一标识的规范和/或概念的引用。为了实现一个与某个tModel兼容的新的服务，该tModel所对应的规范是必须被正确理解的。而为了注册一个服务并声明它是与某个规范相兼容的，那么应当在该服务下的bindingTemplate实例中的tModelInstanceDetails下包含一个对该规范的tModel的引用，引用的键值是tModelKey。

accessPoint

accessPoint元素是一个由属性修饰的指向服务入口点的指针。在这里表示的元数据层次的服务概念是相当抽象的，同时在这里出现很多服务入口点的类型都是合适的。

一个名为URLType的属性被提供用于修饰accessPoint元素。设置该属性的目的是为了查找匹配指定服务入口点类型的那些特定服务入口点。例如，一个采购订单服务提供了3个入口点，一个是基于HTTP，一个是基于SMTP的，还有一个是基于FAX的。在这个例子中，我们就可以去查找一个businessService元素，该元素包含有个3个bindingTemplate条目，每一个都包含相同的数据，除了accessPoint的值及其附带的URLType的值是不同的。

URLType的有效值包括:

mailto: 表明accessPoint的内容字符串是电子邮件的格式。(例如，mailto:program@uddi-china.org)

http: 表明accessPoint的内容字符串是一个兼容HTTP规范的URL(统一资源定位符)的格式。(例如，http://www.fabrikam.com/purchasing)

https: 表明accessPoint的内容字符串是一个兼容安全HTTP规范的URL(统一资源定位符)的格式。(例如，https://www.fabrikam.com/purchasing)

ftp: 表明accessPoint的内容字符串是一个可写的FTP目录地址的格式。 (例如，ftp://ftp.dealeasy.com/public)

fax: 表明accessPoint的内容字符串是一个可连入某个传真机的电话号码的格式。(例如，1 425 555 5555)

phone: 表明accessPoint的内容字符串是一个可与某人联系或与某个语音/音频响应系统相关联的电话号码的格式。 (例如，1 425 555 5555)

other: 表明accessPoint的内容字符串是其他的寻址格式。当使用该值时，一个或多个在tModelInstanceInfo聚集中的tModel必须蕴含一个必需的特定格式或传输类型。

hostingRedirector

hostingRedirector元素被用来表明这个bindingTemplate条目是一个指向另外一个bindingTemplate的指针。当一个商业实体想发布一个服务描述(例如，宣布他们有一个特定用途的服务已经可用了)，而这个服务已经在另一个独立的bindingTemplate中被描述了，此时就会使用这种机制。该情况可能发生于，当服务是部署在远端主机上的(这也是本元素名字的由来)，或是当很多的服务描述可以基于一个单一的服务描述。

hostingRedirector元素只有一个单一的属性而没有元素的内容。这个属性是一个bindingKey值(UUID)，这个bindingKey值可以用于在同一个UDDI注册中心实例中查询和获取将要被使用的bindingDetail数据。

关于hostingRedirector元素的使用，我们将在后面详细给出。

tModelInstanceDetails

这个结构是一个或多个tModelInstanceInfo结构的简单容器。当以一个信息组的形式被使用的时候，在tModelInstanceDetails结构中描述的数据就形成一个描述性的技术指纹，这个技术指纹是通过在这个结构中包含了一个无顺序的tModelKey引用的列表而表现的。也就是说，如果有用户注册了一个bindingTemplate(在一个businessEntity数据集内)，那么它就会包含一个或多个对于特定的并且是可标识的规范的引用，这些规范是在注册过程中通过tModelKey值所蕴含的。在对于一个服务的查询过程中，有兴趣的用户会利用这些信息来寻找一个特定的包含有一个甚至多个指定的tModel引用的bindingTemplate。如果通过这个方式来注册特定的技术指纹，那么软件开发人员就能够很容易地以这种方式表示出他们所提供的服务能够与tModelKey所蕴含的规范相兼容。

基于bindingTemplate的服务调用模式

当我们需要编制实现一个应用程序：这个应用程序需要使用一个已被其它商业实体注册在UDDI注册中心的远端Web服务，那么你需要从注册中心中发现为调用指定服务所需要的调用规范信息，并在程序编制时使用。这种类型的跨商业实体的服务调用在传统上将被视为是开发阶段的任务。尽管，这样的开发模式并不会因UDDI注册信息的出现而完全改变，但起码，如果使用了UDDI注册所支持的特别的调用模式，将可以解决一个非常显著而重要的问题。

从UDDI注册中心中获得的bindingTemplate信息集中的数据表示了一个指定的远端Web服务的调用规范实例。程序应当缓存该信息并且使用这个调用规范通过该Web服务注册的地址来访问这个Web服务。使用以前流行的远程过程调用技术的工具已经能够将这样一种工作自动化地实现，无论是通过缓存其调用位置或是通过写入固定代码的方式，都可以做到。然而，当远程服务在没有通知调用者的情形下发生了迁移，那么就会引起问题，该程序无法自动地更新访问代码或访问地址。这样的迁移可以是由各种原因造成的，包括服务器升级，灾难恢复以及服务入口或企业名称的改变等。

当使用从UDDI注册表中获得并缓存下来的信息进行调用发生失败时，正确的做法是去查询当初获得该数据的UDDI注册中心并获取与其对应的更新了的bindingTemplate信息。正确的调用是使用get_bindingDetails，并传入原始的bindingKey键值。如果返回的数据与缓存的信息不同，那么应该使用新的调用信息来重新尝试服务调用。如果这一重试操作获得成功的话，新的信息应当取代原先缓存的信息进入当前的缓存。

在使用Web服务中，使用这样的调用模式，那么使用UDDI操作入口站点(Operator Site)的商业实体就得以在不加重通信与协调开销的情况下自动完成与大量合作伙伴的服务恢复。例如，如果一个企业激活了一个灾难恢复站点以取代某个崩溃的原服务提供站点，来自合作伙伴的大部分调用想访问那个已经崩溃的服务提供站点时，会遭遇失败。通过把新的提供服务的地址更新到UDDI信息中，那些使用调用模式的合作者将可以自动地获取新的服务调用信息并在无需管理员介入的情况下恢复系统连接。

这一过程的详细程序式描述如下：

服务提供者使用save_xx在UDDI注册中心中注册了Web服务S；

调用者使用find_xx查询UDDI注册中心，获得所需的服务S的概要信息；

调用者使用get_xx再一次查询UDDI注册中心，获得所需服务S的详细信息；

调用者缓存服务S的bindingTemplate信息，通过服务绑定，实施对服务S的调用；

服务S由于某种原因出现问题，无法继续提供服务；

服务提供者在新的位置重新部署了服务S，同时更新了UDDI注册中心的关于Web服务S的技术描述；

调用者使用缓存的服务S的bindingTemplate信息再一次进行调用，调用失败；(服务S的部署位置已经更改)

调用者使用缓存的bindingTemplate的bindingKey键值查询UDDI注册中心，获得服务S的更新后的bindingTemplate信息。

调用者缓存服务S的新的bindingTemplate信息，通过服务绑定，重新实施对服务S的调用。

服务重定向

在许多情况下，在get_bindingDetail消息中定义的API是直接的。当一个企业或应用程序知道需要调用的服务时，该服务相关的bindingTemplate信息就可以被缓存以供使用。如果缓存信息在真正需要被调用时发生失败的话(比如被缓存的bindingTemplate结构的accessPoint信息被用于调用一个远程的合作伙伴所提供的服务)，该应用可以通过被缓存的信息中的bindingKey来得到一个bindingTemplate信息的最新副本。这种缓存操作可以避免多余的对注册中心的访问。

然而在一些情况下，通过get_bindingDetail消息获得的bindingTemplate所描述的信息并非是直接的某个Web服务的绑定信息，在这个bindingTemplate中可能通过hostingRedirector机制指向了另一个bindingTemplate，而由这个bindingTemplate完成对目标服务的最终描述。这就是间接描述的使用方式。

需要使用hostingRedirector的特殊情况

两种不能被bindingTemplate中accessPoint信息直接支持的特殊需求是：

Web服务在技术上由第三方提供主机：一个企业可以选择这样一种方式来发布一种服务，该服务逻辑上属于本企业，但实际上该服务是在远程的或者第三方的主机上运行的(比如ASP模式的企业应用)。应用服务提供商和网络交易市场运营商是这种情况的典型代表。在这种情况下，实际上是作为第三方的应用服务提供商和网络交易市场运营商实际上控制了绑定信息bindingTemplate的运行时态的取值。

由用户指定的对绑定位置的访问控制：在其他情况中，比如与调用上下文相关的重定向是基于调用者的用户标识的(比如具备某种权限的用户被重定向入一个管理入口，而其他用户被重定向入一个普通入口)，或者甚至是每天的路由，此时，提供更动态的对远程服务的实际联络信息的方式是非常必需的，相比起缓存accessPoint数据以支持调用的方式更为必要。

由于这些原因，bindingTemplate结构包括了另一个数据元素，被称为hostingRedirector。hostingRedirector元素的存在表明了调用者如果需要调用由指定bindingTemplate所表示的Web服务时必须使用一个额外的步骤去获得accessPoint信息(即，调用地址)。当在解析一个hostingRedirector引用时，需要经过两个步骤。

使用hostingRedirector数据

当一个包含hostingRedirector元素的、同时表示了一个服务入口(称为服务绑定)的bindingTemplate被UDDI注册中心返回时，程序员可以使用该信息来定位实际的描述站点服务的bindingTemplate，这个实际的描述站点服务的bindingTemplate包含了描述真正提供服务的主机的相关的accessPoint信息。

一般的，hostingRedirector元素的内容包括一个bindingKey，该键引用了另一个bindingTemplate。这个包含在hostingRedirector元素中的、引用了在同一个UDDI注册中心中的另一个bindingTemplate的可解析的bindingKey是在最初的get_bindingDetail消息返回的。

在访问这第二个绑定信息(称为间接绑定)之后，调用者就可以完全着眼于这个间接绑定的技术指纹。如果这个间接绑定的技术指纹与服务绑定的技术指纹是一样的，那么这个间接绑定中的accessPoint就可以用来与最终的Web服务交互。hostingRedirector的这种使用方式称为简单间接模式(simple indirection)。如果，这个间接绑定的技术指纹表明这个间接绑定是实现了一个hostingRedirector服务，那么需要再一次使用get_bindingDetail消息，这个消息被发往在这个间接绑定信息中包含的accessPoint所指明的地址，以获得真正的服务绑定信息。hostingRedirector的这种使用方式称为重定向模式(redirection)。

在简单间接模式中，描述最终服务的bindingTemplate将简单地被初始的服务绑定所引用。在这种场合下，并没有复杂的逻辑。(参见下图)

Figure 1. 简单间接模式示意


而对于重定向模式，以下的具体描述表述了重定向使用的步骤：

一个商业实体为一个寄宿于远程站点或需重定向的商业服务S注册了一个bindingTemplate A。这个bindingTemplate包括一个bindingKey值Q来引用另外一个bindingTemplate B。这个bindingTemplate B典型地由提供重定向服务的组织来控制。这个bindingTemplate B包含了指向实际上的hostingResirector服务R的accessPoint元素。

应用程序需要调用步骤一中注册的服务S，首先需要得到公布的服务的绑定信息。这个bindingTemplate信息包含了一个hostingRedirector元素，该元素同时包含了对应于bindingTemplate B的bindingKey值K。

程序员使用bindingKey值K对原始bindingTemplate A所在的UDDI注册中心发送get_bindingDetail消息。这样就能得到返回的bindingTemplate B。现在程序员就能得到实现重定向的服务的地址。这个信息就是在bindingTemplate B中所能找到的accessPoint元素。该服务知道如何响应get_bindingDetail消息。

使用最初的bindingKey值Q，并发送一个get_bindingDetail消息到重定向服务R。这个服务负责返回被重定向的商务服务S的实际绑定信息或者返回一个错误信息。如果需要，程序员可以选择缓存这个bindingTemplate。

使用上述这个算法，一个为其他企业提供主机服务的机构可以控制实际访问该服务的信息。这不仅可以帮助提供主机服务的组织对各种情况实施有效管理，比如灾难恢复，而且可以让他们定义访问实际上被调用的商务服务所使用的URL。这个URL可以由调用者来指定，也可以是一个宿主机或重定向服务的通用地址。(参见下图)

Figure 2. 重定向模式示意

使用重定向服务的意义就在于那些提供ASP或者在线交易市场服务的服务提供商能够动态地使用自身的重定向服务来决定某一企业的应用的入口，这对于使用动态路由的网络应用环境或是动态的企业应用解决方案的服务提供商来说，是至关重要的。

在任何情况下，原始的调用者可以在不知道任何重定向存在的情况下，找到实际商业伙伴所发布的Web服务(通过bindingTemplate)，并通过该服务找到实际商业伙伴的数据。

小结

本文通过介绍UDDI数据模型中的bindingTemplate数据实体，对如果使用bindingTemplate中的信息实施Web服务调用进行了讨论，阐明了利用缓存bindingTemplate加速服务多次调用的方法，也介绍了在灾难恢复的情况下如何再次缓存的方法。同时通过对hostingRedirector的功能的分析，介绍了简单间接模式和重定向模式对于非直接提供服务，而是由ASP供应商提供服务这一模式的重要性。

参考资料

作者简介

柴晓路: 系统架构师, Web Service技术顾问, UDDI Advisor Group成员, UDDI规范中文版编辑。专长于Web Service架构、Web Service系列技术以及基于XML的系统集成和数据交换技术，同时对数据库、面向对象技术及CSCW等技术比较擅长。2001年加入UDDI Advisor Group，参与了UDDI Specification V2的开发。目前作为UDDI-China.org的主要核心成员参与UDDI-China.org的核心技术工作。2000年获复旦大学计算机科学硕士学位，曾在国际计算机科学学术会议(ICSC)、亚太区XML技术研讨会(XML Asia/Pacific'99)、中国XML技术研讨会(北京)、计算机科学期刊等各类国际、国内重要会议与期刊上发表论文多篇。

相关推荐