ESB技术演变.docx

在企业信息化进程的最初，一个应用软件的使用范围可能仅限于某一个部门或某一种业务，由此而导致的情况是：一个大型的企业可能存在多个大小不一且支撑技术不同的应用软件系统，这些系统可能基于不同的编程语言，运行在不同的硬件上，有着不同的系统平台。但随着企业的壮大，业务的发展，部门和部门之间的关键路径和业务接口逐渐增多，各个应用软件之间的信息交互也越发频繁，同时，企业与上下游合作伙伴之间，数据共享、流程整合的需求也不断催生，在这样的背景下，企业应用集成软件应运而生。至今为止，企业集成软件的发展，可以分为三个阶段：
基于标准协议的代码定制
这是最初出现的集成软件。一个业务系统和另一个业务系统直接通话，业务接口采取定制代码的方式，通过一些标准的协议，例如Http、Ftp等，紧密的集成在一起。这种集成方式的缺陷不言而喻：缺乏可靠的数据传输保障；系统毫无弹性可言；数据交换时双方必须同时在线；部署模型是非常复杂混乱的网状结构等等。

基于消息的代码定制
基于消息的异步编程模型，则为企业集成提供了一种新颖的解决方案。传统的消息中间件，能够有效解决数据传输的可靠性、稳定性与安全性，并且，消息提供的异步编程模型，避免了集成双方必须同时在线的问题，于是，人们在原先方式中的数据载体由通过标准协议，换成基于消息，大大提高了数据的可靠性，以及部署上的分布性。但是缺点还是同样明显：路由逻辑和业务逻辑没有分离，系统基本没有扩展性，部署上还是网状结构等等。

集线器模式
集线器模式在基于消息的基础上，引入了“前置机-服务器”的概念，使用一种集线器/插头（hub-and-spoke）的架构，将消息路由信息的管理和维护从前置机迁移到了服务器上，巧妙的把集成逻辑和业务逻辑分离开来，大大增加了系统弹性。由于前置机和服务器之间不再直接通信，每个前置机只通过消息和服务器之间通信，将复杂的网状结构变成了简单的星型结构。

集线器模式在企业集成的过程中取得了很大的成功，但是集线器模式的模型自身存在不足：中央服务器的存在导致部署上无法分布开来，同时，中央服务器承担了太多的工作和责任，往往会带来压力瓶颈以及硬件投资上的巨额付出。随着基于集线器模式的EAI系统的广泛使用，更多的不足逐渐暴露出来：
1、集成的各方之间, 依然是一种紧密耦合的方式，一方所暴露的业务接口，只能在当前的集成环境下使用，无法提供可复用的业务价值。
2、业务系统之间的协议都是基于消息的，有时候很难跨越企业的防火墙。
3、当集成的需求越来越多的时候，不断添加的功能使得集成系统日趋庞大，缺乏灵活性且难于管理。
那么有没有一种更好的架构可以解决这些问题，并且能够在完成企业集成的同时，带来更大的业务价值？
当人们正在为集线器模式的企业集成架构所表现的不足寻求解决方案时，SOA的思想被提出来了。
划时代的体系思想：SOA
SOA（Service-Oriented Architecture），指的是面向服务的架构，意指将软件按照功能设计成一个个独立封装、支持异步处理的服务，这些服务用标准的方式定义接口，并可以通过标准的协议进行调用。重要的一点是，SOA所定义的接口和调用方式是独立于编程语言和运行平台的。

SOA的思想试图定义一个业界都“认可”、都“遵循”的法则，大家都使用同样的方法来进行互通互联，从而实现无界限的“联通”和最大可能的复用。
SOA是一个具有非常意义的体系思想，是所有软件人员的一个梦想：将中间层再进行抽象，通过一个跨技术架构的元数据和业务逻辑，也就是服务，使之成为可跨企业使用、能够长期积累、并不断丰富的企业业务库和信息资产。夸张一点说，如果所有软件开发都遵循SOA，那么世界软件业将会发生彻底的改变。
但是，SOA思想诞生时，它并不是一个技术标准，也没有相关规范。如何在技术体系上实现SOA？Web服务在这个恰当的时候恰当的出现了。Web服务使业务逻辑能够以标准化的接口（WSDL）提供，并可基于标准化传输方式（HTTP、Message等）、采用标准化协议（SOAP）进行调用。这为SOA的实现提供了可能。

向ESB发展
ESB（Enterprise Service Bus），企业服务总线，作为下一代的企业集成技术，巧妙的将总线集成和SOA思想结合起来。ESB 是一项允许开发人员集成异构系统的技术，同时ESB不再面向定制出来的业务接口，它面向的是公共服务。ESB为服务提供者和服务消费者之间的集成提供了一个平台，相对集线器模式的集成系统，具有更有效、更灵活的内部体系结构。
ESB是面向服务的，而服务是基于标准的，例如Web服务，这使得ESB具有屏蔽异构系统平台差异的能力。由于服务本身的独立封装、可以随意插拔，各式各样不同的服务可随时注册到总线中，形成面向服务的组件库，所以，ESB天然就具备很好的扩展性。同时ESB采用了轻量级的分布式体系，可以将更多的处理逻辑分配到多个的端点上，中央服务器不复存在，业务逻辑处理能力及系统压力可灵活调配。

ESB是服务提供者和服务消费者之间的桥梁，同时也是服务提供者和服务消费者之间的中介代理，可以提供多种不同的增值服务，带来更多的业务价值。
ESB支持数据处理流程，这些数据处理流程可以是一些简单的路由规则，也可以是功能强大的流程引擎，例如BPEL。这些流程的作用域在逻辑上可以是一个部门内, 也可以是多个伙伴企业之间, 而在物理拓扑上, 可以是跨区、跨国、跨洲，甚至可以是休斯敦和阿波罗飞船之间。
ESB支持数据转换，它已经屏蔽了异构系统之间的平台差别，同时还能屏蔽异构系统之间的同种语义的数据差别，就象翻译能把中文翻译成英文一样，ESB可以把一个系统的业务数据根据规则翻译成另一个系统能够识别的业务数据。

几种集成方式之间的比较

从图中可以看到，ESB处于最右上方，一个 ESB 架构形成了一个消息集线器和集成服务的互通网格，具有一个彻底分布的集成网络的功能性和智能性。
Apusic ESB 立足于Apusic应用服务器和Apusic消息中间件之上，并与其无缝结合，具备面向服务、面向消息、事件驱动的特性，是一个在SOA架构中充当服务间智能化集成与管理中介的灵活敏捷的基础平台。

Apusic ESB 面向基于Web Services的标准服务，彻底摆脱了传统EAI中中央服务器的集中式交换模式，采用轻量级的分布部署模型，通过对服务的注册、发布、流程化等一系列的管理，形成服务仓库，并可以将服务仓库中的来自世界各地的服务根据业务需求有机的结合起来，对服务进行组合，如此一来，能够在数据集成、信息共享的基础上，释放更大的业务价值，并且带给用户一种良好的体验：好像这些服务都安装在自己的本地桌面一样。
Apusic ESB 主要包含了下面这几部分的内容：
1、智能网络
2、服务仓库
3、业务重组
4、数据交换
5、管理工具

智能网络
Apusic ESB 在部署模型上具有高度的分布式特性。不同的Apusic ESB 服务器在物理上可以相隔很远，像北京和纽约。但是，在逻辑上，在集中式管理上，这些Apusic ESB 服务器共同组成了Apusic ESB 网络。在Apusic ESB 网络中，各个Apusic ESB 服务器通过网络相互连接，在逻辑上形成完整的企业服务总线。

Apusic ESB 网络具有高度的智能性，不要求网络中的各个服务器都必须明确地和其他所有的服务器建立连接关系，只要一个节点不是孤立节点，那么这个节点就可以和Apusic ESB网络中的任意非孤立节点通信。并且，在通信过程中的路径选择上，Apusic ESB 网络会根据网络连接状况的实际情况，作出智能调整，自动选择最优路径。

服务仓库
Apusic ESB 服务仓库是一个服务容器，对服务进行管理。Apusic ESB 面向的是符合Web Services标准的服务。也就是说，任何一个已经公开的Web服务，在网络能够联通的情况下——无论是部署在本地还是异地——这个Web服务就可以被注册到Apusic ESB的服务仓库中，成为基于服务的组件库中的一员。需要时，随时可以根据业务需求对Apusic ESB服务仓库中的任何服务进行组合。
对于一个已经被导入到服务仓库中的服务，Apusic ESB 不会对这个服务本身产生任何影响，并且，Apusic ESB 服务仓库中的所有服务，都是可重用的，也就是说，可以在不同的服务组织流程中，使用同一个服务。
这是和SOA的思想是相符的：服务本身，必须要释放出广泛的业务价值。

除了服务注册之外，Apusic ESB还可以发布符合Web Services标准的服务以供业务系统调用，并作为业务系统接入Apusic ESB的唯一方式。在这种模式下，业务系统和Apusic ESB之间的交互被标准化，而不需要通过特定平台的特定API。
这也和SOA的思想是相符：一切基于标准。
除了符合Web Services标准的服务之外，Apusic ESB还提供了一些内置的服务，例如Apusic ESB数据库适配服务。Apusic ESB 数据库适配服务具有根据用户配置，针对主流数据库，提取、打包和存储数据的能力。

服务重组
在Apusic ESB 服务仓库中已经注册的服务，一个个都是离散的、无机的，两两之间没有联系。根据服务的特性，每个服务都是独立封装的，专注于执行自己所负责的业务逻辑。但是企业间的业务集成，往往是需要多个服务一起来协同完成的。
例如我们经常会作的一件事情，在网络上买书。我们首先登录购书网站，提交购书订单。购书网站会通过库存系统检查自己的库存，如果没有存货，则会通过采购系统完成新书采购的工作。可以把其中的每一个步骤都看作是一个服务，那么对于网上卖书这么一个简单的操作来说，需要提交订单、检查库存、执行采购等多个服务组合到一起，才能完成。
如何将这些服务组合到一起？最浅显的答案莫过于，服务的消费者，根据需求场景，依次调用服务仓库中的已存服务。但是这样一来，作为服务消费者，很多的业务逻辑将被硬编码写死，系统弹性很差。这时，人们发现，即使在SOA的架构中，在面向服务的软件开发过程中也面临一个重要的问题：如何把功能逻辑和业务逻辑分离，使系统具有最大程度的可扩展性？工作流技术被引入，来解决这样的问题。BPEL4WS规范的提出，就是要解决在SOA的体系下，针对符合Web Services标准的服务，以流程化的方式进行组合。
Apusic ESB引入了工作流流程化的概念，引入自主实现且基于业界标准的，具有条件分支和合并并行流转功能的BPEL4WS流程引擎，可以实现综合的、复杂的业务逻辑编排。这个流程引擎支持子流程、条件脚本、路由节点等功能。通过灵活的流程定义，按照即时的业务需求，将单个离散服务有机的组合起来，达到服务重组的目的，完成集成的业务需求。此外，Apusic ESB在引擎级别将BPEL规范的细节进行了包装，对用户来说，只需要关心流程中的一个服务即可，无须再去关心BPEL的具体技术细节。
流程化的服务组织，在SOA的级别上，将服务的功能和需要完成的业务分离开来。一旦业务发生变化，只需要简单的修改流程定义，就可以适应新的业务场景，如此一来，系统将具备高度的弹性与可扩展性。

数据集成
如果业务系统从一开始构建的时候，就本着SOA的理念，已经将大量的业务逻辑设计并实现成标准的服务，那么在Apusic ESB上完成这些系统的集成是一件非常快捷、简单的事情。但是对于那些已经运行了多年的历史系统而言，在构建这些系统的时候， SOA思想还没有被提出，服务的概念还不存在。这些系统之间，如果一定要通过面向服务的方式进行集成的话，对于这些遗留系统的改造成本是巨大的。
为了实现遗留系统，特别是那些不是在SOA的理念下搭建的系统之间的集成，并且，鉴于现存的这些系统，基本都是基于数据库的特点，Apusic ESB 提供了针对数据库的适配器，实现遗留系统的非破坏式接入Apusic ESB。
Apusic ESB 数据库适配器是Apusic ESB内置的服务，具有服务的独立封装、事件驱动等特性，根据用户的配置，针对主流的数据库，提供数据的提取、打包、存储等功能。Apusic ESB 数据库适配器支持当今主流的数据库Oracle、DB2、SQL Server、MySQL等，并且提供数据错误日志、异常处理机制等数据安全保证。并且，Apusic ESB 数据库适配器，提供数据映射机制，实现异构数据结构、异构数据库平台之间的数据自动转换。
Apusic ESB 数据库适配器也是一种服务，可以进行定制并发布到Apusic ESB服务仓库中，通过Apusic ESB 流程引擎将不同的Apusic 数据库适配服务串联起来，通过流程定义勾勒出完整的数据流向，形成一个完整的业务解决方案。单纯的数据交换流程，就是特殊的服务组织流程，这个流程中的所有节点任务，都是Apusic ESB数据库适配器。并且Apusic ESB流程引擎支持在同一个流程定义中，可以同时存在处理Web服务类型任务的节点，和处理数据库任务的节点。
通过流程机制,有机的在数据库适配器服务和已经注册在服务仓库中的Web服务之间进行数据信息交互，从而实现了遗留系统之间的集成。
同时，Apusic ESB 数据库适配器允许用户灵活的定制数据同步周期，例如每隔5分钟、每天的固定深夜12点、每周最后一个工作日的下午6点，每个月的10号从上午10点开始；每隔3分钟直到中午12点结束等等。
管理工具
Apusic ESB同时提供了一体化的管理工具，通过工具，您可以非常方便的对Apusic ESB进行集中式管理、可视化的流程设计，以及运行期的实时监控等功能。
集中式管理：
Apusic ESB管理工具可以对多个Apusic ESB网络进行统一管理，通过管理工具登录到Apusic ESB网络的任意一个节点，就可以对整个网络中的所有节点进行远程的管理和部署，真正做到部署上的高度分布，管理上的高度统一。

您可以在Apusic ESB网络拓扑图中，非常轻松的添加新的节点，删除已有的节点，您也可以对其中的某个具体节点进行各种详细的配置。

流程设计:
Apusic ESB管理工具还能够以可视化的方式对ESB节点上的服务进行管理，您可以非常方便的注册一个服务，也可以非常方便的注销一个服务，对于最为复杂的流程定义，只需要在工具中拖拖拽拽，就可以完整的定制一条复杂的服务组织流程。

实时监控：
Apusic ESB 管理工具还提供了对整个ESB网络的实时监控功能，您可以对ESB网络上的任意一个节点运行情况进行实时监控，包括流程实例的运行状态，数据状态等等，使您真正做到对ESB的运行状况了然于胸，尽在掌握。