ESB是企业服务总线(Enterprise Service Bus)的缩写,是中间件技术与Web Service等技术结合的产物,也是SOA系统中的核心基础设施。ESB就是一个服务的中介,形成服务使用者->ESB服务Proxy->服务提供者的生物链,中介的作用在不同应用中各有不同:
从上面可以看到ESB的基本功能仍然是数据传输,消息协议转化,路由三大核心功能。有这三大核心功能也可以看到在进行异构系统的整合时候往往根据需要ESB提供这些功能。没有ESB时候也可以实现SOA,比如借助SCA和BPEL来实现SOA,当时却很难实现消息协议转化和动态路由。 ESB在发展过程中有从原有的消息中间件转化为ESB产品的,这类消息中间件和数据总线产品在原有的EAI企业应用集成中应用比较多。而SOA根据强调了基于服务的集成,以Web Service服务为基本的管理单元。一个服务的定位是关于如何把业务逻辑表现成为一组相互独立的,自描述的且能互操作的实体。 对于SOA关注的是服务全生命周期,通过服务实现业务价值。而ESB关注的是服务中介和服务的集成,是SOA的基础设施。SOA有两个核心组件,一个是ESB,一个是BPEL,而ESB是基础设施,BPEL是业务流程驱动下服务的集成和整合。离开了SOA,ESB将失去它所连接的服务,而仅仅是一个总线,同时也将变得毫无价值。Bobby做了一个比喻:路是没有任何价值的,除非你利用它把一个东西从一个地方移到另外一个地方。而离开SOA,ESB就像一个没人使用的道路。 做SOA的事情不要先上来建立一个大而全的ESB,相反是关注你的业务问题,找到用SOA的方法来解决业务上的需求,在解决这个问题的过程当中,你会看到一系列的业务服务。这些业务服务是会产生业务价值的。它可以灵活地组装,动态地解决你变化的业务需求。这是它的价值,只有这样才能使你的业务敏捷起来,随需应变起来。而在服务的组装过程中,你再去考虑利用ESB来把他们连接起来。
ESB 需要某种形式的服务路由目录(service routing directory)来路由服务请求。然而,SOA 可能还有单独的业务服务目录(business service directory),其最基本的形式可能是设计时服务目录,用于在组织的整个开发活动中实现服务的重用。Web 服务远景在业务服务目录和服务路由目录的角色中都放置了一个 UDDI 目录,因而使得可以动态发现和调用服务。这样的目录可以视为 ESB 的一部分;然而,在这样的解决方案变得普遍之前,业务服务目录可能与 ESB 是分离的。
标准的 ESB 功能
通信 | 服务交互 |
---|---|
路由 寻址 通信技术、协议和标准(例如 IBM® WebSphere® MQ、HTTP 和 HTTPS) 发布/订阅 响应/请求 Fire-and-Forget,事件 同步和异步消息传递 | 服务接口定义(例如,Web 服务描述语言(Web Services Description Language,WSDL)) 支持替代服务实现 通信和集成所需的服务消息传递模型(例如 SOAP 或企业应用程序集成 (EAI) 中间件模型) 服务目录和发现 |
集成 | 服务质量 |
数据库 服务聚合 遗留系统和应用程序适配器 EAI 中间件的连接性 服务映射 协议转换 应用程序服务器环境(例如 J2EE 和 .NET) 服务调用的语言接口(例如 Java 和 C/C++/C#) | 事务(原子事务、补偿、Web 服务事务(WS-Transaction)) 各种确定的传递范例(例如 Web 服务可靠消息传递(WS-ReliableMessaging)或对 EAI 中间件的支持) |
安全性 | 服务级别 |
身份验证 授权 不可抵赖性 机密性 安全标准(例如 Kerberos 和 Web 服务安全性(WS-Security)) | 性能 吞吐量 可用性 其他可以构成契约或协定的持久评估方法 |
消息处理 | 管理和自治 |
编码的逻辑 基于内容的逻辑 消息和数据转换 有效性 中介 对象标识映射 数据压缩 | 服务预置和注册 记录、测量和监控 发现 系统管理和管理工具的集成 自监控和自管理 |
建模 | 基础架构智能 |
对象建模 通用业务对象建模 数据格式库 B2B 集成的公共与私有模型 开发和部署工具 | 业务规则 策略驱动的行为,特别是对于服务级别、服务功能的安全和质量(例如 Web 服务策略(WS-Policy)) 模式识别 |
集成 服务质量
安全性 服务级别
消息处理 管理和自治
建模 基础架构智能
上面的许多功能既可以使用专有技术实现,也可以通过利用开放标准实现。然而,使用不同的技术来实现 ESB 可能会使它们的性能、可伸缩性和可靠性这些特性显著不同,同时 ESB 功能和所支持的开放标准也会有所不同。由于这些原因,再加上最近制订和正在兴起的一些相关标准,当今实现 ESB 的许多关键决策都涉及到成熟的专有技术和不成熟的开放标准之间的权衡。 支持 SOA 的最低功能的 ESB 实现 如果在前面确定的功能中只有一部分和大多数 SOA 场景相关,我们可能会问:实现 ESB 所需的一组最低功能由什么构成?为此,考虑最被普遍认同的 ESB 定义的原理:
最低的 ESB 功能
通信 | 集成 |
---|---|
提供位置透明性的路由和寻址服务 控制服务寻址和命名的管理功能 至少一种形式的消息传递范型(例如,请求/响应、发布/订阅等等) 支持至少一种可以广泛使用的传输协议 | 支持服务提供的多种集成方式,比如 Java 2 连接器、Web 服务、异步通信、适配器等等 |
服务交互 | |
一个开放且与实现无关的服务消息传递与接口模型,它应该将应用程序代码从路由服务和传输协议中分离出来,并允许替代服务的实现。 |
服务交互
请注意这些最低功能并不需要使用特别的技术,比如 EAI 中间件、Web 服务、J2EE 或 XML。这些技术的使用非常接近也非常符合需求,但是不必强制要求使用它们。相反,最低功能几乎只需简单地使用 SOAP/HTTP 和 WSDL 就可以实现(当然不是所有的情况都这样):
然而,这些 SOAP/HTTP 和 WSDL 的基本应用只是点到点(point-to-point)的集成,并不能实现一些 ESB 需要的关键功能:
当然,在许多甚至是大多数情形中往往需要其他的功能,并且这种需要变得越来越常见。特别地,不管是现在还是以后,下面的需求类型可能会导致更复杂高级的技术的使用: