本文不仅仅是为架构师准备的：使用企业服务总线(Enterprise Service Bus)，作为支持面向服务的体系结构(SOA)的基础架构，也将使开发人员能够更加轻松地工作。

　　引言

　　重要的应用程序很少是单独存在的；如果不能与其他的应用程序一起使用，应用程序将难以发挥很大的作用。面向服务的体系结构往往将应用程序集成在一起，这样它们就可以协同工作并提高工作效率，每个应用程序都分成必须相互集成的各个部分。SOA模型——服务使用者调用服务提供者——可能看起来相当简单，但是它提出了两个重要的问题：

　　·使用者如何找到它需要调用的服务的提供者
　　·使用者如何快速而可靠地调用服务，而网络实际上很慢且不可靠？

　　对于这两个问题，有一个相当简单的答案，即采用称为企业服务总线(ESB)的方法。ESB处理使用者和提供者之间的所有复杂问题，从而使得服务调用对于两者都比较简单。ESB不仅使应用程序（或其各个部分）可以更加容易地调用服务，而且还帮助它们转换数据和广播事件通知。ESB的设计体现了许多已为大家接受的设计模式和标准规范。

　　本文旨在帮助开发人员理解ESB的作用以及应用程序集成的必要部分（包括SOA）。重点不在于定义或产品，而在于ESB实现的功能，这样您就不必自己实现这些功能。它展示了ESB可以为您做什么。

　　调用服务

　　为了帮助您理解应用程序集成和SOA，我将从介绍Web服务如何工作开始。Web服务只不过是您可以用来实现服务调用的一种方法。它们甚至可能不是最好的方法，但却是目前可用的最标准的方法，它们能够帮助我形成正在尝试完成的任务的设计。

　　首先，我必须解释相关术语。Web服务非常类似过程性编程中的功能：它具有名称、参数和结果。名称就是统一资源标识符(URI)，通过URI，Web服务提供者使Web服务可以作为端点使用。Web服务使用者将端点URI作为查找和调用Web服务的地址。使用者调用端点时会将请求传送到Web服务，请求中包含特定的操作和参数。在执行服务之后，端点将响应 传送回使用者，响应指示成功（或错误），并且包含服务的结果。通过这种方式，使用者可以调用提供者的端点，传入请求，并得到响应。

　　目前，定义实现Web服务的方式的是WS-I Basic Profile 1.1，该概要包括SOAP 1.1 over HTTP 1.1，后者由Web服务描述语言(WSDL)1.1进行定义。（请参阅参考资料以获得指向规范本身的链接。）有了SOAP over HTTP，使用者可以通过HTTP请求中的一个绑定HTTP消息传输的SOAP请求调用服务。使用者同步阻塞HTTP套接字，等待包含SOAP响应的HTTP响应。端点的API是由使用者和提供者之间的约定描述的。

　　既然您了解了相关术语，就让我们来看一看使用者用于调用服务的通信选择：同步或异步。
　　
　　同步与异步调用

　　使用者可以同步或异步实现服务调用。从使用者的观点来看，这两种方式的不同之处在于：

　　·同步——使用者通过单个线程调用服务；该线程发送请求，在服务运行时阻塞，并且等待响应。
　　·异步——使用者通过两个线程调用服务；一个线程发送请求，而另一个单独的线程接收响应。

　　术语同步和异步经常与顺序和并发混淆了。后面的这两个术语与执行单独的任务必须遵循的顺序有关，而同步和异步 与线程执行单个任务（如调用单个服务）的方式有关。理解同步和异步调用之间的不同的一种很好的方法是考虑崩溃恢复的后果：

　　·同步——如果使用者在服务运行的过程中阻塞时崩溃了，当它重新启动时，将无法重新连接到正在进行的调用，所以响应丢失了。使用者必须重复调用过程，并且期望这次不会崩溃。
　　·异步——如果使用者在发送了请求之后等待响应时崩溃了，当它重新启动时，可以继续等待响应，所以响应不会丢失。

　　崩溃恢复不是同步和异步调用之间的唯一不同，但是如果您尝试确定某个调用采用哪一种方式，请考虑每一种调用如何处理崩溃恢复，这通常可以给您一个很好的答案。

　　既然您了解了使用者对服务调用通信方式的选择，就可以看一看使用者对用于连接到提供者的连接方式的选择。使用者可以从下列通信方式中选择一种：

　　·同步直接调用
　　·同步代理调用
　　·异步代理调用

　　我将分别解释每一种方式。

　　同步直接调用

　　调用Web服务的SOAP over HTTP方式就是直接的：非常类似于执行函数调用，使用者知道端点的地址，并直接调用它。为了使调用成功，Web服务必须在使用者调用端点时可用，而且必须在使用者超时之前进行响应。如果将Web服务部署到新的位置（例如不同的Internet域），则必须让使用者知道端点的新URI。要部署具有相同服务类型的多个提供者，必须将每个提供者的端点部署到不同的URI。要在不同的服务提供者之间进行选择，使用者必须知道其中的每个URI。

　　例如，考虑一个简单的用于获取股票报价的Web服务：使用者传入股票代号，然后取回股票的当前价格。此服务可能由多个不同的代理公司提供，每个公司都有一个不同的Internet URL。获取Web服务的URL是一个先有鸡还是先有蛋的问题。如果使用者知道端点的位置，它就可以询问服务其地址是什么，但是使用者需要知道地址才能询问地址。

　　为了解决这个问题，统一描述、发现和集成（Universal Description Discovery and Integration，UDDI）描述了一种Web服务，它是一个类似于电话簿的目录，用于查找其他的Web服务。其思想就是，将UDDI部署到一个使用者已经知道的知名地址，然后使用者就可以使用UDDI来查找其他的Web服务。

　　对于股票报价服务，使用者知道UDDI服务的地址，而UDDI服务又知道股票报价服务的地址，如图1所示。

　　图1：直接调用Web服务
 
　　图2展示了使用者如何使用UDDI服务来查找股票报价提供者的端点，并且调用其中的一个端点。该流程的工作方式如下：

　　·使用者向UDDI询问服务提供者列表。
　　·使用者从UDDI返回的列表中选择一个提供者的端点。
　　·使用者调用该端点。

　　图2：同步直接服务调用
 
　　请注意，选择提供者的算法完全由使用者决定；在本例中，使用者只选择列表中的第一个。实际实现可能要复杂一些。

　　还需要注意的是，因为服务端点可能改变，所以当使用者每次需要调用服务时，都应该重新查询UDDI，查看提供者的详细信息是否有改变。必须为每次服务调用查询UDDI大大增加了调用服务的开销，特别是在提供者的详细信息通常不改变的情况下。

　　同步代理调用

　　直接调用方法的不足之处在于，使用者必须知道提供者的端点的URI才能调用服务。它使用UDDI作为查找URI的目录。如果提供者更改其端点的URI，它必须向UDDI服务器注册，这样UDDI就有新的URI，然后使用者必须重新查询UDDI以获得新的URI。事实上，这意味着每次使用者需要调用服务时，它都必须查询UDDI以找到端点URI，并从中进行选择。这导致使用者把许多时间浪费在重复查找UDDI和选择提供者这样的工作上。这种方法还使得使用者必须以某种方式从看起来不可区分的列表中选择提供者。

　　简化这个问题的一个方法是引入Broker，作为调用Web服务的中介。使用者不再直接调用服务提供者，而是调用Broker中的服务代理，而服务代理又调用服务提供者。使用者需要知道代理端点的URI，以便使用UDDI查找地址，但是在本例中，UDDI只返回单个URI，因而使用者不必选择。使用者甚至没有意识到端点在代理中；而只是知道它可以使用此URI来调用Web服务。Broker协调使用者与服务提供者，如图3所示。

　　图3：同步企业服务总线
 
　　代理的URI应该是稳定的：在使用者使用UDDI获取代理的URI之后，它第一次调用服务，在以后的调用中，使用者可以重用该URI（至少在代理停止工作之前）。同时，代理跟踪提供者及其URI（可能在调用之间发生改变）、它们是否可用（上一次调用失败了吗？）、它们的负载（上一次调用花了多长时间），等等。然后，代理负责为每次调用选择最好的提供者，从而免去了使用者这方面的责任。使用者每次都在同一地址调用同一代理，代理负责协调各个提供者。

　　图4展示了使用者如何使用Broker调用服务，工作方式如下：

　　·使用者向UDDI请求服务提供者列表。UDDI返回的URI实际上是服务代理的URI。UDDI只返回一个URI而不是多个URI，因为Broker只将一个代理用于特定的服务。
　　·使用者使用代理的URI调用服务。
　　·服务代理从其可用提供者列表中选择服务提供者。
　　·服务代理调用所选提供者的端点。

 

　　图4：同步代理服务调用
 
　　请注意，选择提供者的工作已经从使用者转走了，现在封装在Broker的代理中。这简化了使用者的工作。最后，代理使用的选择流程可能不同于使用者使用的选择流程。但是，因为UDDI服务器和代理都封装在Broker中，所以可以更容易地提高某些方面的效率，例如在代理中缓存信息、在缓存的信息变得过时让UDDI服务器通知代理。

　　还需要注意的是，因为代理的地址是稳定的，所以使用者不必重复地查询UDDI，每个服务调用只需查询一次。更确切地说，使用者只需查询UDDI一次，然后就可以安全地缓存代理的地址，并且重复地使用它来调用服务。这大大地降低了调用服务的开销。