在过去的数年中，许多开发人员都使用了各种版本的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="2223344"
keyName="taxnumber" keyValue="333333"
... 其他的xml内容
现在明白tModels如何被用作名字空间了吧。为了进一步地深化对标识符包的理解，我们在下面的图中再次解释了标识符和类别包的概念：
从上面的图中我们能够看出，标识符包是一个在特定环境中的键/值对集合，这个环境从本质上说就是能够唯一地解析名字/值对儿的名字空间，它是由tModel确定的。类别包也是如此，二者之间唯一的区别就是类别包中由tModel确定的名字空间是一个预先确定好的类别。
类别包
我想将公司归类于饭店，其地理位置位于杰克逊维尔。
公司名字：mycompany
适用类：
企业类型：饭店
所在城市：杰克逊维尔
keyName="restaurant" 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，以提供更进一步的具体资料。它可以由一个标识符包确定和由一个类别包进行分类。
我们已经知道，一个t
