【ESB专题】－面向消息的EAI的关键组件 企业应用虚拟机中间件设计模式工作

<!----><o:p> </o:p>

企业集成有很多种模式，随着技术的发展，实时的、面向消息的企业集成越来越成为主流，面向消息的企业集成的稳定性和兼容性要求其基础件，也就是message系统必须提供足够强壮和可扩展的设计，下面几种是作为面向消息的企业集成的基础件所必须提供的几个关键性组件。

<o:p> </o:p>

消息集成使得message系统负责转换两个应用之间的数据格式，从而使得应用可以专注于他们需要共享什么数据而不是如何共享它们。

<o:p> 
</o:p>

<o:p>以下这些组件，在著名的ESB系统Mule中都可以见到，有兴趣的同学可以去看看Mule的源代码，虽然Mule对ESB的实现有很多不成熟的地方，以至于让我不敢在生产系统中使用（唉...可恨的Mule），但是毕竟是一个大而全的系统，值得借鉴一下。
 </o:p>

Channels — Messaging应用通过一个Message Channel传送数据，一个sender到receiver的虚拟管道。一个新安装的消息系统默认不包含任何channel；你必须知道你的应用需要怎样通讯，然后才能建立channel来完成它。

<o:p> </o:p>

Messages — Message是在channel上传输的不可分割的包。因此，为了传输数据，应用必须将数据打包成一个或多个packets，将每个packet包装成一个message，然后将其传输到一个channel。同样的，一个receiver应用在接受到message后必须从message中提取出数据才能使用。Message系统应该能重复的传输message，直到它成功为止。

<o:p> </o:p>

Pipes and Filters — 最简单的情况下，message系统将一个消息直接从sender计算机传送到receiver计算机。然而，通常在消息从sender中发出后，receiver接受到之前，有一些动作需要对message执行。举例来说，message也许需要验证或者转换。Pipes and Filters架构使用channel将多个处理步骤连接起来。

<o:p> </o:p>

Routing — 在一个大型的、拥有许多不同的应用和channel连接的企业应用中，一个message可能需要穿过多个channel才能到达最终目的地。Message的路由如此复杂以至于最初的发送者无法知道那些channel能将message传送给最终的receiver。因此，最初的发送者将message发送给一个Message Router，一个以Pipes and Filters架构中的filter形式存在的应用组件。Router将决定如何将message发送到最终receiver或者至少是下一个Router。

<o:p> </o:p>

Transformation — 不同的应用的数据格式可能不同。为了调节sender和receiver之间的数据格式不同的问题，message必须经过一个中介的filter，一个Message Translator，它将message从一个格式转换成另外一个格式，或转换成一个公共的格式。

<o:p> </o:p>

Endpoints — 大多数的应用程序没有内建的能力来同一个message系统交互。因此他们必须包含一个中间层，它知道应用系统如何工作，也知道message系统如何工作，并桥接两个系统。这个系统是一组并列的Message Endpoints，它能够使得应用发送和接受message。

<o:p> </o:p>

System manager － 作为一个大型的消息集成系统，其面向消息的、异步、低耦合的本质使得系统更加难以调试，运行期的状态也难以跟踪，所以，我们必须有强有力的手段进行系统的运行期管理和监控，同时最好能够在运行进行动态更新，以保障系统的强壮性。


企业应用集成是一个巨大而复杂的系统，作为其基础件ESB系统，必须能够提供对其完全的支撑以及足够强壮的系统，这正是ESB系统建设的难度所在。