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