SOA之路2

第四章   UDDI发现Web服务

1.     UDDI介绍

UDDI( 统一描述、发现和集成 ) 是未来电子商务的基石，它使得商业实体能够使用他们首选的应用软件，快速、方便、迅捷地发现现存的或潜在的商业伙伴，并与之进行交易。所有的这一切全部由自动化的应用程序来完成，因此应用程序如何与 UDDI 注册中心进行交互就显得异常重要。

如图 4.1 所示，这是一个 UDDI 应用框架图，中间大圆圈表示 internet 网络，从上到下分为三个层次：服务提供者、 UDDI 和服务请求者。右边表示各个层次需要用到的工具。当然你也可以不使用这些工具，这只是作者在实际运用中的工具而已。

图 4.1 UDDI 应用框架

     我们根据图 4.1 来看看 UDDI 具体是怎么工作的，首先服务提供者通过 wsdl 、 axis 来制作自己的服务，这一步在第三章已经详细说明，接下来是发布服务，即 UDDI ，这一部分在接下来会详细讨论，最后是请求者通过 UDDI 来检索所需服务，前面提到，请求通过 soap 协议调用服务的形式是多种多样的，你可以用你熟悉的任何语言来检索调用，文章主要列举了 IBM 提供的 uddi4j 调用方式。

2.     UDDI的核心

如图 4.2 所示， UDDI 的核心包括 Business 、 Service 、 Binding 、 TModel 四个大的部分，各个部分如图表现为包含关系实际却相互独立，如何理解这句话呢，例如一个 Business 可以包括多个 Service ，但一个 Service 并不一定属于这个 Business, 它可以属于另外一个 Business ，其它两两关系类似，尤其越往后这种关系越明显，但必须尊从几个原则：各层次关系不能越界，例如 Business 不能越过 Service 直接包含 Binding;

图 4.2  UDDI 结构图

其中 Business 是指商务实体，通常认为是某个企业 ;Service 是指服务，这里服务是个抽象的概念，不同于之前所说的一个简单的 HelloWordService 方法，在此指企业所提供的服务，跟 WSDL 定义的服务是一致的 ;Binding 即一个服务束定或绑定，它描述了一个服务的详细实施细节，例如这个服务的传入传出参数，类型，具体服务 URL （ AccessPoint ）。 tModel 是个很难理解的概念，我们根据图 4.3 从 WSDL 到 UDDI 的映射来理解 tModel 的概念，从 WSDL 的设计原则看，一个服务描述包括服务接口和实施，服务接口对应的是 UDDI 的 tModel ，服务实施对应 UDDI 的 BusinessService ，也就是说 tModel 是一个接口的定义，它是 UDDI 的核心，是一个服务的抽象定义，你可以称它为技术模型，或技术规范。我对核心的理解就是 UDDI 通过创建 tModel 这一概念来为每一个服务定义一个规范，这些服务可以是 UDDI API ，也可以是商家自己定义的 tModel ，例如服务的传递方式（ HTTP/SMTP ）和分类。如果你还是不理解的话，可以暂时先放一边，继续往下。

附：大师对 tModel 的理解

tModel 的用途及结构详解

[url]http://www-128.ibm.com/developerworks/cn/webservices/ws-tmodel/part1/index.html#resources[/url]

图 4.3   WSDL 到 UDDI 的映射

再回到图 4.2 ，最顶层的 tModel 包括 name 、 description 、 oviewURL 、 identifierBag ， catagoryBag 等元素，实际上我之所以把这几个要素放到第一层，一是为了好看，二是因为每一层次都具有这几种元素。

Name ――必要元素，名称。
description ――文字描述。

overviewDOC ――可选项，结构文档地址， UDDI 建议这个文档应为 HTML ，以便用户使用浏览器，通过 HTTP  GET 操作读取该文档。

identifierBag ――可选项，标识号组。通过这个元素，我们可以使用预定义的名字空间标志来确定某个结构。该名字空间可由企业集团定义，或有 UDDI （ DUNS ）提供。这个元素包含一组 keyReference （关键字引用）元素，每个 keyReference 元素都是一个关键字 / 取值对。

catagoryBag ――可选项，类别组。通过这个元素，我们可以把结构按照各种不同的分类法进行分类。分类法由企业集团或 UDDI 提供。

 

因为分类法可由企业集团或 UDDI 提供，那么必然存在建类与分类的方案，建类这里就不讨论了， UDDI 第 1 版的狠心规范含有三个预定义的分类方案：北美企业分类方案（ North Americacan Industry Classfication System ， NAICS ），它按照行业进行分类（ [url]http://www.ntis.gov/product/naics.htm[/url] ）；用于产品和服务分类体系（ Universal Standard Products and Services Classification UNSPSC ）； ISO3166 标准，它按照地理位置进行分类（ [url]http://www.din.de/gremien/nas/nabd/iso3166ma[/url] ）。

这只是一个大体的介绍，实际上还忽视了一些细节，例如从 bindingTemplate 到 tModel 之间的关联是通过 tModelInstanceDetail 来完成的，从某种意义上说， bindingTemplate 结构就是 UDDI 的最终目的。其他结构为我们提供了商务信息（也就是说 businessEntity 和 businessService 是属于商业上的），如商务描述、联络信息、分类信息以及服务器类型。在决定了要使用某个提供者的某项服务之后，我们就要从 bindingTemplate 子树中获取服务调用的必要技术信息。同一个逻辑服务可以有一个或多个束定，每个束定都有自己的 bindingTemplate 结构进行描述。如图 7-19 所示， bindingTemplate 通常是访问入口点信息， tModel 引用及其特定参数的组合。

tModelInstanceDetail 是 tModelInstanceInfo 结构的容器，而 tModelInstanceInfo 又是 instanceDetails 的容器。它定义了服务调用这的最终细节，如前面所述，每项已注册的服务 (businessService) 都可以有一个或多个束定 (bindingTemplate) ，而每个束定 (bindingTemplate) 可以引用一个或多个 tModel 。例如，我们决定为某个服务提供两种束定 : 一个基于 SOAP/HTTP ，另一个基于 Email/SMTP 。在这种情况下，两种束定都至少需要两个 tModelInstanceInfo 结构，这将带来一些好处：服务可重用已有的抽象规范，其他商务机构可根据它的技术模型来定位这一信息。

总结， UDDI 总的结构大致如下： businessEntity->businessService->bindingTemplate->tModelInstanceDetails->tModeInstancelnfo->instanceDetails->tModel

3.     UDDI实现

3.1  实现流程

表 4.4  UDDI 规范定义的 CRUD API 消息。

	Business	Service	Binding	tModel
Save/Update	Save_business	Save_service	Save_binding	Save_tModel
Delete	Delete_business	Delete_service	Delete_binding	Delete_tModel
Find	Find_business	Find_service	Find_binding	Find_tModel
GetDetail	Get_businessDetail	Get_serviceDetail	Get_bindingDetail	Get_tModelDetail

 

上面列出了 UDDI API4 种结构的 4 个操作方法，通过调用这些方法你就可以实现发布、更新操作了。 UDDI 的实现流程大概是这样的，首先在 UDDI 服务器上注册，这时 UDDI 会返回给你一个 UUID 的 Authonkey ， UUID 是指全球标唯一识号， UDDI 所有返回的 key 都是 UUID ，所以文章涉及到的 key 不特别申明。通过这个 Authonkey 你就可以做任何你想做的了，包括发布、检索各种服务。按照前面所讲的首先我们应该注册一个 BusinessEntity ，其中 name 、 discriptiong 、 overviewDoc 、 identifierBag 、 catagoryBag 等属性都是自己输入的 , 注册完后 UDDI 同样会返回一个 BusinessKey 给你，有了 businesskey 我们就可以注册 businessService 了，依次类推。

3.2           UDDI的安装和使用

安装和使用 JUDDI 和 UDDI4j 不是一件很困难的事情，详情参考我的文章

[url]http://ziapple.blog.51cto.com/271886/54230[/url]

第二章    SOA来了

1           智能交通服务集成的概念

废话就不说了，而且涉及到商业的东西，只是一个概念而已。

2           建模实现

第三章    未来方向

1.       Ontolgy

 v