商业服务信息：businessService元素

　　businessService 结构将一系列有关商业流程或分类目录的Web 服务的描述组合到一起。businessService和下面要提到的bindingTemplate一起构成了"绿页"信息。其中，一个可能的商业流程的例子是一组相关的Web 服务信息，包括采购服务、运输服务和其它的高层商业流程。这些服务都将是提供这些商业流程服务的商业实体所需要注册的Web服务。

　　这些businessService的信息集合可以再次加以分类，使Web应用服务的描述可以按不同的行业、产品、服务类型或是地域划分来进行。分类的方法的机制与businessEntity是类似的。

　　下面是businessService结构的XML Schema定义:

<element name = "businessService">
<type content = "elementOnly">
<group order = "seq">
<element ref = "name"/>
<element ref = "description" minOccurs = "0" maxOccurs = "*"/>
<element ref = "bindingTemplates"/>
<element ref = "categoryBag" minOccurs = "0" maxOccurs = "1"/>
</group>
<attribute name = "serviceKey" minOccurs = "1" type = "string"/>
<attribute name = "businessKey" type = "string"/>
</type>
</element>
 
　　其中，serviceKey和businessKey两个直接属性分别表示businessService的主键和businessService的父类容器businessEntity的主键标识。一般的，serviceKey是在注册后由UDDI注册中心自动赋予，并在businessService整个生命周期中有效。而businessKey的值仅当businessService的父类容器发生变化时才会被修改。

　　name、description分别表示该服务的名、描述等信息。categoryBag的作用与businessEntity中是类似的。

　　bindingTemplates是一个bindingTemplate的容器，它表示了这个businessService所包含的所有技术绑定信息。在bindingTemplates中的每个bindingTemplate条目都是本Web服务的一条技术描述信息。这个结构表达了businessService和bindingTemplate的父子包含关系。

　　技术绑定信息：bindingTemplate元素

　　对于每一个businessService，存在一个或多个Web 服务的技术描述bindingTemplate。这些技术描述包括应用程序连接远程Web 服务并与之通讯所必须的信息。这些信息包括Web应用服务的地址、应用服务宿主和调用服务前必须调用的附加应用服务等。另外，通过附加的特性还可以实现一些复杂的路由选择，诸如负载平衡等。

　　下面是bindingTemplate结构的XML Schema定义:

<element name = "bindingTemplate">
<type content = "elementOnly">
<group order = "seq">
<element ref = "description" minOccurs = "0" maxOccurs = "*"/>
<group order = "choice">
<element ref = "accessPoint" minOccurs = "0" maxOccurs = "1"/>
<element ref = "hostingRedirector" minOccurs = "0" maxOccurs = "1"/>
</group>
<element ref = "tModelInstanceDetails"/>
</group>
<attribute name = "bindingKey" minOccurs = "1" type = "string"/>
<attribute name = "serviceKey" type = "string"/>
</type>
</element>
 
　　其中，bindingKey和serviceKey两个直接属性分别表示bindingTemplate的主键和bindingTemplate的父类容器businessService的主键标识。一般的，bindingKey是在注册后由UDDI注册中心自动赋予，并在bindingTemplate整个生命周期中有效。而serviceKey的值仅当bindingTemplate的父类容器发生变化时才会被修改。

　　tModelInstanceDetails包含了这个bindingTemplate所定位的调用入口的调用规范的描述，这些描述都以tModel的形式出现。事实上，tModel并不是bindingTemplate的子元素，这里应该理解成引用关系。

　　accessPoint定义了由这个bindingTemplate描述的服务调用入口的访问地址，用户可以通过这个地址访问具体的服务。而hostingRedirector则是因为accessPoint无法满足需求而提供的替代机制，同时hostingRedirector机制也是一种及为有效的满足当前电子交易市场、ISP等中间机构存在的情况下的强有力的描述托管机制。

　　两种不能被bindingTemplate中accessPoint信息直接支持的特殊需求是：

　　Web服务在技术上由第三方提供主机: 一个商业实体可以选择这样一种方式来发布一种服务，该服务逻辑上属于本企业，但实际上该服务是在远程的或者第三方的主机上运行的。应用服务提供商和网络交易市场运营商是这种情况的典型代表。在这种情况下，实际上是第三方实际控制绑定信息的运行时态的取值。

　　用户指定的对绑定位置的访问控制: 在其他情况中，比如情景相关的重定向是基于调用者的标识的，或者甚至是每天的路由，此时，提供更动态的对远程服务的实际联络信息的方式是非常必需的，相比起缓存accessPoint数据以支持调用的方式更为必要。关于对bindingTemplate信息的缓存机制请参阅本文后面的相关小节。
 
　　由于这些原因，bindingTemplate结构包括一个备用的数据元素，被称为hostingRedirector。hostingRedirector元素的存在和accessPoint信息是互斥的。这样使我们得以知道到底应该如何获取包含所需要使用的accessPoint数据的实际bindingTemplate信息，使用hostingRedirector或accessPoint。