EAI Bridges简介

作为2011年9月份Service Bus 的一部分，我们添加了一组全新的EAI（企业应用集成）功能，包括bridges（通常称为管道）、转换和混合连接。我们将通过一系列的博客文章来介绍这一整套功能，在讨论EAI bridges之前让我们先了解一下它的基础概念。这篇文章将阐述建立bridges的必要性并演示了怎样配置和部署一个简单的XML bridge，通过它发送消息。

“bridge（桥）”这个词让我们马上想到了用来连接两个端点的一个东西。在信息系统中，我们用bridge来连接两个或多个完全不同的系统。让我们借助一个简单的例子来更好地理解这一概念。假设在一机构里，新员工入职或雇员的信息改变（例如银行账户）的时候，员工管理系统和HR系统与工资管理系统之间要进行交互。员工管理系统和HR系统可能是完全不同的系统，例如，可以是在SQL、 Oracle、 SAP 中，等等。

这些系统与工资管理系统（通过交换消息）要以一种它们能理解的格式进行交互。工资管理系统是一个独立的单元，我们能够使用第三方基础架构来实现它。这些系统要以一种能够继续使用他们各自的消息格式但仍能相互沟通的方式来实现互相连接。每当工资管理系统接收到来自其它两个系统的消息，它将执行一套共同的操作。可以将这组操作整合成一个普通的单元，我们称这个单元为bridge。

为什么使用Bridge？

桥接协议

假设有这么一个情形，application1想与application2进行交流。然而application1只使用REST/POX协议发送消息，而application2只能通过SOAP协议接收消息。要实现这一目标，其中的一个application需要以一种其它application能理解的格式进行交流，这是要付出一定代价的，在大多数的情况中是一个不能被接收的解决方案。我们使用一个bridge作为中介物，问题就解决了。这个bridge通过REST/POX协议接收消息，使用SOAP协议发送消息。一个bridge有效正确地连接了两个及以上使用不同协议的应用程序。

结构规范化或合同数据转换

下图中，左边的应用程序正在以一种特殊的结构发送消息。接收应用程序以另一种结构接收同一数据。在这当中要变换数据的结构，以便他们可以相互通信。Bridge能够帮助我们实现结构规范化（或转换）。

我们可以将这种情形引申至多个不同的应用程序正向某一应用程序发送消息的情形。接收应用程序或进程可以预先建立一个bridge，将所有传入的消息规范化为一种它能理解的通用的格式，响应消息的过程也是如此。此过程通常被称为规范化。

消息/合同验证

假设有这样的一种情况，有一个进程或应用程序希望只允许那些符合一种或几种格式的消息进入并拒绝所有不符合条件的消息。要达到这个目标可能需要编写复杂且代价大的验证逻辑。使用EAI bridge，一些基本的配置步骤就可以实现了。该bridge可以针对一个或多个模式验证所有收到的信息。仅当该消息符合所提供的模式之一，该消息就被发送给应用程序。否则，它将被驳回并发送相应的响应消息到发送端应用程序/客户端。

基于路由选择的内容

很多时候我们看到应用程序需要基于消息的元数据/上下文将消息路由到另一个应用程序。例如，在贷款处理过程中，如果贷款金额>$10,000，将消息发送到application1，否则发送到application2.这种基于路由的内容可以通过bridge实现。Bridge通过对传出元数据使用简单的路由规则来实现这一点。该消息能够被发送到任何端点或应用程序，不论是在云上或是在非云端。

虽然我们单独讨论了上面的每个功能，实际上它们很少单独发生。你可以将上面的情况与其他的情况结合起来使用一个或多个EAI bridge。Bridge也可以被链接或根据客户的要求并行使用，或实现模块化和增强易维护性。

配置、部署和代码

注册Service Bus账户并订阅

在开始使用EAI bridge之前，你需要先在Service Bus portal里注册一个Service Bus账户。你需要使用一个Windows Live ID (WLID) 登录，它将与你的Service Bus账户相关联。一旦你完成了这些，你就可以创建一个新的Service Bus Subscription。以后，每当你登录该WLID，你可以访问与该账户相关的所有Service Bus Subscriptions。

创建一个命名空间

一旦你拥有了适当的Subscription，你可以通过创建一个新的且在所有Service Bus账户里唯一的命名空间。每个service命名空间都是一组 Service Bus实体的容器。当你创建名为“Harish-Blog” 的service命名空间时，其界面如下。

关于账户设置和命名空间创建的更详细的资料可以在12月发布的版本的CTP所附带的用户指南里找到。

配置和部署bridge

可以使用Microsoft Visual Studio所提供的一个简单用户界面设计器来配置bridge。在这之前要从这里下载SDK。安装SDK后，在Visual Studio里创建一个新的EAI项目，你可以在Visual C# -> ServiceBus下找到它。接着按照这里(XML 单向 Bridge)或这里(XML 双向 Bridge)所提到的步骤一步步地配置并部署bridge。

下面的截图展示了单向bridge（bridge1）连接到一个Service Bus队列（Queue1）、Service Bus 中继器（OneWayRelay1）和托管在云里的单向service（OneWayExternalService1）。当该bridge接收到一条消息，该消息将被加工并路由到这3个端点之一。

下图展示了请求-响应bridge所包含的不同阶段并且说明了bridge可以被配置的位置：

向bridge发送消息

在配置和部署bridge之后，你可以向它发送消息了。你可以使用一个简单的web client或WCF client向bridge发送消息。你也可以通过REST/POX 或 SOAP向其发送消息。作为示例下载的一部分，我们也提供了一些可以用来发送消息的示例client。在这里下载示例以使用现成的client发送消息。

总结和请求反馈

希望这篇文章能够帮助你们快速地了解Service Bus 12月份发布的CTP的EAI bridge的功能。我们在这里提到的只是冰山一角。在将来的博客中我们将深入地介绍这些功能。

最后，我们发布CTP的主要目的之一是获得其服务和功能的反馈信息。对于这些集成的功能，我们想听听您的意见。特别地，我们想知道您对bridge的配置和部署体验的看法，我们所提到的其他的功能只是它的一部分。

您可以在我们的实验室论坛上提供建议、批评、赞美意见或者提出问题。您的反馈将帮助我们为您和其他用户改进我们的服务。

本文翻译自：http://blogs.msdn.com/b/windowsazure/archive/2011/12/20/an-introduction-to-eai-bridges.aspx