面向服务的架构以其服务复用、松耦合、灵活、高互操作性以及在集成和监管方面的特点促进了商业的敏捷性，及时响应以及可靠性。在这些方面中，SOA一个重要的特性就是将服务的实现和描述的分离，并且在服务的整个生命周期中使用服务描述的元数据。为了实现服务实现和描述的分离，用户需要一个注册服务器来存储服务元数据。

　　IBM? WebSphere? Service RegistryandRepository（文章随后的部分都简写为WSRR）是一个保存，查询和管理服务元数据的系统。在SOA体系架构中，这个系统在服务选择、调用、管理、监管以及服务复用方面起了关键作用。换句话说，它是一个你用来保存自己系统或者组织系统内的已经使用，计划使用的服务的场所。例如，一个应用系统可以在调用服务之前先检查WSRR来定位哪一个服务实例能够更好地满足用户在功能和性能方面的要求。WSRR在生命周期其它阶段也发挥了关键作用。

　　Universal Description, Discovery Integration ( 文章随后的部分都简写为UDDI) 提供了基本的发布和查询Web服务描述的能力。它不是一个存储服务数据实体的服务器，并且也没有提供管理端到端生命周期中的服务数据的监管能力。此外UDDI还有其它的局限性。例如，UDDI 在UDDI实体上面增加限制条件方面的能力很有局限性，这是因为UDDI里面使用的分类系统是纯技术性的，它很难表 Web服务的的语义信息，没有语义信息就不能充分发掘 Web 服务在动态调用，选择，绑定方面的潜力。此外在UDDI上做一个简单的操作都需要多次通讯交互，而在很多环境里面，这一点是很难接受的。

　　我们可以设想如下一个企业商业系统，该企业有大量的Web服务（WSDL）注册在UDDI服务器上，而WSDL文件的实体还保存在网络服务器上（web server）。该企业决定使用WSRR提供的在SOA架构方面的高级能力，WSRR 服务器被引入到该企业，被部署在企业IT系统中。用户可以配置 WSRR 里面的UDDI同步模块来同步WSRR和UDDI这两个系统里面的数据。见图 1

　　既然WSRR有存储WSDL文件的能力，企业很自然地就计划使用WSRR作为Web服务的唯一数据源，而不是使用原有的网络服务器，从而减少企业在系统维护方面的复杂度。因为企业在基于UDDI的既有系统上面有大量的投资，在这里非常重要的一点就是企业需要保留UDDI作为Web服务的接口。

　　WSRR里面的UDDI同步模块可以在同步UDDI数据的时候将WSDL文件从网络服务器保存到WSRR里面。这里就带来了一个问题，UDDI实体中（uddi:tModel）的overview URLs依然指向网络服务器上地址，而不是Web服务在WSRR上的地址。

　　本文介绍了如下一个转换工具，运行该工具可以自动检索UDDI，找到已经被同步到WSRR的Web服务，并且自动将UDDI实体中的overview URLs指向WSRR上的Web服务的地址。读者可以从本文下载章节下载参考代码。

图 1. 企业商业系统中的服务注册示例

　　Web服务注册地址转换工具

　　工具运行时需求

　　该工具的运行依赖Java运行时环境，可以将它拷贝到安装了WSRR的机器上运行，这样可以利用WebSphere Application Server(WAS)的JRE作为其Java运行时环境，同时该工具的运行还依赖以下jar包：

以下是引用片段： uddiv3client.jar  com.ibm.ws.admin.client_6.1.0.jar  com.ibm.ws.webservices.thinclient_6.1.0.jar  sdo-int.jar  ServiceRegistryClient.jar

　　其中sdo-int.jar，ServiceRegistryClient.jar 可以在WSRR安装的根目录下找到；com.ibm.ws.admin.client_6.1.0.jar和com.ibm.ws.webservices.thinclient_6.1.0.jar可以在WAS安装目录下的 runtimes 目录下找到，uddiv3client.jar可以在WAS安装目录下 UDDIRegclients 目录下找到。

　　该工具所能检索到的发布到UDDI服务器上的WSDL格式遵循TN202规范，有关该规范的详细描述参考如下链接：

以下是引用片段： http://www.oasis-open.org/committees/uddi-spec/doc/tn/uddi-spec-tc-tn-wsdl-v202-20040631.htm

　　该工具在WSRR6.3版本上测试运行通过，如果使用WSRR新的版本，则需要更新到相应版本的jar包，如果运行有问题可以与作者联系。

　　工具的设计

　　该工具包含三个主要功能模块：UDDI代理，WSRR代理和URL处理模块。UDDI代理主要负责和UDDI服务器建立连接，并完成对发布到 UDDI 服务器上的数据的增、删、改、查工作。WSRR代理主要负责和WSRR服务器建立连接并对其上的数据进行查询。URL处理模块主要完成URL的匹配，新URL的生成工作。具体的工作流程如图 2 所示：

　　首先检索UDDI服务器，找出所有满足TN202规范的portType tModel和binding tModel，这些tModel的定义里面包含了WSDL文档的 URL 信息。
 
　　对于第一步检索出来的每一个tModel，到WSRR上查询与之对应的逻辑对象，如果能够找到，则生成与之对应的WSDL文档的URL地址。该地址的组成包括两部分，一部分是WSRR的内容地址，类似于：http://localhost:9090/WSRR/6.1/Content/， 还有一部分是该WSDL文档的bsrURI，是该文档在WSRR中的唯一标志。
 
　　比较tModel中记录的URL地址信息和第二步中新生成的URL地址，如果他们不同，则将新生成的URL记录到tModel的定义中，替换原有的 URL 地址信息。

　　最后将修改过的tModel定义保存到UDDI服务器中。

图 2. 工具的实现机制

　　通过上面的介绍我们可以看到，该工具在运行时需要分别和WSRR，UDDI建立连接，连接所需的相关信息例如：服务器地址，安全相关的配置都保存在一个配置文件当中，用户在运行该工具之前，需要修改该配置文件来指定需要连接的WSRR和UDDI服务器。下面将具体介绍该配置文件的结构。

　　编辑修改工具的配置文件

　　和UDDI，WSRR相关的连接信息保存在一个名为Config.properties的配置文件中，该文件的具体格式如下所示：

以下是引用片段：  # UDDI Related Setting   UDDI.U1.INQUIRY_URL = https://localhost:9443/uddiv3soap/services/UDDI_Inquiry_Port   UDDI.U1.INQUIRY_SERVER_AUTH = BasicAuth   UDDI.U1.INQUIRY_UDDI_AUTH_TOKEN = required   UDDI.U1.PUBLISH_URL = https://localhost:9443/uddiv3soap/services/UDDI_Publish_Port   UDDI.U1.PUBLISH_SERVER_AUTH = BasicAuth   UDDI.U1.PUBLISH_UDDI_AUTH_TOKEN = required   UDDI.U1.SECURITY_URL = https://localhost:9443/uddiv3soap/services/UDDI_Security_Port   UDDI.U1.SECURITY_SERVER_AUTH = BasicAuth   UDDI.U1.USER_ID = Administrator   UDDI.U1.PASSWORD = password   UDDI.U1.TRUST_STORE = C:/trust.p12   UDDI.U1.TRUST_STORE_PASSWORD = WebAS   UDDI.U1.KEY_STORE = C:/key.p12   UDDI.U1.KEY_STORE_PASSWORD = WebAS   # WSRR Related Setting   serviceContentLocation = https://localhost:9443/WSRR/6.1/Content/   WSRRServiceEndpoint = https://localhost:9453/WSRRCoreSDO/services/WSRRCoreSDOPort   securityEnabled = true   username = Administrator   password = password   WSRR.KEY_STORE = C:/key.p12   WSRR.KEY_STORE_PASSWORD = WebAS   WSRR.TRUST_STORE = C:/trust.p12   WSRR.TRUST_STORE_PASSWORD = WebAS

 
　　该配置文件分为两部分，一部分负责UDDI连接，另一部分负责WSRR连接和UDDI连接相关的配置信息如下所示 :

　　表 1. UDDI连接相关的配置信息

　　INQUIRY_URL UDDI对外提供查询功能及相关API，访问该API的地址通过该属性设置。

　　INQUIRY_SERVER_AUTH设置访问UDDI查询API所需的服务器端认证级别，如果服务器端需要认证，设置该属性的值为“BasicAuth”。 该属性的取值范围如下：

以下是引用片段： None  BasicAuth

 
　　INQUIRY_UDDI_AUTH_TOKEN  设置应用级别的安全访问机制。如果访问UDDI的查询API需要提供从UDDI安全API获取的AuthToken，设置该属性的值为”Required”。该属性的取值范围如下：

以下是引用片段： None  Required

 
　　PUBLISH_URL UDDI对外提供发布功能及相关API，访问该API的地址通过该属性设置。

　　PUBLISH_SERVER_AUTH设置访问UDDI发布API所需的服务器端认证级别，如果服务器端需要认证，设置该属性的值为“BasicAuth”。 该属性的取值范围如下：

以下是引用片段： None  BasicAuth

 
　　PUBLISH_UDDI_AUTH_TOKEN设置应用级别的安全访问机制。如果访问UDDI的发布API需要提供从UDDI安全API获取的AuthToken，设置该属性的值为”Required”。该属性的取值范围如下：

以下是引用片段： None  Required

 
　　SECURITY_URL UDDI对外提供安全相关的功能及API，访问该API的地址通过该属性设置。

　　SECURITY_SERVER_AUTH设置访问UDDI安全API所需的服务器端认证级别，如果服务器端需要认证，设置该属性的值为”BasicAuth”。该属性的取值范围如下：

• None
• BasicAuth
• USER_ID UDDI 的用户名。
• PASSWORD 登陆 UDDI 服务器的密码。
• TRUST_STORE Trust store 文件的本地路径。
• TRUST_STORE_PASSWORD Trust store 文件的密码。
• KEY_STORE Key store 文件的本地路径。
• KEY_STORE_PASSWORD  Key store 文件的密码。

　　从上文中的配置文件示例中可以看到，与UDDI连接相关的配置项前面都有一个前缀，例如：UDDI.U1，称之为UDDI的别名，用于唯一标记一个UDDI服务器，该标记需要和执行WSRR，UDDI之间数据同步时使用的标记一致，用户可以使用不同的UDDI别名，在该配置文件中录入多个UDDI服务器的连接信息。从而可以在该工具的运行阶段，通过命令行的方式输入UDDI服务器的别名，来指定哪个UDDI服务器需要做相应的转变。

　　配置文件的另外一部分负责 WSRR 的连接，具体配置项如下所示：

　　表 2. WSRR 连接相关的配置项

　　serviceContentLocation WSRR中存储的物理文档可以通过URL访问，该URL的组成分为两部分，一部分是根地址，一部分是对象在WSRR中的唯一标志。该配置项用于指定内容的根地址。

　　WSRRServiceEndpoint用户可以通过Web服务的方式访问WSRR的功能。该配置项用于制定WSRR的Web服务地址。

• 　　securityEnabled 用于指定WSRR服务器安全是否启用。
• 　　WSRR.KEY_STORE Key store文件的本地路径。
• 　　WSRR.KEY_STORE_PASSWORD Key store文件的密码。
• 　　WSRR.TRUST_STORE Trust store文件的本地路径。
• 　　WSRR.TRUST_STORE_PASSWORD Trust store文件的密码。
• 　　username WSRR服务器的用户名。
• 　　password WSRR服务器的密码。

　　以上是对配置文件的详细描述，用户可以根据本地WSRR，UDDI服务器的设置自行修改该配置文件。

　　工具的运行

　　该工具的运行采用命令行方式，示例如下：

以下是引用片段：  java  -classpath  C:UDDITestuddiv3client.jar;  C:UDDITestcom.ibm.ws.admin.client_6.1.0.jar;  C:UDDITestcom.ibm.ws.webservices.thinclient_6.1.0.jar;  C:UDDITestsdo-int.jar;  C:UDDITestServiceRegistryClient.jar;URLConversionTool.jar;    ChangeUDDIURL UDDI.U1

 
　　用户需要指定工具运行所依赖的jar包。 用户可以一次输入多个UDDI的别名来实现对多个UDDI的转换工作。

　　该工具具体的运行效果如下所示，图 3 是工具运行之前UDDI中Web服务的情况，这些Web服务的地址都没有指向WSRR服务器，而是指向了一个存放物理文档的网络服务器。

图 3. 工具运行之前UDDI中的Web服务

　　在工具的运行过程当中，如果UDDI中发布的Web服务的地址发生了改变，在命令行窗口中会显示对应的tModel的key，旧的地址及改变之后的新地址。如图 4 所示：

图 4. 工具运行时的命令行窗口

    从图 5 可以看到，该工具运行之后，UDDI中Web服务的地址指向了WSRR服务器。

图 5. 工具运行之后UDDI中的Web服务

　　结束语

　　本文介绍了一个转换工具，用户可以利用该工具将WSRR作为Web服务的唯一数据源。不但避免了维护多份Web服务拷贝所带来的不便和风险，还可以维持现有的基于UDDI的应用不变。