《开发人员为何需要企业服务总线》由会员分享，可在线阅读，更多相关《开发人员为何需要企业服务总线（11页珍藏版）》请在金锄头文库上搜索。
1、本文内容包括： 引言 调用服务 其他集成功能 开发企业服务总线 结束语 参考资料 本文不仅仅是为架构师准备的：使用企业服务总线 (Enterprise Service Bus)，作为支持面向服务的体系结构 (SOA) 的基础架构，也将使开发人员能够更加轻松地工作。引言重要的应用程序很少是单独存在的；如果不能与其他的应用程序一起使用，应用程序将难以发挥很大的作用。面向服务的体系结构往往将应用程序集成在一起，这样它们就可以协同工作并提高工作效率，每个应用程序都分成必须相互集成的各个部分。SOA 模型服务使用者调用服务提供者可能看起来相当简单，但是它提出了两个重要的问题：1. 使用者如何找到它需要调
2、用的服务的提供者 2. 使用者如何快速而可靠地调用服务，而网络实际上很慢且不可靠？ 对于这两个问题，有一个相当简单的答案，即采用称为企业服务总线 (ESB) 的方法。ESB 处理使用者和提供者之间的所有复杂问题，从而使得服务调用对于两者都比较简单。ESB 不仅使应用程序（或其各个部分）可以更加容易地调用服务，而且还帮助它们转换数据和广播事件通知。ESB 的设计体现了许多已为大家接受的设计模式和标准规范。本文旨在帮助开发人员理解 ESB 的作用以及应用程序集成的必要部分（包括 SOA）。重点不在于定义或产品，而在于 ESB 实现的功能，这样您就不必自己实现这些功能。它展示了 ESB 可以为您做什
3、么。调用服务为了帮助您理解应用程序集成和 SOA，我将从介绍 Web 服务如何工作开始。 Web 服务只不过是您可以用来实现服务调用的一种方法。它们甚至可能不是最好的方法，但却是目前可用的最标准的方法，它们能够帮助我形成正在尝试完成的任务的设计。 首先，我必须解释相关术语。Web 服务非常类似过程性编程中的功能：它具有名称、参数和结果。名称就是 统一资源标识符 (URI)，通过 URI，Web 服务 提供者 使 Web 服务可以作为端点使用。Web 服务使用者将端点 URI 作为查找和调用 Web 服务的地址。使用者调用端点时会将请求传送到 Web 服务，请求中包含特定的操作和参数。在执行服务
4、之后，端点将 响应 传送回使用者，响应指示成功（或错误），并且包含服务的结果。通过这种方式，使用者可以调用提供者的端点，传入请求，并得到响应。目前，定义实现 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 响应。端
5、点的 API 是由使用者和提供者之间的约定描述的。既然您了解了相关术语，就让我们来看一看使用者用于调用服务的通信选择：同步或异步。同步与异步调用使用者可以同步或异步实现服务调用。从使用者的观点来看，这两种方式的不同之处在于： 同步使用者通过单个线程调用服务；该线程发送请求，在服务运行时阻塞，并且等待响应。 异步使用者通过两个线程调用服务；一个线程发送请求，而另一个单独的线程接收响应。 术语 同步 和 异步 经常与 顺序 和 并发 混淆了。后面的这两个术语与执行单独的任务必须遵循的顺序有关，而 同步 和 异步 与线程执行单个任务（如调用单个服务）的方式有关。理解同步和异步调用之间的不同的一种很好
6、的方法是考虑崩溃恢复的后果： 同步如果使用者在服务运行的过程中阻塞时崩溃了，当它重新启动时，将无法重新连接到正在进行的调用，所以响应丢失了。使用者必须重复调用过程，并且期望这次不会崩溃。 异步如果使用者在发送了请求之后等待响应时崩溃了，当它重新启动时，可以继续等待响应，所以响应不会丢失。 崩溃恢复不是同步和异步调用之间的唯一不同，但是如果您尝试确定某个调用采用哪一种方式，请考虑每一种调用如何处理崩溃恢复，这通常可以给您一个很好的答案。既然您了解了使用者对服务调用通信方式的选择，就可以看一看使用者对用于连接到提供者的连接方式的选择。使用者可以从下列通信方式中选择一种：1. 同步直接调用 2. 同
7、步代理调用 3. 异步代理调用 我将分别解释每一种方式。同步直接调用调用 Web 服务的 SOAP over HTTP 方式就是直接的：非常类似于执行函数调用，使用者知道端点的地址，并直接调用它。为了使调用成功，Web 服务必须在使用者调用端点时可用，而且必须在使用者超时之前进行响应。如果将 Web 服务部署到新的位置（例如不同的 Internet 域），则必须让使用者知道端点的新 URI。要部署具有相同服务类型的多个提供者，必须将每个提供者的端点部署到不同的 URI。要在不同的服务提供者之间进行选择，使用者必须知道其中的每个 URI。例如，考虑一个简单的用于获取股票报价的 Web 服务：使用
8、者传入股票代号，然后取回股票的当前价格。此服务可能由多个不同的代理公司提供，每个公司都有一个不同的 Internet URL。获取 Web 服务的 URL 是一个先有鸡还是先有蛋的问题。如果使用者知道端点的位置，它就可以询问服务其地址是什么，但是使用者需要知道地址才能询问地址。为了解决这个问题，统一描述、发现和集成（Universal Description Discovery and Integration，UDDI）描述了一种 Web 服务，它是一个类似于电话簿的目录，用于查找其他的 Web 服务。其思想就是，将 UDDI 部署到一个使用者已经知道的知名地址，然后使用者就可以使用 UDDI
9、 来查找其他的 Web 服务。对于股票报价服务，使用者知道 UDDI 服务的地址，而 UDDI 服务又知道股票报价服务的地址，如图 1 所示。图 1：直接调用 Web 服务图 2 展示了使用者如何使用 UDDI 服务来查找股票报价提供者的端点，并且调用其中的一个端点。该流程的工作方式如下：1. 使用者向 UDDI 询问服务提供者列表。 2. 使用者从 UDDI 返回的列表中选择一个提供者的端点。 3. 使用者调用该端点。 图 2：同步直接服务调用请注意，选择提供者的算法完全由使用者决定；在本例中，使用者只选择列表中的第一个。实际实现可能要复杂一些。还需要注意的是，因为服务端点可能改变，所以当使
10、用者每次需要调用服务时，都应该重新查询 UDDI，查看提供者的详细信息是否有改变。必须为每次服务调用查询 UDDI 大大增加了调用服务的开销，特别是在提供者的详细信息通常不改变的情况下。同步代理调用直接调用方法的不足之处在于，使用者必须知道提供者的端点的 URI 才能调用服务。它使用 UDDI 作为查找 URI 的目录。如果提供者更改其端点的 URI，它必须向 UDDI 服务器注册，这样 UDDI 就有新的 URI，然后使用者必须重新查询 UDDI 以获得新的 URI。事实上，这意味着每次使用者需要调用服务时，它都必须查询 UDDI 以找到端点 URI，并从中进行选择。这导致使用者把许多时间浪
11、费在重复查找 UDDI 和选择提供者这样的工作上。这种方法还使得使用者必须以某种方式从看起来不可区分的列表中选择提供者。简化这个问题的一个方法是引入 Broker，作为调用 Web 服务的中介。使用者不再直接调用服务提供者，而是调用 Broker 中的服务代理，而服务代理又调用服务提供者。使用者需要知道代理端点的 URI，以便使用 UDDI 查找地址，但是在本例中，UDDI 只返回单个 URI，因而使用者不必选择。使用者甚至没有意识到端点在代理中；而只是知道它可以使用此 URI 来调用 Web 服务。Broker 协调使用者与服务提供者，如图 3 所示。图 3：同步企业服务总线代理的 URI
12、应该是稳定的：在使用者使用 UDDI 获取代理的 URI 之后，它第一次调用服务，在以后的调用中，使用者可以重用该 URI（至少在代理停止工作之前）。同时，代理跟踪提供者及其 URI（可能在调用之间发生改变）、它们是否可用（上一次调用失败了吗？）、它们的负载（上一次调用花了多长时间），等等。然后，代理负责为每次调用选择最好的提供者，从而免去了使用者这方面的责任。使用者每次都在同一地址调用同一代理，代理负责协调各个提供者。图 4 展示了使用者如何使用 Broker 调用服务，工作方式如下：1. 使用者向 UDDI 请求服务提供者列表。UDDI 返回的 URI 实际上是服务代理的 URI。UDDI
13、 只返回一个 URI 而不是多个 URI，因为 Broker 只将一个代理用于特定的服务。 2. 使用者使用代理的 URI 调用服务。 3. 服务代理从其可用提供者列表中选择服务提供者。 4. 服务代理调用所选提供者的端点。 图 4：同步代理服务调用请注意，选择提供者的工作已经从使用者转走了，现在封装在 Broker 的代理中。这简化了使用者的工作。最后，代理使用的选择流程可能不同于使用者使用的选择流程。但是，因为 UDDI 服务器和代理都封装在 Broker 中，所以可以更容易地提高某些方面的效率，例如在代理中缓存信息、在缓存的信息变得过时让 UDDI 服务器通知代理。还需要注意的是，因为代
14、理的地址是稳定的，所以使用者不必重复地查询 UDDI，每个服务调用只需查询一次。更确切地说，使用者只需查询 UDDI 一次，然后就可以安全地缓存代理的地址，并且重复地使用它来调用服务。这大大地降低了调用服务的开销。异步代理调用同步方法的不足之处在于，在执行服务时使用者必须阻塞在服务运行时线程必须阻塞。如果服务花很长时间执行，使用者可能会在接收到响应之前放弃。当使用者发出请求时，如果没有一个服务提供者正在运行或者它们都过载，则使用者将无法等待。如上所述，如果使用者在阻塞时崩溃，则即使它重新启动，响应也会丢失，因而必须重新进行调用。解决这个问题的常见方法是使用者异步调用服务。通过这种方法，使用者可
15、以使用一个线程来发送请求，而使用另一个线程来接收响应。这样，使用者就不必阻塞以等待响应，而且可以同时执行其他工作。因此，使用者对花多长时间执行服务不太敏感。 支持使用者异步调用 Web 服务的 Broker 是通过消息传递系统实现的，消息传递系统使用消息队列来发送请求和接收响应。与同步消息代理一样，这一对消息队列担当使用者用来调用服务的单个地址，而不管多少提供者可能正在侦听，如图 5 所示。图 5：异步企业服务总线这种方法使用请求-响应模式来调用 Web 服务。与 WS-I BP 1.1 中指定的 HTTP 不同，消息队列现在执行传输。SOAP 请求和响应与 WS-I BP 相同，但是它们现在
16、包含在消息系统的消息中。图 6 展示了使用者如何使用 Broker 异步调用服务，具体步骤如下：1. 使用者以请求队列中的消息的形式发送 SOAP 请求。现在，使用者的工作已经完成了，可以使用该线程来执行其他工作。 2. 每个提供者都可以看到请求队列中的使用者，这使得它们要竞争使用者。消息传递系统确定哪一个提供者能够接收消息，并确保只有一个提供者接收消息。具体工作方式取决于消息传递系统的实现。 3. 获胜的提供者从请求队列接收消息。 4. 该提供者执行服务。 5. 该提供者以应答队列中的消息的形式发送 SOAP 响应。现在，提供者的工作已经完成了，可以使用其线程执行其他的工作（例如等待另一个请求）。 6. 使用者的侦听器线程接收包含 SOAP 响应的消息。 图 6：异步代理服务调用请注意，选择提供者的工作现在封装在消息传递系统中，从而简化了使用者的工作。还需要注意的是，如果使用者在发出请求之后崩溃，则即使响应在这个期间返回，消息传递
