实施ESB 的科学

虽然许多人会认为开发以业务为中心的 SOA 是一门“艺术”，但 ESB 的实施更大程度上是一门科学。遵循正确的方法、标准和体系结构原则将确保成功实施 ESB。

ESB 的实施通常在两个工作流中进行；软件体系结构和支持基础结构（即“技术体系结构工作流”）；以及支持业务所必须的服务逻辑（以及支持配置）的设计、开发和部署（即“应用程序体系结构工作流”）。让我们看一下这两个工作流。

技术体系结构工作流。该工作流包括选择软件、识别常见体系结构功能和基础结构要求，以及部署可以开发服务（最终是组合应用程序）的整个基础体系结构。与传统项目相同，有必要对技术体系结构工作流的组成部分进行需求分析。针对该分析，有必要广泛地调查期望 SOA 所具备的功能，并将它们分解到分散的服务中。需求列表示例（不详尽的）包括：

    错误处理
    审计
    策略管理（不同的详细信息级别）
    服务发现
    有保证的传递
    协议支持（特定于所涉及的应用程序和需求）
    标准支持（通常是 WS* 标准，可能包括其他标准，这取决于规划）
    智能路由

只有明确了这些需求并选择了产品之后，才能开始开发。如果重用是所有 SOA 实施的主要着眼点，那么开发人员培训可以更广泛。

应用程序体系结构工作流。应用程序体系结构工作流包括识别、设计、创建业务级别服务以及将其部署到总线上。通过上述的自上而下或者自下而上的方法可以处理这个特殊的工作流；然而，随方法的不同，管理实际设计和开发过程的基本原则只会略有不同。

针对 ESB 进行设计时，第一个也是最重要的决策是识别出在哪些条件下服务应该位于总线上，在哪些条件下服务应该位于（例如）业务流程管理 (BPM) 工具中。虽然这两种功能表面上看来有很大差异，但是用 BPM 工具设计类似于总线的功能是很有可能的（在某些情况下，甚至更可取)。通常，以下准则适合这种情况：

    ESB 上的服务应该是短生命、不连续的事务。
    需要复杂规则来确定路由、访问以及其他基于数据的决策的服务应该位于 ESB 上。
    具有特定于端点的逻辑的服务应该位于 ESB 上。例如，如果无法在应用程序自身内将规范的数据对象映射到特定于应用程序的对象上，就应该在总线中进行该操作（因为您在该应用程序中无法进行控制，也可能是因为您没有留下任何 COBOL 程序员来进行修改）。
    ESB 服务应该不包含任何人力工作流活动。

除了这些高级准则以外，您还应该在全局范围内实施一些较低级别的设计和开发准则。其中某些准则不是 ESB 所特有的，但由于 ESB 会变得更相关。我们已经在下面用斜体标明了新准则。

    建立成功度量。乍一看，这似乎是显而易见的，但经常有很多 ESB（以及 SOA）项目失败，都是因为它们无法量化地演示其所支持的过程或服务中的成功。有用的度量可能包括服务的使用方数量以及服务的响应时间（平均时间和高峰时间）。
    对于每个应用程序，必须识别适当的适配器以及必须应用的相应协议和封套技术。这包括识别交互中所需的所有标准（例如，Web 服务可靠的消息传递）。确保在选择适配器和协议时考虑事务模型（异步或同步的）以及可靠性需求。
    必须详细定义所涉及的源数据对象和目标数据对象，并将它们映射到对应的规范对象。如果某个规范对象不存在，您必须识别、设计并开发一个。规范对象的存在对于广泛采用 ESB 范例很重要。
    将度量设计到服务中。利用 BAM 工具可以轻松地访问实时度量。实时度量的示例可能包括给定值上的订单数、某种类型的客户更新数，或者一段时间内一个人（客户或其他）的请求数。
    识别所有级别的安全限制。这些级别包括应用程序、事务、数据对象内容以及潜在的数据域内容。还必须将安全策略定义为支持这些要求。
    在可能的情况下利用现有服务。所有企业级的 SOA 都应该有一个可搜索的服务注册表。
    识别审计要求以及技术和业务级错误处理要求，相应地设计服务。某些 ESB 工具具有重要的现成功能，对这个特殊步骤有所帮助。
    设计时牢记所有可用的标准。企业体系结构组发布给定的 SOA 环境中将支持的标准并且支持所有开发人员轻松地访问该列表，这是一个不错的做法。
    部署服务时，定义并发布 WSDL。将服务注册到企业服务注册表中。

遵循这些准则就可以成功实施 ESB，从而可以随着时间的流逝轻松地进行小改动。

其他注意事项

和其他所有技术一样，ESB 也有自己的特性和困难。以下是使用 ESB 时会遇到的一些问题。

    开始使用 ESB 时就要分别考虑。您新获得的 ESB 是对您技术库的一个非常强大的补充。它还是一个工具，经常展示其 BPM 形式的许多特性（如逻辑结构或转换功能）。当想使用 ESB 进行一些轻型进程协调时，先回头想想您将 ESB 引入 SOA 的初衷：虚拟化您的 IT 基础结构，将业务需求与 IT 需求相分离。因此，遏制将某些逻辑泄露到 ESB 中的念头；让对 BPM 工具的编排和流程协调待在它们该待的地方。

    转换到何处？使用大多数集成工具（消息处理、ESB、BPM）所提供的转换功能，将“什么”转换到“何处”的决定不再是一个问题，而是一个非常好的实践。因此，在 ESB 和 BPM 工具中应该进行什么类型的转换呢？此处没有适合所有情况的答案。一个省事的经验是将方便的“分别考虑”原则扩展到转换，这意味着在 ESB 中执行系统级别的语法转换（例如，CSV 到 XML），在 BPM 中执行应用程序级别的语义转换（例如，CRM 客户到规范客户）。

    影响分析。松散耦合的体系结构的问题之一是详细计划服务之间的关系以及评估变化或中断的影响。在大型 SOA 中获得直接和间接的相关性是一个恐怖的任务。通过支持更大的分离，ESB 可能会加剧这个问题。另一方面，由于 ESB 了解所有的服务及其相关性，因此它还是执行相关性分析的最好信息来源。这对集成供应商而言是一个新兴领域。

    接受异构性的现实（即“总线舰队”）。虽然构想完美的 ESB 可能是一个逻辑的、单一供应商的总线，但是您必须接受当今世界的现实：企业将必须处理多条总线，这些总线可能来自多个供应商、跨部门、位置和时间（通过升级和移植）。记住这些之后，采用将使这种现实更易于处理的非常好的实践和技术就非常重要了。标准的使用在以下这些地方很重要：HTTP、JMS 或 WS-RM 用于消息传递，XSLT 用于转换，WSDL 用于接口，等等。

结论

ESB 体系结构模式（以及相应的产品）是任何企业级 SOA 的重要组成部分。ESB 提供了一个重要的功能，可以断开特定于应用程序的逻辑与 BPM 功能的连接，同时还提供了一种支持松散耦合的、虚拟化的服务层的方法。通过精心的前期体系结构考虑以及目前正在严格强制执行的一组简单明了的设计准则，通过 ESB 编写服务成为一门非常产业化的科学。