在过去的数年中许多开发人员都使用了各种版本的JEE使服务器端软件编程的情形得到了很大的改观现在他们将再次挑战SOAP在服务器端软件编程方面取得更大的进展 SOAP服务的支持者认为 ·企业级应用服务器是服务(或事务)的集合 ·可以使用的服务应当很方便地列出来供用户浏览搜索和访问 ·象现在的基于组件的开发模式那样将应用服务器设计为服务的集合将鼓励开发人员采用更好的设计模式 ·这些事务能够被重新定位负载平衡替代等 而对SOAP持怀疑态度的人认为SOAP是推广CORBA和COM的又一次尝试他们指出要简单地访问一个对象需要完成太多的准备性工作而且UDDI带来的好处也被夸大了 那么到底哪一种观点更合理呢?对于一些思想开放的人士而言在决定是否采用SOAP服务前他们一定希望了解其中的一些核心技术 解密UDDI 我们首先来看看UDDI代表什么?UDDI是Universal Description Discovery and Integration(统一描述发现和集成)的缩写UDDI的意图是作为一个注册簿就象黄页是一个地区企业的注册簿一样象在黄页中那样在UDDI注册簿中企业将在不同的目录下注册它们自己或其服务通过浏览一个UDDI注册簿开发人员能够查找一种服务或一个公司并发现如何调用该服务 除了黄页外UDDI还使用了白页和绿页白页是企业实体列表绿页是调用一项服务所必需的文档 UDDI的定义非常全面足以适应不同种类的服务一个UDDI服务定义可能代表一个传真服务或电话服务作为一种注册簿UDDI一般使用数据库一类的软件来实现在该数据库中存在一个允许发布或查询服务的有关信息 UDDI数据模型 UDDI数据模型包括下面的主要元素 ·businessEntity表示一个实际的企业 ·businessService表示一个企业提供的服务 ·bindingTemplate如何调用服务的说明 ·tModel>: Good luck understanding this! (Just kidding I will explain this later) 为了加深对UDDI数据模型的理解我们来看看这些数据元素的UML表示法图是这四种主要元素之间的关系图 educitycn/img_///gif > 从上面的图中我们可以知道一个businessEntity(一家公司)有一个能够告诉我们更多有关公司信息的描述性URL和联系人清单此外businessEntity还有一个商业服务清单每种服务可能有多种调用方法每种调用都由一个绑定模板描述绑定模板详细地描述了如何访问一个服务它受益于一系列描述用户如何访问这一服务的文档绑定模板和其必要的文档之间的联系是通过所谓的tModel完成的在上面的图中这种联系被简单地描述为一个绑定模板有许多tModels在进一步地解释tModels与绑定模板的关系前我们必须先弄清楚tModels是什么 TModel是什么? 我们可以把tModel想象成数据库库中的一个独立的表其中包含下面的字段名字描述URL唯一的关健字实际上tModel就是包括有名字和描述那么使用数据库表表示它是否是一种浪费呢?我们下面就会讨论这一问题 下面是一个假想的tModel数据库表中的二个实体 键 名字 描述 URL Javaclass 表示一个具备完全资格的java类的名字 Jndihome 表示一个JNDI名字 在将tModel比作数据库表方面有几点值得注意首先tModel是一个独立的表意味着它可以不依赖其他软件而存在其次tModel是查找表提供了键与键的表示之间的转换关系从这一点来看tModel象词典那样是一个引用表在一些数据库中这样的表也被称作是码集 因此如果在上面的tModel中存在下面的记录 commycompanyHelloWorld commycompanyHelloWorldHome 就意味着字符串commycompanyHelloWorld是一个有完整资格的Java类而字符串commycompanyHelloWorldHome是一个JNDI名 因此在一定程度上tModels中唯一的键与名字空间这个概念差不多为了进一步地说明这个问题我们来看一下下面的数字 x 你能够分清这些数字的意义吗?我们需要在一个环境或名字空间中来确认是电话号码是传真号x是一个ISBN号 因此在tModel数据库表中我们将需要定义三个实体一个是电话号码一个是传真号码一个是ISBN号码 下面我们以mycompany公司公布了一条号码为myhelpline的电话支持热线并在UDDI中注册那么我们的数据模型为 company name: mycompany Service name: helpline tModel: key= (representing telephoneline) name=telephone description=telephone stuff url: some at&t url binding: accesspoint: myhelpline tModelInstanceInfo: 有了对tModel的基本理解后我们就可以利用UML图表来研究绑定模板与tModels之间的关系了我在上面曾经说过这将使我们对绑定模板如何完成UDDI的如何调用一项服务的要求有一个直观的理解 educitycn/img_///gif > 在图中我们讨论了一个绑定模板与tModels之间的关系从图表中我们可以看出一个绑定模板可以指向一个由一个tModel确定的技术规格技术规格有二部分组成 ·规格的类型(例如电子邮件传真WSDLSOAP等) ·确定输入和输出的文档(在SOAP服务中这些文档可以是XML输入/输出消息格式) 既然我们已经对tModels有了一定程度的详细了解就该再讨论UDDI中更复杂的东西了也就是身份包和类别包 理解标识符包和类别包 如果说从概念上理解tModels是理解UDDI需要跨越的第一道障碍那么理解标识符包和类别包则是需要跨越的第二道障碍下面的例子可以帮助我们理解这二个概念 例如您的公司在美国开展业务需要有一个税号如果还在另外的国家(例如墨西哥)开展业务就需要有一个墨西哥的税号为了能够在UDDI注册簿中获取您的公司的这些信息在UDDI中应当包括下面的内容 公司名字mycompany 标识符 美国税号 墨西哥税号 其他国家税号 其他的xml内容 UStaxcode keyName=taxnumber keyValue=> Mexicotaxcode keyName=taxnumber keyValue=> otherstuff keyName=taxnumber keyValue=> 其他的xml内容 现在明白tModels如何被用作名字空间了吧为了进一步地深化对标识符包的理解我们在下面的图中再次解释了标识符和类别包的概念 educitycn/img_///gif > 从上面的图中我们能够看出标识符包是一个在特定环境中的键/值对集合这个环境从本质上说就是能够唯一地解析名字/值对儿的名字空间它是由tModel确定的类别包也是如此二者之间唯一的区别就是类别包中由tModel确定的名字空间是一个预先确定好的类别 类别包 我想将公司归类于饭店其地理位置位于杰克逊维尔 公司名字mycompany 适用类 企业类型饭店 所在城市杰克逊维尔 BusinessTypeClassification keyName=restaurant keyValue=> CityClassification keyName=JAX keyValue=> 现在我们已经搞清楚了tModels是如何用在标识符和类别包中的从本质上说tModels就是名字空间 tModels也能被分类吗? 我们已经明白了企业实体是如何利用使用了类别包的另外UDDI也允许tModels本身被分类 我们用分层次的文件系统进行说明目录是用来对文件进行分类的但目录还可以在父目录下再被分类象硬盘上的目录那样tModels也可以被分层次地进行组织 下面我们来讨论名字为getUniversalTime()的服务该服务将返回当前全球任一地方的时间二家存在竞争关系的公司可能会提供这一服务的不同实现商业服务只限于在公司内部使用公司之外的用户是不可使用的 company:getTime() company:getCurrentTime() 这二者的作用相同为了表明它们实现的是同一个被称作getUniversalTime()的服务我们可以定义如下所示的tModel tModel name: Get Universal Time category: uddiorg:types wsdl [意味着这是一个由WSDL文档定义的服务] 上面的定义表明getUniversalTime()是一个WSDL服务可以由任何公司实现 既然已经阐明了tModels和包之间的关系我们下面可以看看一个tModel的UML表示 educitycn/img_///gif > 从上面的图表中我们可以看出tModel基本上就是一个名字和描述另外它也可以包含一个URL以提供更进一步的详细资料它可以由一个标识符包确定和由一个类别包进行分类 我们已经知道一个t |