文档介绍：ESB拓扑方案
作者Adrien LOUIS译者胡键
摘要
在实施SOA时,现在非常流行使用象企业服务总线(ESB)这样的基础设施。在一个企业中,对于这种基础设施至少有两种不同的实现思路:在公司内使用多个的ESB服务器,每个服务器解决一个特定部门的特殊集成问题;或使用一个覆盖全公司的ESB,它负责将信息系统所有部分链接在一起。本文将讨论这两种方式在架构与管理方面的若干问题。
不同的基础设施
5年来,ESB一直是SOA基础方面的一个时髦词汇。ESB这个概念是David Chappell提出的,但时至今日仍然没有真正适合它的定义。的确,每个ESB厂商都鼓吹各自的愿景,另外在基础设施层面也存在着不同的实现方式。每种方式都有其优点和缺点。
第一种方式是让各个部门用自己的ESB实现去管理自己的SOA。它管理应用的集成与业务过程的开发。通过使用分散独立的ESB,每个部门可以自由地实施它想要的解决方案。但是当需要与其它合作伙伴进行通信时,部门ESB要通过一种标准的“桥接”技术(如Web服务)才能访问和提供一些业务服务。在这种情形下,通信可以依赖于诸如HTTP这样的协议,而服务质量(如可靠性或安全)则必须依靠手工实现。
第二种方式将SOA基础设施视为一个整体视图,在其中ESB是全公司统一的。这种ESB遍布于各个部门的各台服务器上,以确保它们之间能进行通信。对另一个部门提供的服务进行调用非常简单,因为消费者与ESB通信的方式与它调用本地服务的方式没有分别。
在这个视图中,ESB真正被视为一个主干基础设施,就像一个以太网。实际上,ESB是一个天生内部互联的节点集合。一个节点就是服务消费者或提供者的连接点。
注:一个ESB节点实际上是一个具有网络能力、能与其它实例互联的ESB服务器。
覆盖全公司网络的ESB并不是一个老大哥
首席信息官的第一反应可能会说“哦,不!我不想要一个允许任何人都可浏览和访问公司内任何东西的‘无处不在的’工具”,管理员们可能会嚷道“我如何管理和监督?”,“其它管理员可以修改我服务器上的东西,这不可能”,或大家经常听到的“安全性怎么办?”,等等诸如此类……
显然,一个通用ESB不会允许每一件事。它只是简化了整个网络的通信,并以一种简化的方式提供一组全网络的服务质量。
统一ESB中的域(Domain)
域和子域定义了实体间的边界。这样,从管理上来,每个ESB“节点”只能由子域管理员来管理。子域管理员是唯一能启动、停止、安装连接器、部署服务等活动的人,他管理被域中ESB节点所使用的端口,并可以设置代理或防火墙来保护这些端口。
部署于一个域中节点上的业务服务可以是公共或私有的。也就是说,在注册中心中,一个私有服务只对同一域中的消费者可见。而且,私有服务只能由相同域的消费者访问。
注:除非明确说明,在以下几节中将不会讨论私有服务。
服务和过程监测只能显示本域信息或其他域的公共信息,不能看到其他私有域的过程或服务统计。
既然我们已经清除了若干关于统一ESB是什么的潜在误解,让我们看看它的优点。
注册中心
在一个非互联ESB环境中,对于其他域的服务,只有在两个域的ESB之间显式地为该服务创建一个桥接才能访问该服务。比如,某域中的一个服务被暴露为一个经典的Web服务,另一个ESB必须知道URL才能调用它。要引用所有这样的Web服务需要一个公司范围的注册中心。在这种情形下,每个域的管理者必须将本域的Web服务发布到这个公司注册中心中。这些Web服务可以被认为是公司的“公共”服务,因为它们对所有消费者可见。
在一个统一ESB中,业务服务注册中心本身就是统一的;每个ESB实例的注册中心会与其它ESB的注册中心进行同步。一个消费者或服务浏览器只要连接到其中一个域的ESB就可以看到总线上的所有服务。每当有新服务被暴露于ESB上,每一个ESB实例上的所有消费者都可以立即发现并访问它,与这个 ESB的物理位置无关。所有服务以同一方式被访问;它们是“ESB服务”。不管它们是如何实现的,也不管使用的是什么协议。
编配
要编配遍布于多个非互联ESB上的服务有两种方案。一种方案是将BPEL引擎置于ESB环境之外,例如将它作为一个Web服务BPEL引擎。按照这种方式,过程设计者要对各个域上的所有服务均有所了解才行。而且,可能还得把这些服务整合为Web服务以便访问。在运行时,BPEL引擎要在整个网络上建立起 HTTP连接才能访问这些服务。
另一种方案是将BPEL引擎被集成到ESB里,调用那些本地环境可用的服务。当它需要访问其他域中的服务时,必须先通过桥接(如一个Web服务调用)访问对方的ESB,然后再调用对方服务。
对于统一ESB,“内部”注册中心包含了总线上所有的服务及描述。只要将BPEL设计器连接上ESB注册中心,