企业服务总线

why使用esb(Enterprise Service Bus)

SOA 模型：服务使用者调用服务提供者出现的问题：
- 使用者如何找到它需要调用的服务的提供者
- 使用者如何快速而可靠地调用服务，而网络实际上很慢且不可靠

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

调用服务

调用服务的通信选择：同步或异步
同步与异步调用
使用者可以同步或异步实现服务调用。从使用者的观点来看，这两种方式的不同之处在于：
同步——使用者通过单个线程调用服务；该线程发送请求，在服务运行时阻塞，并且等待响应。

如果使用者在服务运行的过程中阻塞时崩溃了，当它重新启动时，将无法重新连接到正在进行的调用，所以响应丢失了。使用者必须重复调用过程，并且期望这次不会崩溃。

异步——使用者通过两个线程调用服务；一个线程发送请求，而另一个单独的线程接收响应。

如果使用者在发送了请求之后等待响应时崩溃了，当它重新启动时，可以继续等待响应，所以响应不会丢失。

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

同步直接调用

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

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

同步代理调用

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

同步企业服务总线

同步代理服务调用:

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

异步代理调用

同步方法的不足之处在于，在执行服务时使用者必须阻塞——在服务运行时线程必须阻塞。如果服务花很长时间执行，使用者可能会在接收到响应之前放弃。当使用者发出请求时，如果没有一个服务提供者正在运行或者它们都过载，则使用者将无法等待。如上所述，如果使用者在阻塞时崩溃，则即使它重新启动，响应也会丢失，因而必须重新进行调用。

调用服务的时候如果发生阻塞，调用者无法接收到返回值会一直等待，解决方法就是使用者可以使用一个线程来发送请求，而使用另一个线程来接收响应。

异步企业服务总线：

使用者以请求队列中的消息的形式发送 SOAP 请求
提供者接收到消息之后再以应答队列中的消息的形式发送 SOAP 响应

消息总线

异步企业服务总线的基础是已为大家接受的模式，称为消息总线 (Message Bus)，如参考资料中列出的 Enterprise Integration Patterns 一书所述。消息总线是消息通道（也称为队列或主题）的集合，通常配置为请求-应答通道对。每一对都表示使用者可以通过总线调用的服务。调用方将请求消息放在服务的请求队列中，然后（异步）侦听应答队列中的结果。（调用方知道哪个结果对于特定的请求是正确的，因为它有正确的关联标识符。）