Accenture 首席技术官 Don Rippert 的近期访谈的主题是:激活 SOA 的全部潜力还需五年。但是,访谈中隐藏着一个简单的论断,即使用企业服务总线(Enterprise Service Bus,ESB)是实现 ESB 全部潜力 4 步中的第三步。Don Rippert 模型中的步骤如下:
- 使用 XML,以更标准的方式使用应用程序接口。
- 捕获一些业务过程,并将它们转化成为 Web 服务。
- 引入并全面使用企业服务总线。
- 产生业务过程执行语言(Business Process Execution Language,BPEL),它可由业务过程建模工具完成。BPEL 可以改变应用程序的行为,而无需修改软件。
Rippert 先生在采访中表示,尽管很多组织拥有 ESB,但是它并没有被完全利用。他进一步的表示,大多数公司仍处于阶段 1。与这个 ESB 所处位置的论断相对比的是, Burton Group 的分析师 Anne Thomas Manes 的叙述,其发表于近期面向服务架构 Yahoo Group 的讨论中。Anne 说:
…如果缺少我推荐启动 SOA 的“基本组件”,ESB 将不会列在我的清单中。事实上,我并不鼓励人们由 ESB 开始。ESB 并不会鼓励好的 SOA 行为。ESB 本质上是集成系统,而非 SOA 系统。SOA 是用于拆卸应用竖井(application silos),而集成系统则是修补这些竖井。
引用她的书,她接着提及的基本组件包括:
- 一个或多个服务平台(如,.NET,Java EE 应用服务器等)
- SOA 管理解决方案
- 注册表
- 如果服务要被暴露在防火墙之外,那么需要 XML 网关
引用组员早期的帖子,她说道:
“…ESB 特别适合桥接传统应用,因此,在服务基础设施中,它是一个有用的组件。很多 ESB 也支持可靠消息传递、异步消息传递和发布 / 订阅交换模式。这些能力都非常有用,但是,在 SOA 项目的初始阶段可能不会发挥多大的用途。(每个组织有很多不选用这些能力的项目。)在 SOA 项目的后期,你还可能需要一个编制(orchestration)引擎,并且大多数的 ESB 都会提供一个。即便如此,ESB 也绝对不是组织启动 SOA 的起点。所有这些能力你一开始并不需要。因此,ESB 应该在后期购买。”
这似乎符合 Rippert 先生的观点,即尽管很多组织拥有 ESB,但是它并没有被完全利用。Manes 女士的评论同样有助于定义 ESB 的范围,通过暗示许多 ESB 支持的特性,它确定了一组适当的能力。
根据维基百科的 ESB 定义,ESB 有如下特性:
- 它是面向服务架构的实现。
- 它通常是操作系统和编程语言无关的;它应能在 Java 和.Net 应用程序之间工作。
- 它使用 XML(可扩展标识语言)作为标准通信语言。
- 它支持 Web 服务标准。
- 它支持消息传递(同步、异步、点对点、发布 - 订阅)。
- 它包含基于标准的适配器(如 J2C/JCA),用于集成传统系统。
- 它包含对服务编制(orchestration)和编排(choreography)的支持。
- 它包含智能、基于内容的路由服务(itenerary 路由)。
- 它包含标准安全模型,用于 ESB 的认证、授权和审计。
- 它包含转换服务(通常是使用 XSLT),在发送应用和接收应用之间转换格式,简化数据格式和值的转换。
- 它包含基于模式(schema)的验证,用于发送和接收消息。
- 它可以统一应用业务规则,充实其它来源的消息,分拆和组合多个消息,以及处理异常。
- 它可以条件路由,或基于非集中策略的消息转换,即不需要集中规则引擎。
- 它可监视不同 SLA(服务级别合约)的消息响应门限,以及在 SLA 中定义的其它特性。
- 它(常常)简化“服务类别”,向更高或更低优先级用户做出适当的响应。
- 它支持队列,在应用临时不可用时用来保存消息。
- 它由(地理)分布式环境中的选择性部署应用适配器组成。
维基百科的定义容许“ESB 精确定义的变种”。
Manes 女士和 Rippert 先生似乎都同意 ESB 是有用的,并代表项目后期用于部署 SOA 的功能集合。维基百科的定义可以作为讨论的起点,主题是关于如何定义这一有用技术。
在随后的讨论中,请关注 ESB 的定义,而非本文中引证的业界专家的观点。
评论