导读：
在过去的数年中，许多开发人员都使用了各种版本的J2EE，使服务器端软件编程的情形得到了很大的改观，现在，他们将再次挑战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表示法。图1是这四种主要元素之间的关系图：
从上面的图中我们可以知道，一个businessEntity（一家公司）有一个能够告诉我们更多有关公司信息的描述性URL和联系人清单，此外，businessEntity还有一个商业服务清单。每种服务可能有多种调用方法，每种调用都由一个绑定模板描述。绑定模板详细地描述了如何访问一个服务，它受益于一系列描述用户如何访问这一服务的文档。绑定模板和其必要的文档之间的联系是通过所谓的tModel完成的。在上面的图中，这种联系被简单地描述为一个绑定模板有许多tModels。在进一步地解释tModels与绑定模板的关系前，我们必须先弄清楚tModels是什么。
TModel是什么？
我们可以把tModel想象成数据库库中的一个独立的表，其中包含下面的字段：名字、描述、URL、唯一的关健字。实际上，tModel就是包括有名字和描述，那么使用数据库表表示它是否是一种浪费呢？我们下面就会讨论这一问题：
下面是一个假想的tModel数据库表中的二个实体：
键 名字 描述 URL
1 Java-class 表示一个具备完全资格的java类的名字 http://www.javasoft.com/
2 Jndi-home 表示一个JNDI名字 http://www.javasoft.com/
在将tModel比作数据库表方面，有几点值得注意。首先，tModel是一个独立的表，意味着它可以不依赖其他软件而存在；其次，tModel是查找表，提供了键与键的表示之间的转换关系。从这一点来看，tModel象词典那样，是一个引用表。在一些数据库中，这样的表也被称作是码集。
因此，如果在上面的tModel中存在下面的记录：
com.mycompany.HelloWorld, 1
com.mycompany.HelloWorldHome, 2
就意味着字符串com.mycompany.HelloWorld是一个有完整资格的Java类；而字符串com.mycompany.HelloWorldHome是一个JNDI名。
因此在一定程度上，tModels中唯一的键与“名字空间”这个概念差不多。为了进一步地说明这个问题，我们来看一下下面的数字：
904-555-1212
904-555-1213
1-56592-391-x
你能够分清这些数字的意义吗？我们需要在一个环境或名字空间中来确认，904-555-1212是电话号码，904-555-1213是传真号，1-56592-391-x是一个ISBN号。
因此在tModel数据库表中，我们将需要定义三个实体：一个是电话号码；一个是传真号码，一个是ISBN号码。
下面我们以mycompany公司公布了一条号码为1-800-my-helpline的电话支持热线，并在UDDI中注册。那么，我们的数据模型为：
company name: mycompany
Service name: helpline
tModel: key=11 (representing telephoneline), name=telephone,
description=telephone stuff, url:
some at&t url
binding:
accesspoint: 1-800-my-helpline
tModelInstanceInfo: 11
有了对tModel的基本理解后，我们就可以利用UML图表来研究绑定模板与tModels之间的关系了。我在上面曾经说过，这将使我们对绑定模板如何完成UDDI的“如何调用一项服务”的要求有一个直观的理解。
在图2中，我们讨论了一个绑定模板与tModels之间的关系。从图表中我们可以看出，一个绑定模板可以指向一个由一个tModel确定的技术规格，技术规格有二部分组成：
·规格的类型。（例如电子邮件、传真、WSDL、SOAP等。）
·确定输入和输出的文档（在SOAP服务中，这些文档可以是XML输入/输出消息格式。）
既然我们已经对tModels有了一定程度的详细了解，就该再讨论UDDI中更复杂的东西了，也就是身份包和类别包。
理解标识符包和类别包
如果说从概念上理解tModels是理解UDDI需要跨越的第一道障碍，那么理解标识符包和类别包则是需要跨越的第二道障碍。下面的例子可以帮助我们理解这二个概念。
例如，您的公司在美国开展业务需要有一个税号，如果还在另外的国家（例如墨西哥）开展业务，就需要有一个墨西哥的税号。为了能够在UDDI注册簿中获取您的公司的这些信息，在UDDI中应当包括下面的内容：
公司名字：mycompany
标识符：
美国税号：111111
墨西哥税号：2223344
其他国家税号： 333333
...其他的xml内容
keyName="taxnumber" keyValue="1111111"> keyName="taxnumber" keyValue="1111111">
keyName="taxnumber" keyValue="2223344"> keyName="taxnumber" keyValue="2223344">
keyName="taxnumber" keyValue="333333"> keyName="taxnumber" keyValue="333333">
... 其他的xml内容
现在明白tModels如何被用作名字空间了吧。为了进一步地深化对标识符包的理解，我们在下面的图中再次解释了标识符和类别包的概念：
从上面的图中我们能够看出，标识符包是一个在特定环境中的键/值对集合，这个环境从本质上说就是能够唯一地解析名字/值对儿的名字空间，它是由tModel确定的。类别包也是如此，二者之间唯一的区别就是类别包中由tModel确定的名字空间是一个预先确定好的类别。
类别包
我想将公司归类于饭店，其地理位置位于杰克逊维尔。
公司名字：mycompany
适用类：
企业类型：饭店
所在城市：杰克逊维尔
keyName="restaurant" keyValue=".."> keyName="restaurant" keyValue="..">
keyName="JAX" keyValue=".."> keyName="JAX" keyValue="..">
现在，我们已经搞清楚了tModels是如何用在标识符和类别包中的。从本质上说，tModels就是名字空间。
tModels也能被分类吗？
我们已经明白了企业实体是如何利用使用了类别包的。另外，UDDI也允许tModels本身被分类。
我们用分层次的文件系统进行说明。目录是用来对文件进行分类的，但目录还可以在父目录下再被分类。象硬盘上的目录那样，tModels也可以被分层次地进行组织。
下面我们来讨论名字为getUniversalTime()的服务，该服务将返回当前全球任一地方的时间。二家存在竞争关系的公司可能会提供这一服务的不同实现。商业服务只限于在公司内部使用，公司之外的用户是不可使用的：
company1:getTime()
company1:getCurrentTime()
这二者的作用相同，为了表明它们实现的是同一个被称作getUniversalTime()的服务，我们可以定义如下所示的tModel：
tModel
name：: Get Universal Time
category: uddi-org:types, wsdl
[意味着这是一个由WSDL文档定义的服务]
上面的定义表明getUniversalTime()是一个WSDL服务，可以由任何公司实现。
既然已经阐明了tModels和包之间的关系，我们下面可以看看一个tModel的UML表示：
从上面的图表中，我们可以看出tModel基本上就是一个名字和描述，另外，它也可以包含一个URL，以提供更进一步的详细资料。它可以由一个标识符包确定和由一个类别包进行分类。
我们已经知道，一个tModel所属于的类别是由UDDI━━WSDL、SOAP等预先定义好的，下面是一个uddi-org:types名字空间中预先定义类别的清单：
tModel
identifier （唯一标识符）
namespace
categorization
specification
xmlSpec
soapSpec
wsdlSpec
protocol
transport
signatureComponent
如何开始在UDDI中创建一个服务？
在开始定义服务的tModel时，要求我们为服务指定一个名字和上面所列出的服务类型中的一个。当然了，如果不喜欢上面的分类可以自己创建类别。
我们可以针对上面定义的tModel开发一个商业服务。在商业服务定义中，我们需要指定一个指向定义了服务的输入/输出的WSDL文档的URL。
在UDDI中为什么需要tModels？
在UDDI中使用tModels的目的如下：
·对商业实体进行标识和分类
·对商业服务进行标识和分类
·对tModels进行标识和分类
·将商业服务绑定到它们抽象的tModel定义上
UDDI名词的快速参考
在看有关UDDI的资料时，如果看到很深奥的术语是一件很烦人的事儿，下面我们就把一些经常用到的与UDDI有关的概念搜集起来，通过比较帮助我们对UDDI概念的理解：
接口和实现
服务绑定是一个容器，接口依赖于其实现；绑定元素详细说明了tModelInstaceInfo和instanceDetail， 我们将再通过一个例子加深对这一问题的例子。对于“获得统一时间”服务而言，细节将提供定义了输入、输出的实际的WSDL文档，绑定的访问点将提供实现服务的物理机器和端口。了解了这些，我们可以得出如下的结论：
·为一种服务定义的tModel是允许多家公司提供该服务的多个实现的界面。
·服务绑定是具体的实现。
名字空间
Java、C++和XML中都有名字空间的概念，尽管其叫法可能不同，但它们都提供了使名字有意义的环境。在UDDI中，tModel象征着“名字”。当把这个名字作为目录使用时，你的本意是，“我属于这个名字”。从这个意义上说，tModel表示的是名字空间。
技术指纹
当一种服务被注册为tModel时，我们可以注册用来与该服务通讯的协议（例如WSDL、SOAP等）。因此根据所使用的协议不同，tModel有WSDL指纹或SOAP指纹。因此tModel被认为是技术性指纹，每种指纹与一种特定的协议有关。如果说一种tModel可以代表一个“技术性指纹”，我们也可以说tModel能够表示一种“协议”。
分类
分类与类别、名字空间类似，它提供了一种环境，只有在这种环境下，一些数字和名字才有意义。例如，
白页
UDDI注册簿中的企业实体列表和根据名字搜索企业的能力。
黄页
黄页将企业实体按企业类别或其他适用的类别分类。
绿页（技术规格）
绿页有助于我们理解服务的定义和访问服务的要求，serviceBindings和tModels也有助于这一目标的实现。
JAXR
JAXR是在服务注册中使用的一种Java XML API。我们以前曾经讨论过，UDDI中的所有元素都用XML文档进行描述。从某种意义上说，嘦我们能够发送包含有服务描述的XML消息，UDDI注册簿就能够对它进行注册或更新。下面我们讨论在没有工具的情况下如何完成这一任务：
1、编写必要的服务描述XML文档。
2、理解SOAP头部，以便能够将XML文件作为一个SOAP附件发送给UDDI注册簿。
3、使用SOAP客户端Java API完成第二步中的任务。
4、通过编程的方式处理SOAP消息。
5、根据UDDI服务的描述，构造消息完成该UDDI服务的任务。
6、对每个消息，完成第2、3步中的操作。
如果使用JAXR，我们可以更好地完成这一任务。因为JAXR允许我们在发送XML消息时无需考虑SOAP头部，而且是一种严格的面向消息的协议。使用JAXR，上面的任务将简化为：
1、编写必要的服务描述XML文档。
2、使用JAXM API发送和接收XML消息，JAXR隐藏了SOAP信息。
3、根据UDDI服务构建消息完成该UDDI服务。（例如，向UDDI注册簿注册UDDI服务包含有4次信息交换过程。）这意味着我们仍然需要与XML内容打交道。
使用这种方式，我们只需处理高层次的Java API即可，这些Java API能够产生必需的消息并通过JAXR传输它们。需要指出的一点是，JAXR也用来完成该任务。
下面列出了JAXR的一些目标：
·支持业界标准的XML注册功能
·支持成员机构和企业的注册
·支持任意注册内容的存储和提交
·支持XML、非XML注册内容的管理
·支持注册内容间用户定义的结合
·支持用户定义的注册内容的多级分类
·支持基于定义的分类计划的注册内容查询
·支持基于复杂查询的注册内容查询
·支持基于关健词的注册内容查询
·支持Web服务的共享
·支持合作伙伴间商业过程的共享
·支持合作伙伴间计划的共享
·支持合作伙伴间商业文档的共享
·支持合作伙伴间贸易伙伴协议的谈判
·支持计划汇编
·支持异类分布注册
·支持参与各方发布/订阅XML消息
JAXR将不仅仅支持UDDI，还会支持其他的类似注册服务标准（例如ebXML）。
在过去的数年中，许多开发人员都使用了各种版本的J2EE，使服务器端软件编程的情形得到了很大的改观，现在，他们将再次挑战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表示法。图1是这四种主要元素之间的关系图：
从上面的图中我们可以知道，一个businessEntity（一家公司）有一个能够告诉我们更多有关公司信息的描述性URL和联系人清单，此外，businessEntity还有一个商业服务清单。每种服务可能有多种调用方法，每种调用都由一个绑定模板描述。绑定模板详细地描述了如何访问一个服务，它受益于一系列描述用户如何访问这一服务的文档。绑定模板和其必要的文档之间的联系是通过所谓的tModel完成的。在上面的图中，这种联系被简单地描述为一个绑定模板有许多tModels。在进一步地解释tModels与绑定模板的关系前，我们必须先弄清楚tModels是什么。 TModel是什么？ 我们可以把tModel想象成数据库库中的一个独立的表，其中包含下面的字段：名字、描述、URL、唯一的关健字。实际上，tModel就是包括有名字和描述，那么使用数据库表表示它是否是一种浪费呢？我们下面就会讨论这一问题： 下面是一个假想的tModel数据库表中的二个实体： 键 名字 描述 URL 1 Java-class 表示一个具备完全资格的java类的名字 http://www.javasoft.com/ 2 Jndi-home 表示一个JNDI名字 http://www.javasoft.com/ 在将tModel比作数据库表方面，有几点值得注意。首先，tModel是一个独立的表，意味着它可以不依赖其他软件而存在；其次，tModel是查找表，提供了键与键的表示之间的转换关系。从这一点来看，tModel象词典那样，是一个引用表。在一些数据库中，这样的表也被称作是码集。 因此，如果在上面的tModel中存在下面的记录： com.mycompany.HelloWorld, 1 com.mycompany.HelloWorldHome, 2 就意味着字符串com.mycompany.HelloWorld是一个有完整资格的Java类；而字符串com.mycompany.HelloWorldHome是一个JNDI名。 因此在一定程度上，tModels中唯一的键与“名字空间”这个概念差不多。为了进一步地说明这个问题，我们来看一下下面的数字： 904-555-1212 904-555-1213 1-56592-391-x 你能够分清这些数字的意义吗？我们需要在一个环境或名字空间中来确认，904-555-1212是电话号码，904-555-1213是传真号，1-56592-391-x是一个ISBN号。 因此在tModel数据库表中，我们将需要定义三个实体：一个是电话号码；一个是传真号码，一个是ISBN号码。 下面我们以mycompany公司公布了一条号码为1-800-my-helpline的电话支持热线，并在UDDI中注册。那么，我们的数据模型为： company name: mycompany Service name: helpline tModel: key=11 (representing telephoneline), name=telephone, description=telephone stuff, url: some at&t url binding: accesspoint: 1-800-my-helpline tModelInstanceInfo: 11 有了对tModel的基本理解后，我们就可以利用UML图表来研究绑定模板与tModels之间的关系了。我在上面曾经说过，这将使我们对绑定模板如何完成UDDI的“如何调用一项服务”的要求有一个直观的理解。
在图2中，我们讨论了一个绑定模板与tModels之间的关系。从图表中我们可以看出，一个绑定模板可以指向一个由一个tModel确定的技术规格，技术规格有二部分组成： ·规格的类型。（例如电子邮件、传真、WSDL、SOAP等。） ·确定输入和输出的文档（在SOAP服务中，这些文档可以是XML输入/输出消息格式。） 既然我们已经对tModels有了一定程度的详细了解，就该再讨论UDDI中更复杂的东西了，也就是身份包和类别包。 理解标识符包和类别包 如果说从概念上理解tModels是理解UDDI需要跨越的第一道障碍，那么理解标识符包和类别包则是需要跨越的第二道障碍。下面的例子可以帮助我们理解这二个概念。 例如，您的公司在美国开展业务需要有一个税号，如果还在另外的国家（例如墨西哥）开展业务，就需要有一个墨西哥的税号。为了能够在UDDI注册簿中获取您的公司的这些信息，在UDDI中应当包括下面的内容： 公司名字：mycompany 标识符： 美国税号：111111 墨西哥税号：2223344 其他国家税号： 333333 ...其他的xml内容 < identifierBag> < keyedReference tModelKey="US-tax-code" keyName="taxnumber" keyValue="1111111"> < keyedReference tModelKey="Mexico-tax-code" keyName="taxnumber" keyValue="2223344"> < keyedReference tModelKey="other-stuff" keyName="taxnumber" keyValue="333333"> ... 其他的xml内容 现在明白tModels如何被用作名字空间了吧。为了进一步地深化对标识符包的理解，我们在下面的图中再次解释了标识符和类别包的概念：
从上面的图中我们能够看出，标识符包是一个在特定环境中的键/值对集合，这个环境从本质上说就是能够唯一地解析名字/值对儿的名字空间，它是由tModel确定的。类别包也是如此，二者之间唯一的区别就是类别包中由tModel确定的名字空间是一个预先确定好的类别。 类别包 我想将公司归类于饭店，其地理位置位于杰克逊维尔。 公司名字：mycompany 适用类： 企业类型：饭店 所在城市：杰克逊维尔 < categoryBag> < keyedReference tModelKey="BusinessTypeClassification" keyName="restaurant" keyValue=".."> < keyedReference tModelKey="CityClassification" keyName="JAX" keyValue=".."> 现在，我们已经搞清楚了tModels是如何用在标识符和类别包中的。从本质上说，tModels就是名字空间。 tModels也能被分类吗？ 我们已经明白了企业实体是如何利用使用了类别包的。另外，UDDI也允许tModels本身被分类。 我们用分层次的文件系统进行说明。目录是用来对文件进行分类的，但目录还可以在父目录下再被分类。象硬盘上的目录那样，tModels也可以被分层次地进行组织。 下面我们来讨论名字为getUniversalTime()的服务，该服务将返回当前全球任一地方的时间。二家存在竞争关系的公司可能会提供这一服务的不同实现。商业服务只限于在公司内部使用，公司之外的用户是不可使用的： company1:getTime() company1:getCurrentTime() 这二者的作用相同，为了表明它们实现的是同一个被称作getUniversalTime()的服务，我们可以定义如下所示的tModel： tModel name：: Get Universal Time category: uddi-org:types, wsdl [意味着这是一个由WSDL文档定义的服务] 上面的定义表明getUniversalTime()是一个WSDL服务，可以由任何公司实现。 既然已经阐明了tModels和包之间的关系，我们下面可以看看一个tModel的UML表示：
从上面的图表中，我们可以看出tModel基本上就是一个名字和描述，另外，它也可以包含一个URL，以提供更进一步的详细资料。它可以由一个标识符包确定和由一个类别包进行分类。 我们已经知道，一个tModel所属于的类别是由UDDI━━WSDL、SOAP等预先定义好的，下面是一个uddi-org:types名字空间中预先定义类别的清单： tModel identifier （唯一标识符） namespace categorization specification xmlSpec soapSpec wsdlSpec protocol transport signatureComponent 如何开始在UDDI中创建一个服务？ 在开始定义服务的tModel时，要求我们为服务指定一个名字和上面所列出的服务类型中的一个。当然了，如果不喜欢上面的分类可以自己创建类别。 我们可以针对上面定义的tModel开发一个商业服务。在商业服务定义中，我们需要指定一个指向定义了服务的输入/输出的WSDL文档的URL。 在UDDI中为什么需要tModels？ 在UDDI中使用tModels的目的如下： ·对商业实体进行标识和分类 ·对商业服务进行标识和分类 ·对tModels进行标识和分类 ·将商业服务绑定到它们抽象的tModel定义上 UDDI名词的快速参考 在看有关UDDI的资料时，如果看到很深奥的术语是一件很烦人的事儿，下面我们就把一些经常用到的与UDDI有关的概念搜集起来，通过比较帮助我们对UDDI概念的理解： 接口和实现 服务绑定是一个容器，接口依赖于其实现；绑定元素详细说明了tModelInstaceInfo和instanceDetail， 我们将再通过一个例子加深对这一问题的例子。对于“获得统一时间”服务而言，细节将提供定义了输入、输出的实际的WSDL文档，绑定的访问点将提供实现服务的物理机器和端口。了解了这些，我们可以得出如下的结论： ·为一种服务定义的tModel是允许多家公司提供该服务的多个实现的界面。 ·服务绑定是具体的实现。 名字空间 Java、C++和XML中都有名字空间的概念，尽管其叫法可能不同，但它们都提供了使名字有意义的环境。在UDDI中，tModel象征着“名字”。当把这个名字作为目录使用时，你的本意是，“我属于这个名字”。从这个意义上说，tModel表示的是名字空间。 技术指纹 当一种服务被注册为tModel时，我们可以注册用来与该服务通讯的协议（例如WSDL、SOAP等）。因此根据所使用的协议不同，tModel有WSDL指纹或SOAP指纹。因此tModel被认为是技术性指纹，每种指纹与一种特定的协议有关。如果说一种tModel可以代表一个“技术性指纹”，我们也可以说tModel能够表示一种“协议”。 分类 分类与类别、名字空间类似，它提供了一种环境，只有在这种环境下，一些数字和名字才有意义。例如， 白页 UDDI注册簿中的企业实体列表和根据名字搜索企业的能力。 黄页 黄页将企业实体按企业类别或其他适用的类别分类。 绿页（技术规格） 绿页有助于我们理解服务的定义和访问服务的要求，serviceBindings和tModels也有助于这一目标的实现。 JAXR JAXR是在服务注册中使用的一种Java XML API。我们以前曾经讨论过，UDDI中的所有元素都用XML文档进行描述。从某种意义上说，嘦我们能够发送包含有服务描述的XML消息，UDDI注册簿就能够对它进行注册或更新。下面我们讨论在没有工具的情况下如何完成这一任务： 1、编写必要的服务描述XML文档。 2、理解SOAP头部，以便能够将XML文件作为一个SOAP附件发送给UDDI注册簿。 3、使用SOAP客户端Java API完成第二步中的任务。 4、通过编程的方式处理SOAP消息。 5、根据UDDI服务的描述，构造消息完成该UDDI服务的任务。 6、对每个消息，完成第2、3步中的操作。 如果使用JAXR，我们可以更好地完成这一任务。因为JAXR允许我们在发送XML消息时无需考虑SOAP头部，而且是一种严格的面向消息的协议。使用JAXR，上面的任务将简化为： 1、编写必要的服务描述XML文档。 2、使用JAXM API发送和接收XML消息，JAXR隐藏了SOAP信息。 3、根据UDDI服务构建消息完成该UDDI服务。（例如，向UDDI注册簿注册UDDI服务包含有4次信息交换过程。）这意味着我们仍然需要与XML内容打交道。 使用这种方式，我们只需处理高层次的Java API即可，这些Java API能够产生必需的消息并通过JAXR传输它们。需要指出的一点是，JAXR也用来完成该任务。 下面列出了JAXR的一些目标： ·支持业界标准的XML注册功能 ·支持成员机构和企业的注册 ·支持任意注册内容的存储和提交 ·支持XML、非XML注册内容的管理 ·支持注册内容间用户定义的结合 ·支持用户定义的注册内容的多级分类 ·支持基于定义的分类计划的注册内容查询 ·支持基于复杂查询的注册内容查询 ·支持基于关健词的注册内容查询 ·支持Web服务的共享 ·支持合作伙伴间商业过程的共享 ·支持合作伙伴间计划的共享 ·支持合作伙伴间商业文档的共享 ·支持合作伙伴间贸易伙伴协议的谈判 ·支持计划汇编 ·支持异类分布注册 ·支持参与各方发布/订阅XML消息 JAXR将不仅仅支持UDDI，还会支持其他的类似注册服务标准（例如ebXML）。
本文转自
http://www.cn-java.com/www1/?action-viewnews-itemid-1645
在过去的数年中，许多开发人员都使用了各种版本的J2EE，使服务器端软件编程的情形得到了很大的改观，现在，他们将再次挑战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表示法。图1是这四种主要元素之间的关系图：
从上面的图中我们可以知道，一个businessEntity（一家公司）有一个能够告诉我们更多有关公司信息的描述性URL和联系人清单，此外，businessEntity还有一个商业服务清单。每种服务可能有多种调用方法，每种调用都由一个绑定模板描述。绑定模板详细地描述了如何访问一个服务，它受益于一系列描述用户如何访问这一服务的文档。绑定模板和其必要的文档之间的联系是通过所谓的tModel完成的。在上面的图中，这种联系被简单地描述为一个绑定模板有许多tModels。在进一步地解释tModels与绑定模板的关系前，我们必须先弄清楚tModels是什么。
TModel是什么？
我们可以把tModel想象成数据库库中的一个独立的表，其中包含下面的字段：名字、描述、URL、唯一的关健字。实际上，tModel就是包括有名字和描述，那么使用数据库表表示它是否是一种浪费呢？我们下面就会讨论这一问题：
下面是一个假想的tModel数据库表中的二个实体：
键 名字 描述 URL
1 Java-class 表示一个具备完全资格的java类的名字 http://www.javasoft.com/
2 Jndi-home 表示一个JNDI名字 http://www.javasoft.com/
在将tModel比作数据库表方面，有几点值得注意。首先，tModel是一个独立的表，意味着它可以不依赖其他软件而存在；其次，tModel是查找表，提供了键与键的表示之间的转换关系。从这一点来看，tModel象词典那样，是一个引用表。在一些数据库中，这样的表也被称作是码集。
因此，如果在上面的tModel中存在下面的记录：
com.mycompany.HelloWorld, 1
com.mycompany.HelloWorldHome, 2
就意味着字符串com.mycompany.HelloWorld是一个有完整资格的Java类；而字符串com.mycompany.HelloWorldHome是一个JNDI名。
因此在一定程度上，tModels中唯一的键与“名字空间”这个概念差不多。为了进一步地说明这个问题，我们来看一下下面的数字：
904-555-1212
904-555-1213
1-56592-391-x
你能够分清这些数字的意义吗？我们需要在一个环境或名字空间中来确认，904-555-1212是电话号码，904-555-1213是传真号，1-56592-391-x是一个ISBN号。
因此在tModel数据库表中，我们将需要定义三个实体：一个是电话号码；一个是传真号码，一个是ISBN号码。
下面我们以mycompany公司公布了一条号码为1-800-my-helpline的电话支持热线，并在UDDI中注册。那么，我们的数据模型为：
company name: mycompany
Service name: helpline
tModel: key=11 (representing telephoneline), name=telephone,
description=telephone stuff, url:
some at&t url
binding:
accesspoint: 1-800-my-helpline
tModelInstanceInfo: 11
有了对tModel的基本理解后，我们就可以利用UML图表来研究绑定模板与tModels之间的关系了。我在上面曾经说过，这将使我们对绑定模板如何完成UDDI的“如何调用一项服务”的要求有一个直观的理解。
在图2中，我们讨论了一个绑定模板与tModels之间的关系。从图表中我们可以看出，一个绑定模板可以指向一个由一个tModel确定的技术规格，技术规格有二部分组成：
·规格的类型。（例如电子邮件、传真、WSDL、SOAP等。）
·确定输入和输出的文档（在SOAP服务中，这些文档可以是XML输入/输出消息格式。）
既然我们已经对tModels有了一定程度的详细了解，就该再讨论UDDI中更复杂的东西了，也就是身份包和类别包。
理解标识符包和类别包
如果说从概念上理解tModels是理解UDDI需要跨越的第一道障碍，那么理解标识符包和类别包则是需要跨越的第二道障碍。下面的例子可以帮助我们理解这二个概念。
例如，您的公司在美国开展业务需要有一个税号，如果还在另外的国家（例如墨西哥）开展业务，就需要有一个墨西哥的税号。为了能够在UDDI注册簿中获取您的公司的这些信息，在UDDI中应当包括下面的内容：
公司名字：mycompany
标识符：
美国税号：111111
墨西哥税号：2223344
其他国家税号： 333333
...其他的xml内容
keyName="taxnumber" keyValue="1111111"> keyName="taxnumber" keyValue="1111111">
keyName="taxnumber" keyValue="2223344"> keyName="taxnumber" keyValue="2223344">
keyName="taxnumber" keyValue="333333"> keyName="taxnumber" keyValue="333333">
... 其他的xml内容
现在明白tModels如何被用作名字空间了吧。为了进一步地深化对标识符包的理解，我们在下面的图中再次解释了标识符和类别包的概念：
从上面的图中我们能够看出，标识符包是一个在特定环境中的键/值对集合，这个环境从本质上说就是能够唯一地解析名字/值对儿的名字空间，它是由tModel确定的。类别包也是如此，二者之间唯一的区别就是类别包中由tModel确定的名字空间是一个预先确定好的类别。
类别包
我想将公司归类于饭店，其地理位置位于杰克逊维尔。
公司名字：mycompany
适用类：
企业类型：饭店
所在城市：杰克逊维尔
keyName="restaurant" keyValue=".."> keyName="restaurant" keyValue="..">
keyName="JAX" keyValue=".."> keyName="JAX" keyValue="..">
现在，我们已经搞清楚了tModels是如何用在标识符和类别包中的。从本质上说，tModels就是名字空间。
tModels也能被分类吗？
我们已经明白了企业实体是如何利用使用了类别包的。另外，UDDI也允许tModels本身被分类。
我们用分层次的文件系统进行说明。目录是用来对文件进行分类的，但目录还可以在父目录下再被分类。象硬盘上的目录那样，tModels也可以被分层次地进行组织。
下面我们来讨论名字为getUniversalTime()的服务，该服务将返回当前全球任一地方的时间。二家存在竞争关系的公司可能会提供这一服务的不同实现。商业服务只限于在公司内部使用，公司之外的用户是不可使用的：
company1:getTime()
company1:getCurrentTime()
这二者的作用相同，为了表明它们实现的是同一个被称作getUniversalTime()的服务，我们可以定义如下所示的tModel：
tModel
name：: Get Universal Time
category: uddi-org:types, wsdl
[意味着这是一个由WSDL文档定义的服务]
上面的定义表明getUniversalTime()是一个WSDL服务，可以由任何公司实现。
既然已经阐明了tModels和包之间的关系，我们下面可以看看一个tModel的UML表示：
从上面的图表中，我们可以看出tModel基本上就是一个名字和描述，另外，它也可以包含一个URL，以提供更进一步的详细资料。它可以由一个标识符包确定和由一个类别包进行分类。
我们已经知道，一个tModel所属于的类别是由UDDI━━WSDL、SOAP等预先定义好的，下面是一个uddi-org:types名字空间中预先定义类别的清单：
tModel
identifier （唯一标识符）
namespace
categorization
specification
xmlSpec
soapSpec
wsdlSpec
protocol
transport
signatureComponent
如何开始在UDDI中创建一个服务？
在开始定义服务的tModel时，要求我们为服务指定一个名字和上面所列出的服务类型中的一个。当然了，如果不喜欢上面的分类可以自己创建类别。
我们可以针对上面定义的tModel开发一个商业服务。在商业服务定义中，我们需要指定一个指向定义了服务的输入/输出的WSDL文档的URL。
在UDDI中为什么需要tModels？
在UDDI中使用tModels的目的如下：
·对商业实体进行标识和分类
·对商业服务进行标识和分类
·对tModels进行标识和分类
·将商业服务绑定到它们抽象的tModel定义上
UDDI名词的快速参考
在看有关UDDI的资料时，如果看到很深奥的术语是一件很烦人的事儿，下面我们就把一些经常用到的与UDDI有关的概念搜集起来，通过比较帮助我们对UDDI概念的理解：
接口和实现
服务绑定是一个容器，接口依赖于其实现；绑定元素详细说明了tModelInstaceInfo和instanceDetail， 我们将再通过一个例子加深对这一问题的例子。对于“获得统一时间”服务而言，细节将提供定义了输入、输出的实际的WSDL文档，绑定的访问点将提供实现服务的物理机器和端口。了解了这些，我们可以得出如下的结论：
·为一种服务定义的tModel是允许多家公司提供该服务的多个实现的界面。
·服务绑定是具体的实现。
名字空间
Java、C++和XML中都有名字空间的概念，尽管其叫法可能不同，但它们都提供了使名字有意义的环境。在UDDI中，tModel象征着“名字”。当把这个名字作为目录使用时，你的本意是，“我属于这个名字”。从这个意义上说，tModel表示的是名字空间。
技术指纹
当一种服务被注册为tModel时，我们可以注册用来与该服务通讯的协议（例如WSDL、SOAP等）。因此根据所使用的协议不同，tModel有WSDL指纹或SOAP指纹。因此tModel被认为是技术性指纹，每种指纹与一种特定的协议有关。如果说一种tModel可以代表一个“技术性指纹”，我们也可以说tModel能够表示一种“协议”。
分类
分类与类别、名字空间类似，它提供了一种环境，只有在这种环境下，一些数字和名字才有意义。例如，
白页
UDDI注册簿中的企业实体列表和根据名字搜索企业的能力。
黄页
黄页将企业实体按企业类别或其他适用的类别分类。
绿页（技术规格）
绿页有助于我们理解服务的定义和访问服务的要求，serviceBindings和tModels也有助于这一目标的实现。
JAXR
JAXR是在服务注册中使用的一种Java XML API。我们以前曾经讨论过，UDDI中的所有元素都用XML文档进行描述。从某种意义上说，嘦我们能够发送包含有服务描述的XML消息，UDDI注册簿就能够对它进行注册或更新。下面我们讨论在没有工具的情况下如何完成这一任务：
1、编写必要的服务描述XML文档。
2、理解SOAP头部，以便能够将XML文件作为一个SOAP附件发送给UDDI注册簿。
3、使用SOAP客户端Java API完成第二步中的任务。
4、通过编程的方式处理SOAP消息。
5、根据UDDI服务的描述，构造消息完成该UDDI服务的任务。
6、对每个消息，完成第2、3步中的操作。
如果使用JAXR，我们可以更好地完成这一任务。因为JAXR允许我们在发送XML消息时无需考虑SOAP头部，而且是一种严格的面向消息的协议。使用JAXR，上面的任务将简化为：
1、编写必要的服务描述XML文档。
2、使用JAXM API发送和接收XML消息，JAXR隐藏了SOAP信息。
3、根据UDDI服务构建消息完成该UDDI服务。（例如，向UDDI注册簿注册UDDI服务包含有4次信息交换过程。）这意味着我们仍然需要与XML内容打交道。
使用这种方式，我们只需处理高层次的Java API即可，这些Java API能够产生必需的消息并通过JAXR传输它们。需要指出的一点是，JAXR也用来完成该任务。
下面列出了JAXR的一些目标：
·支持业界标准的XML注册功能
·支持成员机构和企业的注册
·支持任意注册内容的存储和提交
·支持XML、非XML注册内容的管理
·支持注册内容间用户定义的结合
·支持用户定义的注册内容的多级分类
·支持基于定义的分类计划的注册内容查询
·支持基于复杂查询的注册内容查询
·支持基于关健词的注册内容查询
·支持Web服务的共享
·支持合作伙伴间商业过程的共享
·支持合作伙伴间计划的共享
·支持合作伙伴间商业文档的共享
·支持合作伙伴间贸易伙伴协议的谈判
·支持计划汇编
·支持异类分布注册
·支持参与各方发布/订阅XML消息
JAXR将不仅仅支持UDDI，还会支持其他的类似注册服务标准（例如ebXML）。
在过去的数年中，许多开发人员都使用了各种版本的J2EE，使服务器端软件编程的情形得到了很大的改观，现在，他们将再次挑战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表示法。图1是这四种主要元素之间的关系图：
从上面的图中我们可以知道，一个businessEntity（一家公司）有一个能够告诉我们更多有关公司信息的描述性URL和联系人清单，此外，businessEntity还有一个商业服务清单。每种服务可能有多种调用方法，每种调用都由一个绑定模板描述。绑定模板详细地描述了如何访问一个服务，它受益于一系列描述用户如何访问这一服务的文档。绑定模板和其必要的文档之间的联系是通过所谓的tModel完成的。在上面的图中，这种联系被简单地描述为一个绑定模板有许多tModels。在进一步地解释tModels与绑定模板的关系前，我们必须先弄清楚tModels是什么。 TModel是什么？ 我们可以把tModel想象成数据库库中的一个独立的表，其中包含下面的字段：名字、描述、URL、唯一的关健字。实际上，tModel就是包括有名字和描述，那么使用数据库表表示它是否是一种浪费呢？我们下面就会讨论这一问题： 下面是一个假想的tModel数据库表中的二个实体： 键 名字 描述 URL 1 Java-class 表示一个具备完全资格的java类的名字 http://www.javasoft.com/ 2 Jndi-home 表示一个JNDI名字 http://www.javasoft.com/ 在将tModel比作数据库表方面，有几点值得注意。首先，tModel是一个独立的表，意味着它可以不依赖其他软件而存在；其次，tModel是查找表，提供了键与键的表示之间的转换关系。从这一点来看，tModel象词典那样，是一个引用表。在一些数据库中，这样的表也被称作是码集。 因此，如果在上面的tModel中存在下面的记录： com.mycompany.HelloWorld, 1 com.mycompany.HelloWorldHome, 2 就意味着字符串com.mycompany.HelloWorld是一个有完整资格的Java类；而字符串com.mycompany.HelloWorldHome是一个JNDI名。 因此在一定程度上，tModels中唯一的键与“名字空间”这个概念差不多。为了进一步地说明这个问题，我们来看一下下面的数字： 904-555-1212 904-555-1213 1-56592-391-x 你能够分清这些数字的意义吗？我们需要在一个环境或名字空间中来确认，904-555-1212是电话号码，904-555-1213是传真号，1-56592-391-x是一个ISBN号。 因此在tModel数据库表中，我们将需要定义三个实体：一个是电话号码；一个是传真号码，一个是ISBN号码。 下面我们以mycompany公司公布了一条号码为1-800-my-helpline的电话支持热线，并在UDDI中注册。那么，我们的数据模型为： company name: mycompany Service name: helpline tModel: key=11 (representing telephoneline), name=telephone, description=telephone stuff, url: some at&t url binding: accesspoint: 1-800-my-helpline tModelInstanceInfo: 11 有了对tModel的基本理解后，我们就可以利用UML图表来研究绑定模板与tModels之间的关系了。我在上面曾经说过，这将使我们对绑定模板如何完成UDDI的“如何调用一项服务”的要求有一个直观的理解。
在图2中，我们讨论了一个绑定模板与tModels之间的关系。从图表中我们可以看出，一个绑定模板可以指向一个由一个tModel确定的技术规格，技术规格有二部分组成： ·规格的类型。（例如电子邮件、传真、WSDL、SOAP等。） ·确定输入和输出的文档（在SOAP服务中，这些文档可以是XML输入/输出消息格式。） 既然我们已经对tModels有了一定程度的详细了解，就该再讨论UDDI中更复杂的东西了，也就是身份包和类别包。 理解标识符包和类别包 如果说从概念上理解tModels是理解UDDI需要跨越的第一道障碍，那么理解标识符包和类别包则是需要跨越的第二道障碍。下面的例子可以帮助我们理解这二个概念。 例如，您的公司在美国开展业务需要有一个税号，如果还在另外的国家（例如墨西哥）开展业务，就需要有一个墨西哥的税号。为了能够在UDDI注册簿中获取您的公司的这些信息，在UDDI中应当包括下面的内容： 公司名字：mycompany 标识符： 美国税号：111111 墨西哥税号：2223344 其他国家税号： 333333 ...其他的xml内容 < identifierBag> < keyedReference tModelKey="US-tax-code" keyName="taxnumber" keyValue="1111111"> < keyedReference tModelKey="Mexico-tax-code" keyName="taxnumber" keyValue="2223344"> < keyedReference tModelKey="other-stuff" keyName="taxnumber" keyValue="333333"> ... 其他的xml内容 现在明白tModels如何被用作名字空间了吧。为了进一步地深化对标识符包的理解，我们在下面的图中再次解释了标识符和类别包的概念：
从上面的图中我们能够看出，标识符包是一个在特定环境中的键/值对集合，这个环境从本质上说就是能够唯一地解析名字/值对儿的名字空间，它是由tModel确定的。类别包也是如此，二者之间唯一的区别就是类别包中由tModel确定的名字空间是一个预先确定好的类别。 类别包 我想将公司归类于饭店，其地理位置位于杰克逊维尔。 公司名字：mycompany 适用类： 企业类型：饭店 所在城市：杰克逊维尔 < categoryBag> < keyedReference tModelKey="BusinessTypeClassification" keyName="restaurant" keyValue=".."> < keyedReference tModelKey="CityClassification" keyName="JAX" keyValue=".."> 现在，我们已经搞清楚了tModels是如何用在标识符和类别包中的。从本质上说，tModels就是名字空间。 tModels也能被分类吗？ 我们已经明白了企业实体是如何利用使用了类别包的。另外，UDDI也允许tModels本身被分类。 我们用分层次的文件系统进行说明。目录是用来对文件进行分类的，但目录还可以在父目录下再被分类。象硬盘上的目录那样，tModels也可以被分层次地进行组织。 下面我们来讨论名字为getUniversalTime()的服务，该服务将返回当前全球任一地方的时间。二家存在竞争关系的公司可能会提供这一服务的不同实现。商业服务只限于在公司内部使用，公司之外的用户是不可使用的： company1:getTime() company1:getCurrentTime() 这二者的作用相同，为了表明它们实现的是同一个被称作getUniversalTime()的服务，我们可以定义如下所示的tModel： tModel name：: Get Universal Time category: uddi-org:types, wsdl [意味着这是一个由WSDL文档定义的服务] 上面的定义表明getUniversalTime()是一个WSDL服务，可以由任何公司实现。 既然已经阐明了tModels和包之间的关系，我们下面可以看看一个tModel的UML表示：
从上面的图表中，我们可以看出tModel基本上就是一个名字和描述，另外，它也可以包含一个URL，以提供更进一步的详细资料。它可以由一个标识符包确定和由一个类别包进行分类。 我们已经知道，一个tModel所属于的类别是由UDDI━━WSDL、SOAP等预先定义好的，下面是一个uddi-org:types名字空间中预先定义类别的清单： tModel identifier （唯一标识符） namespace categorization specification xmlSpec soapSpec wsdlSpec protocol transport signatureComponent 如何开始在UDDI中创建一个服务？ 在开始定义服务的tModel时，要求我们为服务指定一个名字和上面所列出的服务类型中的一个。当然了，如果不喜欢上面的分类可以自己创建类别。 我们可以针对上面定义的tModel开发一个商业服务。在商业服务定义中，我们需要指定一个指向定义了服务的输入/输出的WSDL文档的URL。 在UDDI中为什么需要tModels？ 在UDDI中使用tModels的目的如下： ·对商业实体进行标识和分类 ·对商业服务进行标识和分类 ·对tModels进行标识和分类 ·将商业服务绑定到它们抽象的tModel定义上 UDDI名词的快速参考 在看有关UDDI的资料时，如果看到很深奥的术语是一件很烦人的事儿，下面我们就把一些经常用到的与UDDI有关的概念搜集起来，通过比较帮助我们对UDDI概念的理解： 接口和实现 服务绑定是一个容器，接口依赖于其实现；绑定元素详细说明了tModelInstaceInfo和instanceDetail， 我们将再通过一个例子加深对这一问题的例子。对于“获得统一时间”服务而言，细节将提供定义了输入、输出的实际的WSDL文档，绑定的访问点将提供实现服务的物理机器和端口。了解了这些，我们可以得出如下的结论： ·为一种服务定义的tModel是允许多家公司提供该服务的多个实现的界面。 ·服务绑定是具体的实现。 名字空间 Java、C++和XML中都有名字空间的概念，尽管其叫法可能不同，但它们都提供了使名字有意义的环境。在UDDI中，tModel象征着“名字”。当把这个名字作为目录使用时，你的本意是，“我属于这个名字”。从这个意义上说，tModel表示的是名字空间。 技术指纹 当一种服务被注册为tModel时，我们可以注册用来与该服务通讯的协议（例如WSDL、SOAP等）。因此根据所使用的协议不同，tModel有WSDL指纹或SOAP指纹。因此tModel被认为是技术性指纹，每种指纹与一种特定的协议有关。如果说一种tModel可以代表一个“技术性指纹”，我们也可以说tModel能够表示一种“协议”。 分类 分类与类别、名字空间类似，它提供了一种环境，只有在这种环境下，一些数字和名字才有意义。例如， 白页 UDDI注册簿中的企业实体列表和根据名字搜索企业的能力。 黄页 黄页将企业实体按企业类别或其他适用的类别分类。 绿页（技术规格） 绿页有助于我们理解服务的定义和访问服务的要求，serviceBindings和tModels也有助于这一目标的实现。 JAXR JAXR是在服务注册中使用的一种Java XML API。我们以前曾经讨论过，UDDI中的所有元素都用XML文档进行描述。从某种意义上说，嘦我们能够发送包含有服务描述的XML消息，UDDI注册簿就能够对它进行注册或更新。下面我们讨论在没有工具的情况下如何完成这一任务： 1、编写必要的服务描述XML文档。 2、理解SOAP头部，以便能够将XML文件作为一个SOAP附件发送给UDDI注册簿。 3、使用SOAP客户端Java API完成第二步中的任务。 4、通过编程的方式处理SOAP消息。 5、根据UDDI服务的描述，构造消息完成该UDDI服务的任务。 6、对每个消息，完成第2、3步中的操作。 如果使用JAXR，我们可以更好地完成这一任务。因为JAXR允许我们在发送XML消息时无需考虑SOAP头部，而且是一种严格的面向消息的协议。使用JAXR，上面的任务将简化为： 1、编写必要的服务描述XML文档。 2、使用JAXM API发送和接收XML消息，JAXR隐藏了SOAP信息。 3、根据UDDI服务构建消息完成该UDDI服务。（例如，向UDDI注册簿注册UDDI服务包含有4次信息交换过程。）这意味着我们仍然需要与XML内容打交道。 使用这种方式，我们只需处理高层次的Java API即可，这些Java API能够产生必需的消息并通过JAXR传输它们。需要指出的一点是，JAXR也用来完成该任务。 下面列出了JAXR的一些目标： ·支持业界标准的XML注册功能 ·支持成员机构和企业的注册 ·支持任意注册内容的存储和提交 ·支持XML、非XML注册内容的管理 ·支持注册内容间用户定义的结合 ·支持用户定义的注册内容的多级分类 ·支持基于定义的分类计划的注册内容查询 ·支持基于复杂查询的注册内容查询 ·支持基于关健词的注册内容查询 ·支持Web服务的共享 ·支持合作伙伴间商业过程的共享 ·支持合作伙伴间计划的共享 ·支持合作伙伴间商业文档的共享 ·支持合作伙伴间贸易伙伴协议的谈判 ·支持计划汇编 ·支持异类分布注册 ·支持参与各方发布/订阅XML消息 JAXR将不仅仅支持UDDI，还会支持其他的类似注册服务标准（例如ebXML）。
本文转自
http://www.cn-java.com/www1/?action-viewnews-itemid-1645
1736
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
