从企业服务总线(Enterprise Service Bus,ESB)在2002年被正式提出以来,我们看到ESB不管是在实现方式还是部署方式上都有了不小的变化。在过去的四年多的时间里,ESB作为软件领域里的一个独立产品也被越来越多的人所接受,众多的ESB供应商正在架构、连接性、易用性以及服务质量的保证(如持续可用)等方面进行竞争。
很多综合服务供应商(如IBM、BEA)、企业应用集成商(如Tibco、webMethod)以及Web服务工具供应商都纷纷给自己的产品冠以ESB的名号,英国电信甚至把ESB做进了它们的一个硬件产品中。
很明显,作为SOA(Service-Oriented Architecture)的核心和基础架构,ESB已经成为准备踏上和已经踏上SOA之旅的CIO们必须认真考虑和仔细研究的一个产品。因为作为一种中间件,ESB通过与它连接的各种应用的服务级接口实现各种应用之间的连接,控制它们之间的通信,这一功能正在越来越多的生产系统中发挥着作用。更为重要的是,几年来很多企业和机构已经在生产中部署了ESB,ESB的效果得到了一定程度的校验,同时人们对如何充分发挥ESB的作用以及建立SOA的环境,为此需要建设、部署管理哪些基础设施有了越来越清晰的认识。这些基础设施包括:
●面向流程、事件驱动的架构(Event-Driven Architecture,EDA);
● Web服务的治理;
●高级Web服务规范(WS-*);
●复杂事件处理(Complex Event Processing,CEP);
●语义数据集成。
事件驱动的架构
谈到ESB就不得不谈到面向流程、事件驱动的架构,因为ESB与这种架构配合起来可谓相得益彰。
通常,点对点的集成是通过简单的请求/响应这种同步的方式来完成交互的。在这种环境中,ESB作为数据传输和转换的中介可以很好地完成这一任务,但是,ESB最能发挥作用、也最能体现其带来的灵活性的地方还是在面向流程、事件驱动的架构中。
在进行跨多个应用、大范围的集成时,成功的关键是有一个灵活的架构,面向流程、事件驱动的架构就是这样的架构。通过使用ESB,事件驱动的架构中的每个应用与其他应用之间处于一种松耦合状态。在这种架构中,每个应用独立于其他应用运行完成一项任务,或者异步地完成一组任务中的一个。
即使在一个应用发出了一个请求,然后等待响应以完成接下来的流程时也是这样。这个请求被发到总线上,按照预先定义的流程,这个请求可能会经过很多应用、数据源、路由器和转换器。上述一系列的行为都是独立完成的,最后的响应也是作为一个独立的事件到达最初的这个应用。
事件驱动的交互模式一个主要优点就是保证应用之间的松耦合。只要接入ESB中,每个应用都不用了解如何与其他的应用进行交互这些细节,ESB负责处理所有的协议、数据格式和不同的交互模式。
当然,事件驱动的架构只有在一定条件下才能有效地工作。首先,ESB必须具有可靠和高可用的异步消息传递能力。在一个同步的点对点的集成项目中,如果一个应用没有收到一个请求的响应,它会发出错误的信息,同时再次尝试发出请求。但是在异步的情况下,应用向ESB发出一个请求以后就不再关心是否会有响应,直到一个新的请求到达,通知这个应用完成下一个处理。
由于很多时候企业的所有交易都必须经过ESB总线完成,因此ESB必须有容错能力,支持复杂的业务逻辑,遇到错误的逻辑也能及时恢复。
另外一个必须满足的条件是,应用需要适应这种事件驱动的交互模式。在事件顺序非常重要的场合,应用必须能够检查事件的顺序并做出适当的处理,否则,ESB就要有能力保证在复杂的逻辑情况下(也许这些逻辑还会有错)事件的先后顺序。
很多综合服务供应商(如IBM、BEA)、企业应用集成商(如Tibco、webMethod)以及Web服务工具供应商都纷纷给自己的产品冠以ESB的名号,英国电信甚至把ESB做进了它们的一个硬件产品中。
很明显,作为SOA(Service-Oriented Architecture)的核心和基础架构,ESB已经成为准备踏上和已经踏上SOA之旅的CIO们必须认真考虑和仔细研究的一个产品。因为作为一种中间件,ESB通过与它连接的各种应用的服务级接口实现各种应用之间的连接,控制它们之间的通信,这一功能正在越来越多的生产系统中发挥着作用。更为重要的是,几年来很多企业和机构已经在生产中部署了ESB,ESB的效果得到了一定程度的校验,同时人们对如何充分发挥ESB的作用以及建立SOA的环境,为此需要建设、部署管理哪些基础设施有了越来越清晰的认识。这些基础设施包括:
●面向流程、事件驱动的架构(Event-Driven Architecture,EDA);
● Web服务的治理;
●高级Web服务规范(WS-*);
●复杂事件处理(Complex Event Processing,CEP);
●语义数据集成。
事件驱动的架构
谈到ESB就不得不谈到面向流程、事件驱动的架构,因为ESB与这种架构配合起来可谓相得益彰。
通常,点对点的集成是通过简单的请求/响应这种同步的方式来完成交互的。在这种环境中,ESB作为数据传输和转换的中介可以很好地完成这一任务,但是,ESB最能发挥作用、也最能体现其带来的灵活性的地方还是在面向流程、事件驱动的架构中。
在进行跨多个应用、大范围的集成时,成功的关键是有一个灵活的架构,面向流程、事件驱动的架构就是这样的架构。通过使用ESB,事件驱动的架构中的每个应用与其他应用之间处于一种松耦合状态。在这种架构中,每个应用独立于其他应用运行完成一项任务,或者异步地完成一组任务中的一个。
即使在一个应用发出了一个请求,然后等待响应以完成接下来的流程时也是这样。这个请求被发到总线上,按照预先定义的流程,这个请求可能会经过很多应用、数据源、路由器和转换器。上述一系列的行为都是独立完成的,最后的响应也是作为一个独立的事件到达最初的这个应用。
事件驱动的交互模式一个主要优点就是保证应用之间的松耦合。只要接入ESB中,每个应用都不用了解如何与其他的应用进行交互这些细节,ESB负责处理所有的协议、数据格式和不同的交互模式。
当然,事件驱动的架构只有在一定条件下才能有效地工作。首先,ESB必须具有可靠和高可用的异步消息传递能力。在一个同步的点对点的集成项目中,如果一个应用没有收到一个请求的响应,它会发出错误的信息,同时再次尝试发出请求。但是在异步的情况下,应用向ESB发出一个请求以后就不再关心是否会有响应,直到一个新的请求到达,通知这个应用完成下一个处理。
由于很多时候企业的所有交易都必须经过ESB总线完成,因此ESB必须有容错能力,支持复杂的业务逻辑,遇到错误的逻辑也能及时恢复。
另外一个必须满足的条件是,应用需要适应这种事件驱动的交互模式。在事件顺序非常重要的场合,应用必须能够检查事件的顺序并做出适当的处理,否则,ESB就要有能力保证在复杂的逻辑情况下(也许这些逻辑还会有错)事件的先后顺序。