SOA之路2
2008-01-01 17:50
267 查看
第四章 UDDI发现Web服务
1. UDDI介绍
[align=left]UDDI(统一描述、发现和集成) 是未来电子商务的基石,它使得商业实体能够使用他们首选的应用软件,快速、方便、迅捷地发现现存的或潜在的商业伙伴,并与之进行交易。所有的这一切全部由自动化的应用程序来完成,因此应用程序如何与UDDI注册中心进行交互就显得异常重要。[/align][align=left]如图4.1所示,这是一个UDDI应用框架图,中间大圆圈表示internet网络,从上到下分为三个层次:服务提供者、UDDI和服务请求者。右边表示各个层次需要用到的工具。当然你也可以不使用这些工具,这只是作者在实际运用中的工具而已。[/align]
[align=center]图4.1 UDDI应用框架[/align]
[align=left] 我们根据图4.1来看看UDDI具体是怎么工作的,首先服务提供者通过wsdl、axis来制作自己的服务,这一步在第三章已经详细说明,接下来是发布服务,即UDDI,这一部分在接下来会详细讨论,最后是请求者通过UDDI来检索所需服务,前面提到,请求通过soap协议调用服务的形式是多种多样的,你可以用你熟悉的任何语言来检索调用,文章主要列举了IBM提供的uddi4j调用方式。[/align]
2. UDDI的核心
如图4.2所示,UDDI的核心包括Business、Service、Binding、TModel四个大的部分,各个部分如图表现为包含关系实际却相互独立,如何理解这句话呢,例如一个Business可以包括多个Service,但一个Service并不一定属于这个Business,它可以属于另外一个Business,其它两两关系类似,尤其越往后这种关系越明显,但必须尊从几个原则:各层次关系不能越界,例如Business不能越过Service直接包含Binding;[align=center][/align]
[align=center]图4.2 UDDI结构图[/align]
其中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的用途及结构详解
http://www-128.ibm.com/developerworks/cn/webservices/ws-tmodel/part1/index.html#resources
[align=center][/align]
[align=center]图4.3 WSDL到UDDI的映射[/align]
[align=left]再回到图4.2,最顶层的tModel包括name、description、oviewURL、identifierBag,catagoryBag等元素,实际上我之所以把这几个要素放到第一层,一是为了好看,二是因为每一层次都具有这几种元素。[/align]
[align=left]Name——必要元素,名称。
description——文字描述。[/align]
[align=left]overviewDOC——可选项,结构文档地址,UDDI建议这个文档应为HTML,以便用户使用浏览器,通过HTTP GET操作读取该文档。[/align]
[align=left]identifierBag——可选项,标识号组。通过这个元素,我们可以使用预定义的名字空间标志来确定某个结构。该名字空间可由企业集团定义,或有UDDI(DUNS)提供。这个元素包含一组keyReference(关键字引用)元素,每个keyReference元素都是一个关键字/取值对。[/align]
[align=left]catagoryBag——可选项,类别组。通过这个元素,我们可以把结构按照各种不同的分类法进行分类。分类法由企业集团或UDDI提供。[/align]
[align=left] [/align]
[align=left]因为分类法可由企业集团或UDDI提供,那么必然存在建类与分类的方案,建类这里就不讨论了,UDDI第1版的狠心规范含有三个预定义的分类方案:北美企业分类方案(North Americacan Industry Classfication System,NAICS),它按照行业进行分类(http://www.ntis.gov/product/naics.htm);用于产品和服务分类体系(Universal Standard Products and Services Classification UNSPSC);ISO3166标准,它按照地理位置进行分类(http://www.din.de/gremien/nas/nabd/iso3166ma)。[/align]
[align=left]这只是一个大体的介绍,实际上还忽视了一些细节,例如从bindingTemplate到tModel之间的关联是通过tModelInstanceDetail来完成的,从某种意义上说,bindingTemplate结构就是UDDI的最终目的。其他结构为我们提供了商务信息(也就是说businessEntity和businessService是属于商业上的),如商务描述、联络信息、分类信息以及服务器类型。在决定了要使用某个提供者的某项服务之后,我们就要从bindingTemplate子树中获取服务调用的必要技术信息。同一个逻辑服务可以有一个或多个束定,每个束定都有自己的bindingTemplate结构进行描述。如图7-19所示,bindingTemplate通常是访问入口点信息,tModel引用及其特定参数的组合。[/align]
[align=left]tModelInstanceDetail是tModelInstanceInfo结构的容器,而tModelInstanceInfo又是instanceDetails的容器。它定义了服务调用这的最终细节,如前面所述,每项已注册的服务(businessService)都可以有一个或多个束定(bindingTemplate),而每个束定(bindingTemplate)可以引用一个或多个tModel。例如,我们决定为某个服务提供两种束定:一个基于SOAP/HTTP,另一个基于Email/SMTP。在这种情况下,两种束定都至少需要两个tModelInstanceInfo结构,这将带来一些好处:服务可重用已有的抽象规范,其他商务机构可根据它的技术模型来定位这一信息。[/align]
[align=left]总结,UDDI总的结构大致如下:businessEntity->businessService->bindingTemplate->tModelInstanceDetails->tModeInstancelnfo->instanceDetails->tModel[/align]
3. UDDI实现
3.1 实现流程
[align=center]表4.4 UDDI规范定义的CRUD API消息。[/align]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 |
3.2 UDDI的安装和使用
安装和使用JUDDI和UDDI4j不是一件很困难的事情,详情参考我的文章http://ziapple.blog.51cto.com/271886/54230
第二章 SOA来了
1 智能交通服务集成的概念
废话就不说了,而且涉及到商业的东西,只是一个概念而已。2 建模实现
[/b]第三章 未来方向
1. Ontolgy[align=center] v[/align]
相关文章推荐
- 通向SOA和业务灵活性之路
- SOA 之路 -- Spring Cloud配置文件的统一管理
- SOA 之路 -- Spring Cloud配置文件的统一管理
- SOA 之路 -- 组件化开发:最大化利用现有代码
- SOA 之路 -- 组件化开发:最大化利用现有代码
- SOA之路 -- 区别对待服务
- SOA 之路系列:Net与SOA
- SOA 之路 -- Spring Cloud配置文件的统一管理
- SOA 之路 -- 组件化开发:最大化利用现有代码
- SOA之路 -- 区别对待服务
- SOA 之路 -- Spring Cloud配置文件的统一管理
- SOA 之路 -- 组件化开发:最大化利用现有代码
- SOA之路 -- 区别对待服务
- 企业级SOA之路——在Web Service中使用HTTP和JMS
- Martin Fowler:SOA的敏捷之路
- SOA 之路 -- Spring Cloud配置文件的统一管理
- SOA 之路 -- 组件化开发:最大化利用现有代码
- SOA之路 -- 区别对待服务
- SOA解决方案设计师成长之路
- 企业级SOA之路——在Web Service中使用HTTP和JMS