赵 一三 (zhaoyis@cn.ibm.com), 高级软件工程师 , IBM 中国软件开发中心
朱 朴 (zhupu@cn.ibm.com), 软件工程师 , IBM 中国软件开发实验室 SOA 设计中心
2008 年 5 月 19 日 本文主要讲述如何利用 IBM WSRR 来实现多个 UDDI 之间以及 WSRR 和 UDDI 之间的数据同步。
引言
UDDI 是统一描述、发现和集成（Universal Description, Discovery, and Integration）的缩写。它是 OASIS 组织提出的一个基于 XML 的跨平台的描述规范。企业用户可以利用它来发布，查询服务信息构建自己企业信息系统。虽然 UDDI 是一个广泛应用的规范，但是它的一些功能局限，例如缺乏 WSDL 实际数据模型，缺乏服务管理，监管能力等，使它不能适应 SOA 框架对服务灵活部署，调用的要求。
IBM WebSphere Service Registry and Repository(WSRR) 是 IBM SOA 战略中重要组成部分。它除了具有 UDDI 所具有的服务注册的功能还有存储服务信息数据 , 服务监管，管理的功能。
本文主要讲述如何利用 IBM WSRR 来实现多个 UDDI 之间以及 WSRR 和 UDDI 之间的数据同步。
技术背景
虽然 UDDI 有其自身的功能局限，但是作为第一个正式的服务发布规范，现在仍然有很多企业将其业务应用系统架构在 UDDI 标准之上。在一些大型的企业，政府部门内，由于各方面的原因，不同的部门可能采用了不同的 UDDI 产品平台，例如人事部门采用了基于 SAP UDDI 的产品，财务采用了基于 Systinet UDDI 的产品。这种系统平台的异构性也造成了服务整合的极大困难。
IBM WSRR 产品作为 IBM SOA 战略中的重要产品，它提供了比 UDDI 产品更完善的服务管理，监管能力，能够更好的同基于 WS-* 标准的产品协同工作，尤其是能够同 IBM 产品线中的 IBM?WebSphere Process Server，Tivilo ITCAM for SOA 等产品协同工作提供一个统一的，整合的企业服务平台。
IBM WSRR 提供了一个 synchronization module 能够把企业原有 UDDI 中的数据同步到 WSRR。利用这个模块，企业就可以部署新的基于 IBM WSRR 的应用，而原有的信息系统还可以继续在线运行，这样有效的降低了对原有信息系统的影响，保护了企业原有的 IT 投资。
IBM WSRR 6.0.2 的版本能够实现一个 WSRR 和一个 UDDI 产品的数据同步，前提是原有的 UDDI 产品符合 UDDI V3,V2 标准。
在 IBM WSRR 6.1 的版本中，一个 WSRR 可以同多个 UDDI 产品进行数据同步。这些 UDDI 可以 IBM UDDI, Systinet UDDI, SAP UDDI 或者其他产品，只要这些 UDDI 产品符合 UDDI 的 V3,V2 的标准。通过简单的配置，WSRR 就可以同它们进行数据同步。这样通过 IBM WSRR 的同步功能，企业原有的因采用不同 UDDI 产品而割裂，互不联通的企业服务数据就可以统一的，一致的提供给用户。
图 1 应用场景
如图 1，例如财务部门可以继续使用 Systinet UDDI 发布服务数据，新发布的数据可以通过 IBM WSRR synchronization module 同步到 IBM WSRR 上，然后 IBM WSRR 将把这个数据同步到一个人事部门采用的 SAP UDDI 上。这个过程也可以是相反方向的，用户可以在 IBM WSRR 上发布数据，新发布的数据会被同步到相关联的所有 UDDI 上。
下面详细介绍如何利用 IBM WSRR 同步多个 UDDI。
IBM WSRR 如何配置对多个 UDDI 的支持
IBM WSRR synchronization module 以一个 EJB 的形式同 IBM WSRR 一同安装到 J2EE 的服务器上。我们可以通过修改 IBM WSRR 中的 UDDI 配置文件来增加多个 UDDI 的支持。
用户可以通过 3 种方式来修改 UDDI 配置文件
-
WSRR Web UI
-
WSRR MBean 命令
-
UDDI 配置工具
在本文中，只给出如何通过 Web UI 来修改配置文件。
1. 切换到 WSRR 的配置视图
图 2 切换 WSRR 视图
2. 点击 Active Configuration Profile->Plug-ins->UDDI.
3. 点击 UDDIConfiguration 项目，然后选择 Content 标签
4. 修改文件内容，然后点击 OK 应用配置文件内容
在 UDDI 配置文件中，UDDI 配置是在一个 <UDDIREGISTRIES> 元素中定义的，这个元素有如下结构
<UDDIREGISTRIES>
<UDDIREGISTRY>
... XML elements specifying UDDI registry settings ...
</UDDIREGISTRY>
.
.
.
<UDDIREGISTRY>
... XML elements specifying UDDI registry settings ...
</UDDIREGISTRY>
</UDDIREGISTRIES>
|
其中每一个 <UDDIREGISTRY> 代表一个 UDDI 服务器，对于用户想要进行同步的每一个 UDDI 服务器，都必须要用元素 <UDDIREGISTRY> 来进行声明。
元素 <UDDIREGISTRY> 有一个属性 Alias，这个元素用来唯一的标识一个 UDDI 服务器。这个元素的取值必须符合“UDDI.Un”的格式。其中 n 可以取值为 0,1,….. (0 代表第一个 UDDI 服务器，1 代表第二个 UDDI 服务器，以此类推 )
假如用户原有的信息系统中有两个 UDDI 服务器，分别是 IBM UDDI 和 SAP UDDI, 这个配置文件可以表示成
<UDDIREGISTRY Alias="UDDI.U0">
... XML elements specifying IBM UDDI registry settings ...
</UDDIREGISTRY>
<UDDIREGISTRY Alias="UDDI.U1">
... XML elements specifying SAP UDDI registry settings ...
</UDDIREGISTRY>
|
元素 <UDDIREGISTRY> 内部的 XML 内容可以参见 WSRR 6.1 信息中心来进行详细配置，在这个文章附录里面也给出了一个配置多个 UDDI 的配置文件的示例文件。
在应用了如上的支持多个 UDDI 的配置文件以后，WSRR 就每隔指定的时间和多个 UDDI 进行一次数据同步。
IBM WSRR 支持的数据类型
IBM WSRR 同步模块支持如下数据对象
-
WSDL 文档
-
Policy 协议文档
-
XSD 逻辑对象
-
XML 文档
-
Concept 概念对象
-
SCA 模块对象
-
其它类型对象
以上这些对象都能够从 WSRR 同步到指定的多个 UDDI 服务器，除了 SCA 模块对象，XSD 逻辑对象以外 ,UDDI 的实体也能够同步到 WSRR 进而同步到其它 UDDI.
IBM WSRR 同步多个 UDDI 的用户场景
图 2 是该系统的用例图，WSRR2UDDI Mapper 负责将 WSRR 中的数据更新映射到一个或多个 UDDI 中，UDDI2WSRR Mapper 负责从 UDDI 中抓取更新的数据并写入 WSRR 中，通过这两个模块，多个 UDDI 可以以 WSRR 为中介实现数据同步。这两个模块由 Scheduler 来控制，每隔一段时间启动一次同步操作，间隔时间可以按照需求由配置文件动态配置，WSRR 6.1 支持的最小间隔单位为分钟。
图 3? 用例图
Figure xxx. Requires a heading
下面将以 WSDL 为例详细说明如何利用 WSRR 实现多个 UDDI 的数据同步，包括两种典型用户场景：
WSRR 同步到 UDDI（WSRR->UDDI）
WSRR 本身具有 notifier 机制，当用户对 WSRR 中的数据进行更新时，系统会自动产生相应的 notifier 事件 ; WSRR2UDDI Mapper 模块会侦听到这些事件，并对这些事件进行过滤，只有和同步模块支持的数据类型相关的事件才被进一步处理，获取到这些更新以后，WSRR2UDDI Mapper 会从配置文件中读取所有 UDDI 的连接信息，并逐个将 WSRR 中的更新映射到 UDDI 中去，如果其中某个 UDDI 被用户配置为只读，那么更新将不会被写入到该 UDDI 中。
用户在 WSRR 中 load 一个 WSDL 文档，系统会自动创建出该文档的 Document 对象以及该文档所包含的所有逻辑对象 , 图 3 显示了一个示例 WSDL 文档的结构，该结构中每一个元素在 WSRR 中都有与之对应的对象，并且系统会给每一个对象赋予一个唯一的标志，称为 bsrURI。该属性在数据的同步过程中起着非常重要的作用，它负责将 WSRR 中的对象与 UDDI 中的数据实体关联起来。
图 4 示例 WSDL 文档结构
WSRR 中的对象会按照一定的规则被 map 到 UDDI 中去，其中 IBM 定义了两种在 UDDI 中发布 WSDL 的方式：TN202 和 Rational?Web service tooling ，其中 TN202 方式的详细描述可以在如下这个网址中找到：http://www.oasis-open.org/committees/uddi-spec/doc/tn/uddi-spec-tc-tn-wsdl-v202-20040631.htm 。以 TN202 为例，图 3 结构中的 Service 对象会被映射为 UDDI 中的 Business Service 数据实体，Service 对象包含的 Port 对象会被映射为 Binding Template 数据实体，而 Port Type 对象和 Binding 对象都会被映射为 UDDI 中的 tModel 数据实体，如图 4 所示，该 WSDL 文档在 UDDI 中将被分解为一个 Business Service，一个 Binding Template 和两个 tModel。
图 5 WSDL 映射到 UDDI
被映射到 UDDI 中的数据还需要和 WSRR 中的对象建立起关联关系，以 Port Type tModel 为例，图 5 显示了该 tModel 的 category bag 的详细信息。其中 wsrrDocumentBsruri 记录了与该 tModel 对应的 WSDL 文档在 WSRR 中的 bsrURI，wsrrBsrUri 则记录了与该 tModel 对应的逻辑对象在 WSRR 中的 bsrURI。当用户在 WSRR 中更新这个逻辑对象时，系统可以通过该逻辑对象的 bsrURI 在 UDDI 中找出与之对应的 tModel，然后将更新映射到该 tModel 上，当用户在 WSRR 中删除这个 WSDL 文档时，系统可以通过 Document 对象的 bsrURI 在 UDDI 中找到所有与该文档对应的数据实体，然后将他们删除。这样用户在 WSRR 上所做的操作都可以被正确映射到 UDDI 的数据实体上。
图 6 Port Type tModel 所包含的 CategoryBag
该用户场景可以用图 6 来表示，首先用户在 WSRR 中创建一个对象，该对象将通过 synchronization module 被复制到配置文件中描述的所有 UDDI 上去。
图 7 WSRR 同步到 UDDI
多个 UDDI 之间的数据同步 (UDDI<->WSRR<->UDDI)
UDDI 本身不具有 notifier 机制，所以需要定时从 UDDI 中抓取所有的数据，然后通过一定的算法计算出这段时间内更新的数据实体，并将他们映射到 WSRR 中，这一功能由 UDDI2WSRR Mapper 模块实现。
假设用户拥有两个 UDDI：U0,U1，并且在 U0 中以 TN202 的方式发布了一个 WSDL 文档。当 Scheduler 启动 UDDI2WSRR Mapper 时，它会从配置文件中读取到 U1 和 U2 的连接信息，并依次从 U0 和 U1 中抓取更新的数据实体，这时会发现 U0 中新创建了一个 WSDL 文档 , 然后它会调用 WSRR 的 API，将该文档 load 到 WSRR 中去。由于 WSRR 自身的 notifier 机制，它会发出 Document 对象的创建事件，该事件会被 WSRR2UDDI Mapper 模块捕获到，经过处理，它会将该事件的主体——WSDL 文档发布到 U1 中去。如果在用户的应用环境中，存在多个 UDDI，而且其中有些 UDDI 被配置为只读，那么 WSRR 中的数据将会被写入除 U0 和只读 UDDI 以外的其他所有 UDDI。
同样从 UDDI 这边 Map 到 WSRR 中的对象也需要和 UDDI 中的数据实体建立起关联关系，以 UDDI 中的 Port Type tModel 为例，图 7 显示了与之对应的逻辑对象的详细属性信息，其中 UDDI.U0---entityKey 记录了 U0 中与之对应的 tModel 的 key，而 UDDI.U1---entityKey 则记录了 U1 中与之对应的 tModel 的 key。所以无论用户在 U0 还是 U1 中进行更新操作，都可以通过相应的 tModel key 找到 WSRR 中的逻辑对象，并将更新应用到该对象上。
图 8 Port Type 逻辑对象的详细属性信息
该用户场景可以用图 8 来表示，首先用户在 U1 中发布一个 WSDL，该 WSDL 先被 synchronization module 同步到 WSRR 中，然后再通过 WSRR 的 notifier 机制，将更新映射到其他的 UDDI 中去。
图 9 多个 UDDI 之间的数据同步
冲突处理
通过上面的机制，一个数据对象会被复制到不同的 UDDI 上，不同 UDDI 的用户有可能在同一段时间内对同一个数据实体进行不同的操作，这样就会发生冲突，我们需要相应的机制来处理这些冲突，保持 UDDI 中数据的一致。对于同一数据实体在不同 UDDI 上的副本，只要其中一个 UDDI 的用户删除了该数据实体，那么我们将会删除所有副本。如果在同一段时间内多个用户对这一数据实体都进行了更新操作，那么我们会取最近更新的数据，去覆盖其他 UDDI 上原有的数据，这样保证所有的 UDDI 上都是最新的数据。
总结
用 IBM WSRR 作为中介，我们可以实现多个 UDDI 之间的数据同步，从而将用户割裂的信息系统整合起来。用户就可以用 IBM WSRR 为核心构建自己的 SOA 平台，SOA 所带来的灵活业务的能力将显著增加客户满意度。
参考资料
作者简介  | | | 赵一三（Sam）是来自 IBM 中国开发实验室 SOA 设计中心的软件开发工程师，目前从事 WebSphere Service Registry and Repository 产品的集成开发工作。为国内外多个重要客户提供过WSRR产品的技术支持服务，有过多个 SOA 项目的设计和实施经验。自从 2003 加入 IBM 以来，他曾经从事过 IBM Productivity Tool（Symphony 的前身）产品的开发和测试工作。您可以通过以下方式与他联系：zhaoyis@cn.ibm.com。 |
| | |
朱朴 IBM 中国软件开发实验室 SOA 设计中心软件开发工程师，主要从事 SOA 相关技术的研究和相关项目的实施。
|
对本文的评价
| 
