智能路由——ESB

SOA之我见

SOA已然是企业级开发的必定之路。有人会问：我们有了OOP，还须要SOA吗？好吧我承认，这个问题也困扰了我非常久。现现在我得出的结论是：OOP是OOP，SOA是SOA。

OOP是指面向对象程序设计。是指程序开发中的编程思想或者是编程设计方法。它的产生是为了弥补面向过程开发的缺陷，用现代人的思维方式编敲代码的方法。

SOA（面向服务的体系结构Service Oriented Architecture）是大型分布式系统的架构模式，它让架构师站在了一个全新的角度理解企业级架构的开发。

SOA本质上是一种架构模式，它与面向对象相比，它是一个粗粒度、松耦合的组件架构模式。它的产生，也是随着生产关系的变化，不适应生产力发展的须要。

面对公司陈旧的老系统，能够用一个词来形容鸡肋（食之无味，弃之可惜）。

企业是要生存的，不可能全然丢弃老系统，去开发一个全新的系统。况且在新的系统，也会变成将来的老系统。推倒重来，不是一个长久的解决的方法，正途是须要与老系统进行整合。这样，SOA就登场了。

那么OOP与SOA的关系，你可能也有点儿明确了。SOA的内部实现。可能会使用OOP实现，但这不是肯定的。SOA内部全然能够採用其它设计方法进行实现。所以OOP关注的是程序设计层次。SOA关注的是架构模式层次，它希望通过服务化，来实现系统集成，解决信息孤岛。

ESB

谈了这么久的SOA。那么什么是ESB呢？ESB是SOA的重要实现手段。

         

大家应对各种各样详细的需求。也就对SOA有了行业性的理解，结果就是现现在各种各样的ESB产品。这些ESB都致力于解决各行各业的问题。

ESB的表现形式尽管有非常多，可是从宏观作用上来讲是一致的。

它能实现于各系统见的协议转换、数据装换、动态路由功能。

我也仅仅是接触过几个ESB的产品：Mule ESB、Jboss ESB以及Shuttle ESB。关于再详细的关于ESB的东西。我也仅仅能是谈下自己的理解。由于这些产品，功能各异，側重的实现不一。

Mule ESB以轻量级著称。它是基于实际需求的整合问题而设计实现的。它能轻松的与眼下的系统进行整合，并且非常easy进行再扩展。它标榜可以解决一切信息孤岛问题。用一位同事的话来形容：Mule就是一个大杂烩，它里面什么都有，所以可以完毕各种格式数据的转化；

Jboss ESB比較重量级，它必须部署到Jboss的应用server中，并且它主要专注于与Jboss产品的整合。

Shuttle ESB是.NET平台基于事件的项目。

这是一个比較新的开源项目。我眼下项目中，就负责这一块的开发与研究。

我会在后文中。着重介绍Shuttle ESB在我们项目中的应用。

与此同一时候，我在网上也找了一些资料，也看了非常多官网，发现大家都说的都有道理，并且它们都是致力于不同行业问题的不同解决方式。总结起来。ESB主要起到例如以下作用：

使系统更便于扩展，添加系统灵活性

如上图所看到的，这就是ESB的基本思路的一种实现。

不管是系统内部的服务调用，还是系统间的调用。都会走ESB这条服务总线。不管哪一个系统，都之和ESB有关系，减少系统间的耦合性，便于系统的功能扩展。

这里发挥的是ESB强大的连通性。整合老系统也是应用了该思想。这个消息通道，也是一个服务中介，为各系统提供基础的服务支持。

这么看来，似乎ESB应该是统一的，不应该有那么多产品的出现，实则不然。

实际需求中，业务逻辑是复杂的，一种ESB产品内不可能包括对每一个系统都通用的服务。

详细到消息、事件，详细实现也不可能做到面面俱到。

服务编排

多个服务进行编排形成新的服务。

ESB支持一个直观形式定义新服务的流程。SOA有两个核心组件：一个是ESB。一个是BPEL。ESB是基础设施，BPEL是业务流程驱动下服务的集成与整合。离开SOA。ESB将失去全部连接的服务，而不过一个总线。Bobby做过一个比喻：路是没有不论什么价值的，除非你利用它把一个东西从一个地方一道还有一个地方。离开SOA，ESB就像一个没人通行的道路。

架构设计的考虑

ESB作为一条总线。插入系统之中。所以，就要求ESB具有无状态。高吞吐量的特点。

所以，怎样给ESB减肥，也是一款成功产品在架构设计中，必定要考虑的问题。

只是，ESB的使用，要注意系统的性能问题。记得GXPT项目中，系统间的通信採用的是Webservice，Webservice的效率就已经非常低了，中间再走一层ESB的话，无疑会减少系统的性能，这些在系统架构。必须考虑进去。