轻松实现企业服务总线
轻松实现企业服务总线（ESB）
声明：如果笔者的文章哪里引用了您的语句，请通知笔者(alisd)。
前序
什么是SOA？
这里引用某ibm专家提出的以下部分概念：
关于SOA的概念，你可以找到很多的文章从不同的角度来描述它，不同的软件提供商也有不同的定义方式。BEA有流体计算，微软有Indigo 和SOA-building， SAP有ESA。 每个人都可以从不同的视角来理解SOA，从程序员的角度，SOA是一种全新的开发技术，新的组件模型，比如说Web Service；从架构设计师的角度，SOA就是一种新的设计模式，方法学；从业务分析人员的角度，SOA就是基于标准的业务应用服务。从概念的角度，IBM对SOA的定义是最为全面的，既SOA是一种构造分布式系统的方法，它将业务应用功能以服务的形式提供给最终用户应用或其他服务。
SOA包括如下要素:
• 一个体系架构，用开放的标准将软件资产(Asset)化为服务
• 提供标准的方法来表示软件资产及其交互
• 单独的软件资产作为构造单元，被重复使用来开发其他应用
• 将关注点从细节实现转移到应用(application)组装
• 整合企业外部的应用（B2B）的方式
• 开发（现在）和整合（未来）的统一
从软件开发人员，站在开发人员的角度，往往希望软件开发能够满足对于开发效率、可靠性、易维护性、易管理等多方面的更高要求。
让我们通过回顾软件开发的演化过程来看一看SOA出现的必然性：
• 面向机器语言(Monolithic)的开发模式：需要根据不同平台的机器语言来开发代码。
面向过程(Procedure)的开发模式：独立于机器的程序语言(C, Pascal等)使开发过程变得简单了，用过程来代表一个抽象的代码集合，包装重用现成的代码。
• 面向对象(Object)的开发模式：用更接近现实的对象来表述一个相对完整的事物。面向对象的开发强调从现实世界问题域到软件程序的直接映射，更接近人类的自然思维方式。
面向组件(Component)的模式：随着软件开发规模的扩大，在涉及分布式、异构等复杂特征的环境中，代码级别的重用性差，可维护性差，效率低的弱点是不可逾越的，因此人们以架构运行环境(如.Net，J2ee等)来提供完善的支撑平台，从而把开发者解放出来，更专注于业务核心的开发。而这些业务功能(Business Function) 以组件的形式(DCOM， EJB等)发布运行在架构运行环境中。软件开发的重用模式也上升到业务组件的级别。
• 面向服务(SOA)的模式：当软件的使用范围扩展到更广阔的范围，往往会面对更加复杂的IT环境和更加灵活多变的需求。服务(Service)的概念出现了，人们将应用(Application)以业务服务(Business Service)的形式公布出来供别人使用，而完全不需要去考虑这些业务服务运行在哪一个架构体系上，因为所有的服务都讲着同样的语言。SOA考虑了业务发展的长期性，体现了"变化就是永恒"的思想。SOA的核心体现在企业应用或者业务功能上的"重用"和"互操作"，而不再把IT与业务对立起来，这可以被视为在IT驱动业务的方向上迈出的重要一步。
我们注意到，SOA同样也强调重用(Reuse)， 但是相对于传统的代码重用，对象重用，和部件重用，SOA的重用粒度更粗。SOA的重用在于业务级的应用，即服务的重用，这与软件的发展规律是相一致的。
什么是ESB？这里引用某ibm专家提出的以下概念：
ESB全称为Enterprise Service Bus，即企业服务总线。它是传统中间件技术与XML、Web服务等技术结合的产物。ESB提供了网络中最基本的连接中枢，是构筑企业神经系统的必要元素。ESB的出现改变了传统的软件架构，可以提供比传统中间件产品更为廉价的解决方案，同时它还可以消除不同应用之间的技术差异，让不同的应用服务器协调运作，实现了不同服务之间的通信和整合。从功能上看，ESB提供了事件驱动和文档导向的处理模式，以及分布式的运行管理机制，它支持基于内容的路由和过滤，具备了复杂数据的传输能力，并可以提供一系列的标准接口。
我的esb概念：
我想这里就不用再具体的介绍了吧。
关于esb的文章很多，各种各样的说法，五花八门的，但都大同小异。
这里esb的主要组建模块包括以下：
l 开放的传输协议，仅仅包括实现jms、ejb、web service三种；
l 转换器，可以简化到类型的转换；
l 过滤器，同样包括基本的基于xpath的过滤和类类型的过滤而已；
l 服务持久化，可以通过数据库注册服务来保存服务提供者提供的服务，同时对服务可以进行治理；
l 传输器，这里实现了内部的数据传递和外部的数据传递内部主要包括jms和webservice两种；外部就是简单的给予socket的tcp协议的数据传递而已。
l 适配器，这里仅仅是服务消费者来绑定对应的服务把数据传递到esb的对外暴露的服务提供者接口（spi）。可以理解为服务消费者的调用服务的接口。这里用jms、ejb、web服务来实现很easy。一般独立在服务消费者一端。通过三种协议可以轻松的把数据发送的esb上。即通过运行在jboss的esb来监听消息。例如：实现了ejb的MessageDrivenBean接口和jms的MessageListener接口就是所谓的消息驱动bean（mdb）。
l 服务提供者（spi），这里主要是接受适配器发送过来的数据通过esb的client传递到传输器内部进行传递数据。在传递的过程中从服务持久化中读出服务的信息来路由到指定的服务地址。
l 应用服务器，默认指定jboss；
l 消息服务器，默认指定jboss；
基于实现简单的esb的组建有以上构成。其中各个模块可以称其为“组建”；他们之间并没有实现sca和sdo规范但是它完全是给予soa架构设计的和eip模式的实现。顾笔者称其为最简化esb的实现。
服务之间有9中传输方式jms、ejb、web服务*3=9种方式调用，完全满足了给予j2ee的应用系统的业务集成。
这里并不是只基于异构系统的企业业务集成。方案之一是采用基于消息的数据传递的企业集成模式。目前开源Apache activemq5.3已经出来了。完全实现jms1.1规范，而且提供了大量的消息策略和提供消息桥接存储和路由的联邦体系。
这里模拟一个场景：
需求如下：
质检局的质量检查系统需要某个的单位的注册信息，其实质检局完全可以自己申请再开发一个单位信息系统，然而，这样浪费大量的资源以及更不能办公一体化。为了达到这个目标质检局需要从工商局的信息库里获取信息。
根据以上功能划分完全可以满足该需求。
1) 我们把工商系统的部分功能（即：质检系统调用工商系统的接口操作的具体实现）发布成jms服务、ejb服务、web 服务三种服务。这里的web服务可以采用xfire、axis2、cxf其中一种即可。Ejb目前包括ejb2和ejb3.jms仅仅用支持jms1.1规范即可，可以自己实现也可以采用第三方的。
2) 把上面的三种服务注册到数据库中（即服务的持久化）。
3) 部署第一步发布的服务，首先，ejb、jms服务必须依赖于容器，例如jboss等。而web服务仅仅需要servlet容器即可，例如tomcat等。
4) 不是esb server，它肯定是部署在应用服务器的，如果贵公司没有自己的应用服务器，那么不想花钱，则使用jboss，它是目前开源比较好的应用服务器。默认部署在jboss上。
5) 开始调用服务了，质检系统嗲用适配器来把数据传递到esb server的服务提供者（spi）。即通过java代码调用适配器的API即可。这里的适配器主要是如何把数据传递到另一台主机上。默认使用jms，ejb，webservice三中方式都可以把数据传递到远程主机上（部署esb server的机器）。
6) 测试。这里声明一点：jms一般不需要返回参数，因为jms的应用都是使用它的异步消息传递。
以上关于esb的实现和应用也是目前笔者从事的方向。希望得到您的指教。