在关于企业服务总线(Enterprise Service Bus,ESB)的这个系列的第二部分中,作者描述和分析了实现
ESB 和其他面向服务的体系结构(SOA)的解决方案的一些常见场景。
这个系列的第
1 篇文章描述了企业服务总线(Enterprise Service Bus,ESB)的基本概念和工作角色。本文侧重于描述为支持面向服务的体系结构(SOA)而进行的
ESB 开发的场景和问题。您的组织的 SOA 和 ESB 可能需要应用到一个或多个这样的场景。
SOA 中的 ESB 场景部分描述了许多 SOA 和 ESB 实现的起点。每个场景都指出驱动体系结构和设计决策的问题,而这些决策会影响解决方案模式的选择(将在这个系列的第
3 部分中进行介绍)。在
驱动 ESB 体系结构和设计决策的问题 部分中,您可以阅读关于这些问题的详细描述。这些解决方案模式代表着从服务技术的基本使用,到简单的
ESB 实现,再到复杂的 SOA 体系结构的发展过程。
这些 ESB 场景的目的并不在于展示组织对 SOA 或 ESB 的全部需求。例如,虽然某个场景(如两个系统的基本集成)可能看起来很好地匹配了特定的当前需求,但是随着时间的推移,这种需求可能发展成更复杂的需求(如支持一个或多个应用程序实现更广泛的连接性场景。另外,还可能有许多对
SOA 或 ESB 基础架构的单独需求会出现这样的情况,就其个别而言符合简单场景,但集中在一起则表现得比较复杂。
我们需要在实现满足非常明确的需求的解决方案、努力预料未来的需求和定义跨企业的一致解决方案这三者之间作出选择。将组织的需要看作是总体上相对复杂的场景(如实现具有高服务质量和
Web 服务标准支持的 SOA 基础架构)可能是比较适合的。另外,还可以将个别的情形单独看作是简单场景,但是定义最后得到的这些解决方案以后发展成通用体系结构的路线。
SOA 中的 ESB 场景
下面的几个部分描述了这些场景的特征:
两个系统的基本集成
场景 |
企业需要提供用不同的技术(如 J2EE、.NET、CICS 等等)实现的两个系统之间的集成。Web
服务 SOAP 标准或消息传递中间件可能是候选的集成技术。这个场景的一个重要的问题是,将来是否会出现需要集成其他系统的情况。一开始就使用可扩展解决方案可能会对未来的需要提供支持;但是必须在为构建这样的解决方案而付出的额外工作与解决简单的问题的最初需要之间保持平衡。
|
最相关的问题 |
相关的解决方案模式(请参见下一篇文章) |
1,3,4,6,10,13 |
- 使用包装器或适配器来实现基本集成—请参见基本适配器。
- 或者,想要在将来进行扩展,有以下两种方案:
- 添加控制服务网关。
- 或者实现一个复杂的基础架构—比如Web services Compliant
Broker或EAI Infrastructure for SOA。
|
支持一个或多个应用程序实现更广泛的连接性
场景 |
现有的已封装或自定义开发的应用程序(例如客户关系管理(Customer
Relationship Management,CRM)、企业资源规划(Enterprise Resource
Planning,ERP)等等)可能是用 J2EE 平台或其他应用程序服务器环境实现的,它们提供的可用功能超出了应用程序本身。以服务的形式公开这些功能的价值在于,既支持应用程序彼此之间的互操作,也提供对新的通道或客户端的访问。使用可互操作或开放的标准通信和服务协议看来是今后发展的最佳途径。
|
最相关的问题 |
相关的解决方案模式(请参见下一篇文章) |
1、2、3、4、6、8、9、10、11、12、13、14 |
- 使用包装器或适配器来实现基本集成—请参见基本适配器。
- 添加控制服务网关。
- 或者实现一个复杂的基础架构—比如Web services Compliant
Broker或EAI Infrastructure for SOA。
- 如果还需要流程编排(Process Choreography),就实现Service
Choreographer或者Full SOA Infrastructure。
|
支持遗留系统实现更广泛的连接性
场景 |
组织对遗留技术(比如 CICS、IMS 等等)进行了大量的投资,以支持为他们提供核心业务事务和数据访问的应用程序。其重要价值在于提供互操作性或开放标准、以及对这些事务进行基于服务的访问(例如,查询帐户余额的事务、创建订单、日程安排或交付跟踪、查询库存级别等等)。
|
最相关的问题 |
相关的解决方案模式(请参见下一篇文章) |
1,2,3,4,7,8,9,10,11,13,14 |
- 使用包装器或适配器来实现基本集成—请参见基本适配器。
- 或者,想要在将来进行扩展,有以下两种方案:
- 添加控制服务网关。
- 或者实现一个复杂的基础架构—比如Web services Compliant
Broker或EAI Infrastructure for SOA。
|
支持企业应用程序集成(EAI)基础架构实现更广泛的连接性
场景 |
需要对现有的 EAI 基础架构(如 IBM WebSphere Business
Integration)进行扩展,以对其进行基于可互操作协议或开放标准的访问。虽然根据 XML
业务数据并通过高度可互操作协议(如 HTTP 或 WebSphere MQ)公开服务接口可以在某些场景中提供适当的互操作性级别,但是如果对现有的集成范围的自定义开发或专有扩展都不是可接受的,则可能需要支持
WSDL 和 SOAP Web 标准。 |
最相关的问题 |
相关的解决方案模式(请参见下一篇文章) |
3、4、5、8、9、11、13、14 |
- 使用开放数据格式及EAI Infrastructure for SOA来扩展
EAI 基础架构。
- 添加控制服务网关。
- 或者对带有Web services Compliant Broker的基础架构增加开放标准支持。
|
实现组织之间服务或系统的受控集成
场景 |
组织希望使其客户、供应商或其他合作伙伴能够直接集成由一个或多个应用程序、遗留系统等等提供的功能。控制的重点是需要提供从外部各方到这些应用程序的安全且易管理的访问。因为组织不能直接控制其合作伙伴所使用的技术,因此最好使用开放标准。此场景既可以应用于分散的组织之间,也可以应用于大型分布式组织的各个单位之间。
|
最相关的问题 |
相关的解决方案模式(参见下一篇文章) |
1、2、3、4、6、8、9、10、11、13、14 |
- 添加服务网关。
- 或者如果需要更多的复杂功能,就实现Web Services Compliant
Broker。
|
通过编排服务使流程自动化
场景(注意:此场景可以看作是支持一个或多个应用程序实现更广泛的连接性场景的发展。它不被当作一个
ESB 场景,因为服务编排通常是与 ESB 分开实现的,正如本系列的第一篇文章所述。然而,我之所以把它包括在这里,是因为此场景往往驱动对
ESB 和服务编排组件的需求。) |
现有的已封装(例如,客户关系管理(Customer Relationship
Management,CRM)、企业资源规划(Enterprise Resource Planning,ERP)等等)或自定义开发的应用程序可能是在
J2EE 平台或其他应用程序服务环境中实现的,它们提供的可用功能超出了应用程序本身。可以使用可互操作或开放通信和服务协议将这些功能作为服务公开,这样应用程序就可以交互。可以在某些层次上组合这些交互以构成业务流程。应该使用适当的建模和流程执行技术(可能遵守适当的开放标准)来对这些流程进行显式建模。
|
最相关的问题 |
相关的解决方案模式(请参见下一篇文章) |
1、2、3、4、6、10、11、12、13、14 |
- 如果服务的直接连接是可能的,则实现Service Choreographer。
- 如果需要更复杂的集成或控制,则实现Full SOA Infrastructure。
|
实现具有高服务质量和 Web 服务标准支持的 SOA 基础架构
场景 |
此场景是由前面的组成的。它代表了对由多个应用程序、遗留系统等等提供的服务进行普遍的内部或外部访问的需要。需要各种安全、聚合、转换、路由以及服务编排功能。IT
组织以响应所支持的业务不断增加的需求,从而使得能够在业务系统之间进行更普遍且更灵活的集成。 |
最相关的问题 |
相关的解决方案模式(请参见下一篇文章) |
全部 |
- 实现Full SOA Infrastructure。
|
为了确定用于 ESB 的合适解决方案模式和实现技术,需要对特定的 ESB 功能需求进行详细的分析。下面的问题旨在帮助进行这一过程,而前面的部分指出了与每个场景相关的特定问题。
- 现有功能及其数据接口是否与您想要提供的服务相匹配?您是否能够修改或聚合应用程序?
- 如果不可以,则转换或聚合功能就需要由适配器或 ESB 体系结构来提供,或者不得不由服务客户端来完成。
- 服务是否可以以一些通用业务数据模型的形式公开?如果可以,则实现这些服务的系统是否已经支持该模型?或者说可以使它们这样做?
- 如果服务不可以,则转换或聚合功能就需要由适配器或 ESB 体系结构来提供。
- 是否需要开放标准?或者是否可以通过 EAI 中间件来实现适当的互操作性?如果需要开放标准的话,则哪些开放标准是适合的?
- 虽然使用开放标准是实现互操作性的一种途径,但专有的 EAI 中间件也具有高度的互操作性,并且往往要成熟得多。另外,许多组织还拥有广泛的现有基础架构,在一些场景中,它们可能会使得开放标准的作用几近于无。
- 在需要开放标准的场景中,Web 服务也许是这些情况下最明显的选择。不过,您也可以应用 Java
Messaging Service (JMS)、JDBC、基本 XML 或者一些其他的技术(比如
EDI 或业界通用的 XML 格式。
- 在实践中,不能总是假定相同标准的不同实现之间具有互操作性,特别是对于近来出现或刚刚兴起的标准。对于
Web 服务,Web 服务互操作性组织(Web Services Interoperability
Organization)发布了使用 SOAP 和 WSDL 的互操作性的基本概要,其他更高级的标准(例如
Web 服务安全性(WS-Security)、Web 服务事务(WS-Transaction)等等)的概要随后也将发布。在产品全面、稳定且广泛地支持这些概要之前,开放标准的使用还没有得到保证,并且可能并不总是促进互操作性。
- 是否需要支持基本通信协议及标准(例如 WebSphere MQ、SOAP、WSDL)?或者需要更高级的功能(例如
Web 服务安全性(WS-Security)、Web 服务事务(WS-Transaction)等等)?
- 对支持更复杂标准的需求将对实现技术的选择加以更严格的约束,并且可能意味着使用还不成熟的技术。
- 当果考虑更改现有的基础架构使用的消息格式和协议(包括可能采用开放标准)时,需要在整个现有的基础架构中进行这些更改吗?或者很快就要应用新的消息格式和协议吗?如果正在使用或考虑使用
EAI 技术,该技术是否有自己的内部格式?或者它能够将开放标准处理为内部格式吗?
- 开放标准的任何应用都是受扩展访问的需求驱动的,因此它们对现有基础架构的接口的可用性比在内部使用的这样的标准更重要。
- 如果需要在内部使用特定的格式、技术或标准,这会给实现技术的选择带来限制。
- 将作为服务公开的系统实现功能支持所需的技术或开放标准(比如 SOAP、JMS或 XML)吗?
- 如果不支持,ESB 基础架构或适配器将需要在所需的开放标准和服务提供者支持的格式之间进行转换的功能。
- 在需要访问遗留系统的情况下,通过使用更新的基于 XML 的技术,可以直接支持(例如 CICS SOAP
支持)遗留系统的可用性吗?是否需要单独的适配器?遗留平台是否支持 XML 处理?如果支持,这种处理是否可以灵活地使用平台功能?
- 如果因为这其中的任何原因而导致所需的 SOAP 或 XML 功能对遗留平台不可用,则需要在适配器(比如s
J2C Connector Architecture (JCA) 或 WebSphere Business
Integration Adaptors)、集成层或 ESB 基础架构中使用适当的转换功能。
- 如果 EAI 技术已经可用,它是否使用适当的功能或接口粒度将服务作为消息流实现?它支持哪些连接性协议(例如
JCA、SOAP、WebSphere MQ 以及 Java 远程方法调用(Java Remote Method
Invocation))?
- 如果现有消息流不提供所需要的服务,则需要另外的流程来执行转换。如果 EAI 技术不直接支持所需的标准,就需要添加一个网关组件。
- 应该从服务客户端通道以工作负荷缓冲、安全、登录等形式提供给服务提供者系统什么保护措施?
- 这种缓冲通常是 ESB 基础架构的一个角色,并且定义它所需要一些功能。如果特定的服务提供者系统(例如遗留事务系统(legacy
transactional systems))需要额外的保护,则可以使用专用集成层。
- 应该实现多少服务?实现的什么方面应该在这些服务中保持一致?如何实施一致性(可能在多个平台上和多个应用程序中)?
- 如果只需要非常少的服务,简单的点到点(point-to-point)集成模型可能比较适合。然而,如果需要更多的服务或者过一段时间以后可能还是如此,则添加控制点(比如由
ESB 提供的)就变得愈加有益。
- 服务交互包含在组织内部,还是有一些交互在组织外部?
- 这常常是不同于在单个组织中实现的 ESB 基础架构的一种情况,因为对安全和服务路由的需求可能与外部可用的服务不同。
- 是否需要服务编排?服务编排是否涉及短期(short-lived)或长期(long-lived)(换句话说就是有状态的)流程,还是两者都涉及?它们是否包含人工活动?
- 在这些需求构成业务功能的情况下,应该在与 ESB 分离的 Service Choreographer
组件中实现编排。关于是支持长期有状态流程还是支持人工活动的需求将对实现技术的选择产生限制。
- 基础架构应该支持什么样的服务级需求(例如,服务响应时间、吞吐量、可用性等等)?随着时间的推移,需要如何对其进行扩展?
- 一些候选的 ESB 实现技术相对较新,并且可能仅仅在有限的服务级进行过测试。同样,由于相关的开放标准不是最近制订就是正在兴起的,所以在更多的既定产品和技术中对它们的支持也是新出现的。
- 在可以预见的未来,关键的体系结构决策将专注于特定开放标准优点的平衡,针对服务级需求的新兴或成熟的产品技术支持这些开放标准。制订这些即时决策需要考虑到有些标准和支持它们的产品是相对成熟的(例如
XML、SOAP等等),有些(例如 Web 服务安全(WS-Security))比较新,还有一些(例如
Web 服务事务)是正在兴起的。
- 标准的优点之间的权衡和经过验证的服务级特征往往驱动一个结合了 ESB 与 SOA 体系结构中适应标准的、专有的或自定义技术的混合方法。
- 是否需要点到点(point-to-point)或端到端(end-to-end)安全模型(例如,ESB
是否可以简单的对服务请求授权,还是需要将请求者的身份或其他凭证传递给服务提供者)?是否需要使用应用程序或遗留安全系统来集成服务安全模型?
- 如果点到点安全性是可接受的,则许多现有解决方案(例如 SSL 、对数据库访问的 J2EE
安全性、适配器安全模型等等)就能够得到应用。如果需要端到端安全性,则 Web 服务安全标准就成为可能,提供所有相关的系统来支持它。换句话说,您可以使用带有客户端消息头的客户端模型,或者传送像应用程序数据这样的安全信息。
本文确定了一些 ESB 实现中最常见的场景,以及对相应的解决方案直接产生影响的问题。虽然没有完全涵盖所有的隐藏问题,但这些是其中最常遇到的。
我们概述了从两个系统的基本集成到实现支持高质量服务和 Web 服务标准的 SOA 体系结构的常见场景。并描述了需要重视的十四个不同的问题:
- 现有数据接口
- 业务数据模型
- 开放标准的使用
- 对基本或高级通信协议的支持
- 通过现有系统对数据传递格式的修改
- 通过新技术公开现有服务
- 对遗留系统的访问
- 现有 EAI 技术
- 需要的保护措施
- 需要提供多少服务和需要的一致性程度
- 公司内部以及与其他公司之间的互操作
- 对服务编排的需求
- 服务级需求的基础架构级支持
- 点到点(point-to-point)或端到端(end-to-end)安全模型的使用
理解这些基本场景和问题为您开发可能的解决方案打下了牢固的基础。在本系列的第 3 部分,我将讨论本文中提到的实际解决方案。如下:
- 基本适配器
- 服务网关
- Web services Compliant Broker
- Service Choreographer
- 用于 SOA 的 EAI 体系结构
- 完整的 SOA 体系结构
最后,我将讨论组织考虑如何使用受控和增量的方式发展它们的体系结构时可用的选择。也将说明能够指导您开发自己的
ESB 路线的一些问题。
如果作者没有与下列人员进行讨论,就不会有本文的存在,他们中的所有人都为本文贡献了很好的想法和思想:Beth
Hutchison、Rachel Reinitz、Olaf Zimmerman、Helen Wylie、Kyle
Brown、Mark Colan、Jonathan Adams、Paul Fremantle、Keith
Jones、Paul Verschueren、Daniel Sturman、Scott Cosby、Dave
Clarke、Ben Mann、Louisa Gillies、Eric Herness、Bill Hassell、Guru
Vasudeva、Kareem Yusuf、Ken Wilson、Mark Endrei、Norbert
Bieberstein、Chris Nott、Alan Hopkins 和 Yaroslav Dunchych。
|