SOA是一种利用可重用的业务逻辑构建企业系统平台的方式。这些业务逻辑是一些离散的功能，可以为了实现不同的功能进行重用，开发人员可以通过调用和编排多个服务、事件和模型来创建复杂的应用程序，所以将这些业务逻辑组合起来可以成为更高级的业务流程。
提高资产重用：资产重用可以增加企业IT基础架构的灵活性，降低对整体化应用的依赖，这些应用是很难进行配置和重用的。
提高兼容性：目前很多企业对外部规则与内部业务指导方针的兼容级别缺乏有效的监控。然而，为了实现SOA，把资产都进行注册，SOA很容易的就可以让管理员对现有资产的目录进行准确的维护，收集度量和加强操作规范。
提高效率：Web Service可以增强编码的标准，更容易的实现通讯并且在大型的、地理位置分散的企业中最大程度的减少重复的工作。
然而，很多SOA潜在的优点取决于实施方法。因为SOA平台由众多的“服务”组成，这些服务可以配置成多种方式的交互，这个对IT机构选择组件和机制来使服务的性能、效率和扩展性达到最优水平非常重要。
本文将讲述服务注册与发现的不同方法，服务管理的生命周期。这里还要介绍两种可能用到的配置SOA平台的方法。在SOA中，服务注册提高资产重用程度
因为SOA是基于离散的可重用服务，比如WSDL服务描述、BEPL流程描述或者XSLT映射和远远超越整体化应用集成的扩展和分布的组合。如果不能正确地管理和组织，情况会变得混乱。
通过创建集中的元数据注册，企业可以使开发人员更容易的查找和重用已有的资产。服务注册是服务接口在SOA中的索引。它实现一个对服务定义具体实现的链接的功能，但是并不必需包括定义本身。这个功能就像一个目录，服务注册必须提供向这个目录中发布新的服务的方法，并且要在目录中浏览和搜索可重用的服务，还要作为一种服务分类的机制使他们能与应用关联。这些注册可以防止重复的工作并且提高效率。UDDI是SOA注册的Web Service标准。
服务仓库，保存服务定义实现的的内容，比如Java代码，BPEL流程，WSDL描述或者XSLT转换。除了服务定义的内容之外，服务仓库通常还保存元数据，比如服务(比如，XSLT映射调用BEPL业务流程)和版本管理机制之间的依赖关系。UDDI提供基于标准的Web Service索引
被用来定位、调用和管理服务的元数据，UDDI大概是三个Web Service核心标准中最不被了解的。同更为人所知的WSDL和SOAP一起，UDDI使松耦合架构成为可能，这也是SOA的主要特点(见图1)。UDDI标准也描述了一套Web Service编程接口(API)用来在服务注册中发布、搜索、变更调用和复制。
图1 UDDI作为SOA实现的一部分
UDDI提供两个主要功能：
位置独立：与在应用程序中通过硬编码调用它们的目标服务不同，UDDI提供了一种在运行时动态的查找和定位服务接口的机制。
分类法：UDDI支持基于服务类别和Web Service搜索引擎功能的分类。有着良好定义的服务分类可以帮助发布比仅根据名称查询更好的结果。
基本的UDDI信息模型由一个包括四个数据类型的层组成：
1. businessEntity. UDDI信息模型的最高一级是businessEntity——比如，一家自行车修理店。
2. businessService.businessEntity可以包含很多businessService分类——比如，自行车商店可以提供很多维修服务，新自行车和齿轮。
3. bindingTemplate.bindingTemplate被businessService包含，bindingTemplate包括服务运作的技术信息。
4. tModels.这些技术模型是用来展现查找和鉴别服务的命名空间的UDDI结构，并且作为一种描述服务调用信息的技术指纹。tModel是被bindTemplate引用的，而不是被包含的。一个tModel的例子是习惯分类中的叫做“repair chain”的服务。作为一个技术指纹，tModel可能是一个WSDL规则用来描述服务和他的调用机制之间的接口。SOA的好处对系统配置的依赖
对SOA环境的配置有两种可选的方式。第一种方式，服务的消费者和提供者以点到点(或者端到端)的方式直接通讯。在第二种方式中，在服务的消费者和提供者之间有一个服务中介人，比如企业服务总线(ESB)。TIBCO强烈建议中介方式，在这种方式中所有的服务请求和处理都通过ESB，这种方式比点到点的配置方式具有更好的灵活性，可扩展性和可靠性。
为了理解直接通讯和中介通讯的区别，我们考虑一个现实中的例子。假设你自行车上的链条坏了，需要安装一个新的。在这个例子中，服务就是“维修链条”——要访问这个服务，需要打电话给自行车店。在直接查找的场景中，你可能需要查找电话黄页，找到“自行车维修”目录下的修理店，然后直接给修理店打电话要求服务。这个方法就是前面提到的点到点方式。你是服务消费者，自行车修理店是服务提供者，电话黄页是告诉你如何请求服务的注册库。
然而，如果这个自行车修理店搬到了另一个地方并且更换了新的电话号码，那电话黄页上的信息就不在有用了。在SOA环境中也会有相同的问题，当一个服务提供者更改了服务的位置而没有更新注册库，服务消费者就无法再访问这个服务，直到注册库中的记录被更新。即使这样，也只有在消费者每次检查电话黄页并进行服务请求的时候才会发现记录被更新了。
在中介方式中，自行车修理店会有个800电话号码，它可以转到本地电话(即使电话号码变更了)。在这个例子中，800电话就作为ESB来保证服务消费者可以找到合适的服务，而不管他们的本地电话有没有变化。因为800电话变更的可能性很小，而且更容易记住这个虚拟号码，就不用去频繁的检查电话黄页了。
中间件提供最大限度的灵活性和优越性
为了理解为什么服务总线对良好设计的SOA环境非常重要，必须首先理解这个环境的基本元素，如图2。
图2 SOA环境中的基本元素
1. 服务仓库：元数据仓库可以存储、查询和获取任何类型的数据元素和对象，包括服务定义、策略、Schema、样式表、命名空间、例子代码和Billing信息。他们可以为SOA环境中的其他组件提供安全参数、消息格式信息、授权技术、转换信息、消息处理的规则和逻辑、设计和架构的信息、对象(比如，属性、方法或者继承数据)信息等等。
服务仓库可以用来存储各种角色，比如注册权、提交机构和负责机构。通过支持模式分类，仓库可以管理对象并且提供外部订阅，同时，灵活多变的结合可以有利于加快影响分析。
由于服务仓库做为一个连接所有流程和数据库的通用引用点，集成数据和方法就简单得成为找到他们的等价物并将他们结合在一起。因为服务仓库知道源系统和目的系统的数据模式，它也包括了从源系统到目的系统消息流的转换信息。有时候这种信息转换可以自动的通过语义映射进行生成，而不需要人工的干预。服务仓库也可以通过跟踪所有的资产和依赖来使IT管理变得更简单。
2. 服务生产者.服务生产者创建服务——通过编码或者配置来执行某种业务流程，比如信用鉴定——并且对服务注册发布这些服务的目录信息。在SOA中进行重用意味着很多服务消费者共享同样的服务实例。因为当共享的服务停止或者移植到其他的地方，使用它的应用系统就会终止，这样在服务提供者的实现和位置修改时，确保服务消费者不会终止就非常重要。
3. WSDL.服务提供者使用WSDL对服务注册发布服务接口描述。尽管WSDL文件包含服务对外开放的接口信息，但是它没有包含开发人员可能会用到的所有的附加信息，尤其是在他们决定是否要使用这个服务的时候。比如，WSDL文档没有包含服务的定价数据或者服务什么时候是可用的。新的标准，比如WS-Policy正在形成，可以用来描述比简单的WSDL接口更丰富的服务信息，但是即使使用WS-Policy，每个服务的实现者还是有可能使用不同的方式进行服务属性的描述。
4. 服务注册.元数据注册库被设计用来管理公共元数据，这些元数据是存储在不同类型的企业服务仓库中的数据元素的子集。大多数的服务注册库是开发人员在开发时使用，在运行时并不进行查询。服务注册被设计用来与SOAP消息，对WSDL文档的进行访问授权，和定义的，与在目录中列出的Web Service交互的其他的原数据共同工作。
在SOA环境中，服务注册是基于UDDI标准的。UDDI服务注册是开放的，基于XML的，平台无关的，允许将业务展示在Internet上，并且为与其它业务交互定义参数;或者企业内部的一个团体对其他的团体开发它的服务。
5. 服务消费者.一旦一个服被发布到服务注册库中，服务消费者就可以通过浏览或者订阅发现这个服务。在点对点的方式中，服务消费者需要通过SOAP向服务提供者发送一个运行时请求。然而，在ESB中，服务消费者调用ESB，ESB将请求路由给最合适的服务提供者。
6. SOAP请求. 在执行了一个服务查找之后，不论通过UDDI服务注册的动态查找，还是通过中间件的代理，服务消费者都使用SOAP进行服务调用。这些请求通常都使用HTTP协议，也可能使用其他的消息协议。
ESB对于SOA环境的保持高性能，高扩展性和高可用性非常重要。作为服务消费者和服务生产者之间的缓和剂，中间件作为连接基础架构和传输请求之间的每一个元素的信息总线。这种方式保证了在遗留系统上创建服务接口的可靠性，是他们能够加入服务注册库而不需要硬编码，使应用程序在调用一个服务时不需要再每次都进行服务查找，从而提高了性能。因为在服务消费者和服务生产者之间不再使用直接连接，中间件也提高了平台的安全性。
点对点方式降低性能、扩展性和可靠性
企业应用系统经常在非常复杂和不灵活的IT环境中运作，包括独立的整体化的应用程序，点对点连接和硬编码的接口。这种环境在业务需求变更的时候很难被修改。因为这种原因，当SOA系统中没有信息总线的时候，服务消费者通常将他们的服务终点进行硬编码——这种方式就无法得到使用动态服务选择的好处。这种方式在某种些时候可能会提高性能，但是它缺乏灵活性，不能允许在服务更改位置时不用停止流程。比如，当服务被移植到一台新的服务器，应编码的流程就会因为找不到服务而运行失败。
一些企业试图采用动态服务查找来解决这个问题——这种方式可以减少代码的维护量，但会使性能和扩展性下降。大多数企业都因为各种原因而没有去实现动态服务查找。安全方面的问题也显现出来——企业通常不希望在没有检视代码的情况下就很容易的相信一个服务。性能和扩展性也是个问题，如果服务代理选择了一个很忙的服务，可能会造成重复调用并且降低整个网络的性能。
