JBI学习笔记

   二．关于标准提出的背景(EAI 和 B2B 的若干问题)以及ESB

假定现在已经按照SOA的思想提炼出了各种业务服务，公布出来，同样，你发现其他很多人也做了同样的事情。大家都很振奋，开始踊跃的尝试，我调用你的一个服务，你调我的一个服务。啊哈！大家都SOA了。且慢，那么这个SOA给你们带来了什么好处呢？Ok，现在我可以在J2EE环境里调用.Net的组件了，但是原来没有SOA的时候也可以做到的呀。只要两个节点之间互相认可对方的方式，即使不存在公开/统一的服务界面也可以实现点到点的互联。因此我们不得不承认，如果我们只有服务，而服务的请求者和服务的提供者之间仍然需要这种显式的点到点的调用，那么这就不是一个典型的SOA架构。请看图二，服务的参与双方都必须建立1对1 的联系。这样一个结构与我十几年前的那种互联的方式何其相似！但是，还记得我们上面提到的SOA三个基本要素吗？显然第三点没有做到。

EAI的目标是支持对现有IT系统的重新利用，通过EAI技术能够将不同的软件和系统串联起来，延长这些应用系统的生命周期。传统的EAI，往往使用如CORBA和COM等的消息中间件进行分布式，跨平台的程序交互，修改企业资源规划以达到新的目标，使用中间件、XML等方法来进行数据分配。因此，实际上传统的EAI是部件级的重用。很不幸的是，基于部件的架构没有统一的标准，因此，各个厂商都有各自不同的EAI解决方案，你会看到各种各样的中间件平台。如果EAI碰到了异构的IT环境，就必须分别考虑怎样在各个不同的中间件之间周旋，来实现合理的互联方式，你不得不考虑各种复杂的可能性。因此，你所见过的大多数传统EAI解决方案都比较笨重。

再回顾一下我们上面介绍过的SOA的应用场景：复杂的企业级架构。如果我们选择Hub的模式来构建SOA基础架构，从纯粹逻辑的角度，可能会出现哪些问题呢？首先，整个SOA架构的性能，如果每个服务的请求都经过中央Hub的中转，那么Hub的负担会很重，速度会随着参与者的增多而愈来愈慢；其次，这样的系统会很脆弱，一旦Hub出错，整个SOA架构都会瘫痪；最后，这样的架构会破坏SOA的开放性原则，参与者运行在一个相对封闭的环境中，扩展起来十分麻烦。因此，这也不是理想的SOA架构。

好了，现在该ESB登场了:

它与前面的Hub结构有什么不同呢？首先，它比单一Hub的形式更开放，总线结构有无限扩展的可能；其次，真正体现了SOA的理念， 一切皆为服务，服务在总线(BUS)中处于平等的地位。即使我们需要一些Hub，那么它们也是以某种服务的形式部署在总线上，相比上面的结构要灵活的多。这就是ESB，我们需要给它一个明确的定义：ESB是一种在松散耦合的服务和应用之间标准的集成方式。它可以作用于：

l         面向服务的架构 -分布式的应用由可重用的服务组成

l         面向消息的架构 - 应用之间通过ESB发送和接受消息

l         事件驱动的架构 - 应用之间异步地产生和接收消息