【IT168 技术文档】这个系列（上）描述了企业服务总线（Enterprise Service Bus，ESB）的基本概念和工作角色。本文侧重于描述为支持面向服务的体系结构（SOA）而进行的 ESB 开发的场景和问题。您的组织的 SOA 和 ESB 可能需要应用到一个或多个这样的场景。
ESB 场景及分析
SOA 中的 ESB 场景部分描述了许多 SOA 和 ESB 实现的起点。每个场景都指出驱动体系结构和设计决策的问题，而这些决策会影响解决方案模式的选择（将在这个系列的第 3 部分中进行介绍）。在 驱动 ESB 体系结构和设计决策的问题 部分中，您可以阅读关于这些问题的详细描述。这些解决方案模式代表着从服务技术的基本使用，到简单的 ESB 实现，再到复杂的 SOA 体系结构的发展过程。
这些 ESB 场景的目的并不在于展示组织对 SOA 或 ESB 的全部需求。例如，虽然某个场景（如两个系统的基本集成）可能看起来很好地匹配了特定的当前需求，但是随着时间的推移，这种需求可能发展成更复杂的需求（如支持一个或多个应用程序实现更广泛的连接性场景。另外，还可能有许多对 SOA 或 ESB 基础架构的单独需求会出现这样的情况，就其个别而言符合简单场景，但集中在一起则表现得比较复杂。
我们需要在实现满足非常明确的需求的解决方案、努力预料未来的需求和定义跨企业的一致解决方案这三者之间作出选择。将组织的需要看作是总体上相对复杂的场景（如实现具有高服务质量和 Web 服务标准支持的 SOA 基础架构）可能是比较适合的。另外，还可以将个别的情形单独看作是简单场景，但是定义最后得到的这些解决方案以后发展成通用体系结构的路线。
SOA 中的 ESB 场景
下面的几个部分描述了这些场景的特征：
1.两个系统的基本集成
2.支持一个或多个应用程序实现更广泛的连接性
3.支持遗留系统实现更广泛的连接性
4.支持企业应用程序集成（EAI）体系结构实现更广泛的连接性
5.实现组织之间服务或系统的受控集成
6.通过编排服务使流程自动化
7.实现具有高服务质量和 Web 服务标准支持的 SOA 基础架构
两个系统的基本集成
| 场景 | |
| 企业需要提供用不同的技术（如 J2EE、.NET、CICS 等等）实现的两个系统之间的集成。Web 服务 SOAP 标准或消息传递中间件可能是候选的集成技术。这个场景的一个重要的问题是，将来是否会出现需要集成其他系统的情况。一开始就使用可扩展解决方案可能会对未来的需要提供支持；但是必须在为构建这样的解决方案而付出的额外工作与解决简单的问题的最初需要之间保持平衡。 | |
| 最相关的问题 | 相关的解决方案模式（请参见下一篇文章） |
| 1,3,4,6,10,13 |
|
支持一个或多个应用程序实现更广泛的连接性
| 场景 | |
| 现有的已封装或自定义开发的应用程序（例如客户关系管理（Customer Relationship Management，CRM）、企业资源规划（Enterprise Resource Planning，ERP）等等）可能是用 J2EE 平台或其他应用程序服务器环境实现的，它们提供的可用功能超出了应用程序本身。以服务的形式公开这些功能的价值在于，既支持应用程序彼此之间的互操作，也提供对新的通道或客户端的访问。使用可互操作或开放的标准通信和服务协议看来是今后发展的非常好的途径。 | |
| 最相关的问题 | 相关的解决方案模式（请参见下一篇文章） |
| 1、2、3、4、6、8、9、10、11、12、13、14 |
|
支持遗留系统实现更广泛的连接性
| 场景 | |
| 组织对遗留技术（比如 CICS、IMS 等等）进行了大量的投资，以支持为他们提供核心业务事务和数据访问的应用程序。其重要价值在于提供互操作性或开放标准、以及对这些事务进行基于服务的访问（例如，查询帐户余额的事务、创建订单、日程安排或交付跟踪、查询库存级别等等）。 | |
| 最相关的问题 | 相关的解决方案模式（请参见下一篇文章） |
| 1,2,3,4,7,8,9,10,11,13,14 |
|
支持企业应用程序集成（EAI）基础架构实现更广泛的连接性
| 场景 | |
| 需要对现有的 EAI 基础架构（如 IBM WebSphere Business Integration）进行扩展，以对其进行基于可互操作协议或开放标准的访问。虽然根据 XML 业务数据并通过高度可互操作协议（如 HTTP 或 WebSphere MQ）公开服务接口可以在某些场景中提供适当的互操作性级别，但是如果对现有的集成范围的自定义开发或专有扩展都不是可接受的，则可能需要支持 WSDL 和 SOAP Web 标准。 | |
| 最相关的问题 | 相关的解决方案模式（请参见下一篇文章） |
| 3、4、5、8、9、11、13、14 |
|
实现组织之间服务或系统的受控集成
| 场景 | |
| 组织希望使其客户、供应商或其他合作伙伴能够直接集成由一个或多个应用程序、遗留系统等等提供的功能。控制的重点是需要提供从外部各方到这些应用程序的安全且易管理的访问。因为组织不能直接控制其合作伙伴所使用的技术，因此最好使用开放标准。此场景既可以应用于分散的组织之间，也可以应用于大型分布式组织的各个单位之间。 | |
| 最相关的问题 | 相关的解决方案模式（参见下一篇文章） |
| 1、2、3、4、6、8、9、10、11、13、14 |
|
通过编排服务使流程自动化
| 场景（注意：此场景可以看作是支持一个或多个应用程序实现更广泛的连接性场景的发展。它不被当作一个 ESB 场景，因为服务编排通常是与 ESB 分开实现的，正如本系列的第一篇文章所述。然而，我之所以把它包括在这里，是因为此场景往往驱动对 ESB 和服务编排组件的需求。） | |
| 现有的已封装（例如，客户关系管理（Customer Relationship Management，CRM）、企业资源规划（Enterprise Resource Planning，ERP）等等）或自定义开发的应用程序可能是在 J2EE 平台或其他应用程序服务环境中实现的，它们提供的可用功能超出了应用程序本身。可以使用可互操作或开放通信和服务协议将这些功能作为服务公开，这样应用程序就可以交互。可以在某些层次上组合这些交互以构成业务流程。应该使用适当的建模和流程执行技术（可能遵守适当的开放标准）来对这些流程进行显式建模。 | |
| 最相关的问题 | 相关的解决方案模式（请参见下一篇文章） |
| 1、2、3、4、6、10、11、12、13、14 |
|
