异步代理调用

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

　　解决这个问题的常见方法是使用者异步调用服务。通过这种方法，使用者可以使用一个线程来发送请求，而使用另一个线程来接收响应。这样，使用者就不必阻塞以等待响应，而且可以同时执行其他工作。因此，使用者对花多长时间执行服务不太敏感。

　　支持使用者异步调用Web服务的Broker是通过消息传递系统实现的，消息传递系统使用消息队列来发送请求和接收响应。与同步消息代理一样，这一对消息队列担当使用者用来调用服务的单个地址，而不管多少提供者可能正在侦听，如图5所示。

　　图5：异步企业服务总线
 
　　这种方法使用请求-响应模式来调用Web服务。与WS-I BP 1.1中指定的HTTP不同，消息队列现在执行传输。SOAP请求和响应与WS-I BP相同，但是它们现在包含在消息系统的消息中。

　　图6展示了使用者如何使用Broker异步调用服务，具体步骤如下：

　　·使用者以请求队列中的消息的形式发送SOAP请求。现在，使用者的工作已经完成了，可以使用该线程来执行其他工作。
　　·每个提供者都可以看到请求队列中的使用者，这使得它们要竞争使用者。消息传递系统确定哪一个提供者能够接收消息，并确保只有一个提供者接收消息。具体工作方式取决于消息传递系统的实现。
　　·获胜的提供者从请求队列接收消息。
　　·该提供者执行服务。
　　·该提供者以应答队列中的消息的形式发送SOAP响应。现在，提供者的工作已经完成了，可以使用其线程执行其他的工作（例如等待另一个请求）。
　　·使用者的侦听器线程接收包含SOAP响应的消息。

　　图6：异步代理服务调用
 
　　请注意，选择提供者的工作现在封装在消息传递系统中，从而简化了使用者的工作。还需要注意的是，如果使用者在发出请求之后崩溃，则即使响应在这个期间返回，消息传递系统也会将响应保存在应答队列中，直到使用者再次启动为止。

　　同时需要注意，使用者不使用UDDI查找请求队列和应答队列。目前，没有用于返回队列地址对的标准服务，所以使用者必须确切地知道这些地址。使用者要么与这些地址硬编码在一起，要么从外部配置文件中读取它们。将来，需要扩展UDDI或者指定类似的服务供使用者查询，以便发现用于调用特定服务的队列对。

　　现在，您了解了服务调用的连接方式选择。接下来，让我们看一看也可能有用的其他集成功能，然后向您展示如何开发一个ESB来提供这些功能。

　　其他集成功能

　　使用ESB，您还可以超出服务调用，并且使用其他技术集成应用程序和SOA的各个部分。服务调用几乎始终是双向操作，这意味着请求是从使用者发送到提供者的，而响应是按照相反的方向返回的。其他的集成技术是以单向操作的方式进行工作的，其中，发送方将信息发送到接收方而不等待响应；接收方只是使用信息而不进行响应。

　　数据传输

　　有时，应用程序只需将数据传输到另一个应用程序，而不必调用接收方的过程，而且肯定不等待结果。这是一个典型的集成问题：一个应用程序有数据，而另一个应用程序需要数据。发送方不需要告诉接收方如何处理数据；它只需使数据可用即可。

　　可以通过服务调用来传输数据，这等同于调用setter方法，但是使数据传输到RPC范型中。数据传输实际上更类似于文件传输：数据从发送方导出并导入接收方，不需要发送方公开地指导接收方如何处理数据。这更类似于文档样式的SOAP消息而不是RPC样式的消息。

　　用ESB进行数据传输可以查找接收方，并可靠地传输数据。发送方不必知道如何查找接收方，它只需知道如何查找ESB并信任ESB将找到接收方即可。ESB还负责可靠地传输数据。发送方只需将数据传送到ESB并知道数据将传递即可。

　　有关数据传输技术的详细信息，请参见文档消息(Document Message)模式。（有关这方面的详细信息，请参阅参考资料中列出的Enterprise Integration Patterns一书。）

　　事件通知

　　有时，需要将在一个应用程序中发生的更改通知给其他应用程序。例如，如果使用者在一个应用程序中编辑其地址，则应该通知其他的应用程序以及它们自己的数据库，以便它们可以更新其记录。

　　此外，一个应用程序可以对另一个应用程序调用服务来通知其更改情况，但是这种方法有三个问题。头两个问题与数据传输相同。首先，服务调用对接收方应该如何处理信息知道得太具体了，其次，它往往是双向的，这使得发送方必须等待（甚至同步等待）它并非真正需要的应答。

　　通过调用服务进行事件通知的第三个也是最重要的是一个问题是，服务调用在本质上是一对一的，即使用者对提供者，而事件通知在本质上是一对多的，需要广播到所有相关提供者。使用服务调用，发送方必须跟踪所有相关的接收者，并且分别对其中的每一个进行服务调用。这种通知广播最好留给发送方和接收方之间的Broker。

　　用ESB进行消息传递可以跟踪相关接收方并确保通知传递到每一个接收方。通过这种方法，发送方只需发出一次通知，即可确保通知传递到所有的相关接收方，而不管这些接收方是谁。因为此操作是单向的，所以在传递通知时发送方可以同时做其他工作，而且可以并发传递通知。

　　有关数据传输技术的详细信息，请参见事件消息(Event Message)模式。（同时参阅参考资料中列出的Enterprise Integration Patterns一书。）

　　开发企业服务总线

　　现在，您知道了直接调用提供者中的Web服务和使用Broker进行调用之间的区别。您也了解了Broker如何支持使用者同步或异步地调用服务。

　　这样的Broker常常称为ESB。那么，与已为大家接受的设计和模式相比，ESB有什么特点呢？

　　自描述和可发现

　　Web服务与以前的集成方法的不同之处在于，使用者可以动态绑定到服务的提供者。之所以能够这样做，是因为具有以下两种主要功能：

　　·自描述——Web服务可以以机器可读的方式描述自身。同一服务的两个或更多提供者即使具有完全不同的实现也可以立即识别出来，因为它们的声明性接口符合相同的描述。
　　·可发现——Web服务提供者可以组织到机器可执行的目录中。使用者可以搜索这样的目录来查找所需服务的提供者。

　　这些自描述和自发现功能完全不同于以前的集成方法。使用其他方法，将在编译时执行接口，与此同时使用者将被绑定到提供者。消息格式不是以声明的方式表示的，而是暗含在双方的约定中，并且在接收方成功地解析发送方创建的结构之前是不可执行的。

　　自描述服务通过声明可以执行的接口简化了集成。动态发现服务使得不需要在特定的地址将使用者绑定到特定的提供者，但是运行时发现本身也带来了一些问题。使用者应该一次性地发现服务的提供者还是重复地发现服务的提供者？

　　在编译时一次性将使用者绑定到提供者与在运行时潜在地针对每次调用发现新的提供者之间作出取舍非常困难。ESB提供了第三种选择，承诺在支持使用者动态地一次性绑定到服务代理的同时，仍然能够通过代理使用多个提供者和选择新的提供者。

　　因此，ESB不仅使服务可用以便使用者能够调用它们，而且为使用者提供了以编程方式查找服务的功能。

　　服务网关

　　同步ESB的基础称为服务网关，它充当服务使用者和提供者之间的中介，以促进同步代理调用。通过服务网关，可以访问所有知名的服务和其中每个服务的代理。采用这种方式，网关可以为希望调用该网关代理的任何提供者的任何服务的使用者提供一站式服务。

　　如果网关协调的服务是Web服务，则这些服务是自描述的。每个服务都使用WSDL声明其接口，WSDL由以下四个部分组成：

　　·端口类型——Web服务执行的操作集。端口类型可能是带有端口/操作（如getQuote）的stockBrokerServices。
　　·消息——请求和响应的格式，例如getQuoteRequest（包含股票代号）和getQuoteResponse（包含价格）。
　　·类型——Web服务使用的数据类型，例如代号和价格（或者只是xs:string和xs:decimal）。
　　·绑定——调用操作的地址，例如http://stockbroker.example.com/getQuote。

　　这样的网关的服务——或者更具体地说，其服务代理——也是可发现的。如前所述，网关以UDDI服务的形式提供这种功能。要发现调用服务的地址，使用者可以查询网关的UDDI服务，以找到所需WSDL操作的提供者，并取回该操作的网关代理的绑定。

　　消息总线

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

　　调用服务的使用者实际上并不知道谁在提供服务。服务提供者也连接到消息总线，并侦听请求消息。如果有多个服务提供者，则它们实际上将相互竞争，以便成为发出特定请求的使用者的服务提供者。实现消息总线的消息传递系统充当消息调度程序，并且将请求消息分发给服务提供者，在理想情况下，将根据负载均衡、网络延迟等以某种方式优化这种分发。在服务提供者接收请求之后，它执行服务，然后将结果放在达成一致意见的应答通道中的消息内。这样，提供者和使用者从不直接知道彼此的地址；它们只知道消息总线和如何查找适当的通道的地址，而且通过共享相同的通道，它们可以进行通信。

　　消息总线是ESB的基础，并且不是什么新鲜事物。应用程序集成人员已经使用消息队列产品（如WebSphere? MQ和TIBCO Enterprise Message Service）做这项工作十多年了。其实，人们常说，如果您正在使用企业消息传递产品，您就有了ESB。IBM客户已经使用WebSphere Business Integration Message Broker和WebSphere MQ这样做了很长时间。

　　那么，ESB就是消息总线吗？不，消息总线肯定是异步ESB的基础，但完整的ESB还包括其他的功能。ESB具有消息总线一直缺少的功能：即上述描述和发现功能。

　　更好的消息总线

　　如此说来，如果消息总线不是完整的ESB，那么ESB还可以做什么呢？

　　传统消息总线方法的不足之处在于，它不是自描述的。从使用者的角度来看，有许多服务，也有许多用于调用服务的通道。但是哪一个通道是用来调用使用者所需的服务的合适通道呢？使用者不能将请求随便放到一个请求通道中，它必须知道用于调用其所需的特定服务的合适通道。否则，它可能事与愿违，明明需要的是一本书，但最后买到的却是一张飞机票。另外，即使使用者（以某种方式）知道了要使用哪一个通道（以及要侦听哪一个通道以获得应答），它也需要知道请求中的数据应该采用什么格式（以及应答需要采用什么数据格式）。

　　如上所述，WSDL为同步Web服务解决了这个问题，并且暂时也是描述异步服务的标准选择。与请求通道相关的WSDL描述通道提供什么服务，以及使用者必须提供的请求消息的格式。WSDL还可能指定调用方应该侦听以获得应答的应答通道，以及应答消息必须具有的格式。采用这种方式，调用方应用程序可以以编程方式查看用于调用服务的通道对，并且知道它们以所要求的请求和应答消息格式提供了所需的服务。

　　自描述服务通道带来了另一个问题，即通过UDDI发现哪些同步Web服务。如上所述，使用者向UDDI服务器请求Web服务提供者的地址，而该服务器以提供者的URL应答。然后，使用者使用该URL来调用该服务。

　　ESB需要类似的目录服务，一个带有类似于UDDI的API的服务，使用者可以调用这样的服务，来请求实现所需的WSDL操作的服务的地址。ESB以合适的请求-应答通道对应答。所以ESB使用者（如UDDI使用者）只需知道以下内容即可：

　　·描述需要调用的服务的WSDL

　　·ESB的目录服务的地址（它可能派生于ESB的根地址）
对于查找服务的请求与应答通道和开始调用服务，这足够了。此外，这个目录服务还是 ESB 提供的另一个服务，查找其他服务的主服务。

　　同步还是异步？

　　服务使用者需要在通信方式之间做出选择：同步还是异步？为了解决这个难题，许多ESB将同时支持同步和异步服务，并且事实上可以为同一服务提供两种调用模型。在这种情况下，当使用者请求服务地址时，它可以获得两个匹配地址：一个用于同步，一个用于异步。然后，使用者可以选择它最喜欢的调用模型。不管采用哪一种方式，执行的服务都是相同的，不过具体的服务提供者实例可能有所不同。

　　所以ESB比传统的消息总线要好，因为它还使得服务可以自描述，并且提供了用于查找其他服务的目录服务。这正是构建ESB的产品供应商努力提供的。

　　结束语

　　可以看出，服务可以通过以下三种方式之一进行调用：

　　·直接同步
　　·通过Broker同步
　　·通过Broker异步

　　企业服务总线是支持同步和异步调用的Broker。它还支持应用程序之间的数据传输和事件通知。它帮助使用者查找提供者和处理提供者之间的通信的细节。

　　同步ESB是充当各种服务的中间协调者的服务网关。异步ESB是其服务还支持自描述和可发现Web服务功能的消息总线。目前存在用于实现同步ESB和消息总线（简化的异步ESB）的标准和模式。异步ESB还需要其他标准，以便充分发挥他们的潜力。

　　关于作者

　　Bobby Woolf是IBM Software Services for WebSphere(ISSW)的一位WebSphere J2EE顾问。Bobby使用WebSphere Studio Application Developer来帮助客户开发WebSphere Application Server的应用程序。他与别人合著了Enterprise Integration Patterns和The Design Patterns Smalltalk Companion。他在IBM developerWorks Web站点上建立了一个称为J2EE in Practice的博客。Bobby经常在会议上演讲。