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以轻量级著称，它是基于实际需求的整合问题而设计实现的。它能轻松的与目前的系统进行整合，而且很容易进行再扩展。它标榜能够解决一切信息孤岛问题。用一位同事的话来形容：Mule就是一个大杂烩，它里面什么都有，所以能够完成各种格式数据的转化；
Jboss ESB比较重量级，它必须部署到Jboss的应用服务器中，而且它主要专注于与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的话，无疑会降低系统的性能，这些在系统架构，必须考虑进去。