通过企业服务总线连接SOA服务

由于众多原因，企业服务总线 (ESB) 是任何企业级 SOA 必不可少的一部分。随着实施面向服务结构体系 (SOA) 这一观念的日渐普及，企业发现自己的服务组合规模日益增大。如果不遵循正确的体系结构模式，则很难有效地利用和重用这些服务。企
业服务总线 (ESB) 是一种相对较新的软件类别，我们可以使用它来满足上述目的。它提供了一个急需的中间层，从而简化了企业 SOA
实施的数据传递、服务访问、服务重用以及服务管理。ESB 还支持智能指导的通信，调解松散耦合业务组件和取消耦合的业务组件之间的关系。在“精通 SOA”的这一部分中，您将了解 ESB 为什么是企业级 SOA 必不可少的一部分，以及如何实施 ESB（包括常见问题）。是否需要ESB？[/b]正如本系列第 1 部分中所说明的那样，SOA 是应用程序在设计、开发和集成方面的一次根本性转变。SOA 还有助于将企业应用程序作为可轻松集成和重用的模块化业务服务来进行开发。然而，SOA 还意味着各种挑战，其中许多挑战可直接通过 ESB 解决： 可靠的消息传递：可靠的数据传输仍然是所有集成解决方案的基本需要。虽然 SOA 的原则需要基于标准的、与平台无关的消息协议，但该原则本身并未考虑可靠的数据传递。各项标准（如 WS-RM）正在逐渐支持该功能，但它们还不够成熟或者未被广泛采用。
服务虚拟化：SOA 代表了一种基本的体系结构模式，在该模式中，任何服务使用方均可从任何平台访问一个服务提供方。这又意味着适当的协议和语法调解在适当的位置隔离了使用方和提供方。
动态发现和调用服务：为了优化服务的重用，服务使用方需要一个中介功能来了解服务请求的特性，从而方便与提供方进行连接。在理想的 SOA 中，这种关系将在运行时作为中介。
策略管理：已知和未知服务使用方进行访问都需要一个抽象的策略管理模型，该模型除了强制执行与服务提供方实施无关的更复杂的业务级别策略外，还能够强制执行身份验证、授权和加密。
管理和监视服务：逐渐增加的服务数量导致环境越来越复杂。必须监视该环境以了解其可用性、性能以及任何技术或业务级别错误。
系统异构性：人们通过常用的应用程序以及用来连接它们的软件可以发现，今天的新应用程序就是明天的旧应用程序。这种新技术的普及是必然的，因此，设计系统时必须考虑让其支持这种变化。
从技术实施细节中抽取业务逻辑：SOA 的目标之一是提供一种分层的方法来开发系统，该方法将技术变化从业务流程的变化中隔离出来，并且将业务流程的变化从技术变化中隔离出来。实际上，必须从一开始就将这种“分别考虑”设计到体系结构中。解
决这些问题的标准方法 — 无论是企业范围还是部门范围 — 是任何 SOA 项目成功的基础。不能保证数据传递的 SOA
解决方案对大多数业务事务而言不够强健，不能将业务流程从转换和路由逻辑中抽取出来的 SOA
解决方案不会很敏捷。而且，一个无法适应标准和产品发展变化的体系结构并不会降低 TCO。ESB 模式（以及相关 ESB 产品的引入）是全面的
SOA 解决方案成功的基础。ESB 部署的先决条件[/b]深入讨论细节之前，我们先进行一下回顾，就会发现并非所有 SOA 实施都需要重大的重用和松散耦合。例如，较小的实施可能只会从 ESB 的增加中获得边际效益。您需要满足一些战术条件才能建立对 ESB 的需要。按照重要性顺序，这些条件依次为： 1.服务使用方和提供方可能是松散耦合的，或者需要同步、非确定性的路由（其中使用方需要响应，但不会显式知道服务提供方）。
2.执行业务事务之前，需要根据数据、使用方或提供方执行专门的功能（可能包括策略验证、转换等）。

3.必须有一种将端点应用程序连接到总线的方法（通过重新设计或者通过适配器），该方法必须能够在面向服务的模型中运行这些应用程序（并非所有应用程序都
能够轻松地支持服务。例如，传统的老式程序（如客户数据应用程序）使用连接到老式屏幕的、基于批处理的编程模型来运行。它们可能不会很容易地适应更基于事
务的 SOA 模式。）对于所有复杂的计算体系结构，这三个条件仅仅是指导方针。肯定存在这样的情况：无需同时满足以上三个条件即可轻松地判别 ESB。着手进行 SOA 规划时，不但要关心战术方面，还要考虑长期策略目标。自上而下与自下而上[/b]SOA
的两种主要方法通常被称作“自上而下”和“自下而上”。在自上而下的方法中，采用 SOA
是由业务方驱动的，结果是一个专门设计以满足业务需求的体系结构，着重于效率。企业的 IT
部门通常推崇更实用的自下而上的方法，因为该方法更关心服务虚拟化，其主要目标是将成本降至最低并将更多灵活性结合到核心 IT 资产中。可以想象，人们就哪种方法最适合或最有效展开了激烈的争论。在此，我们不会偏袒任何一方，而是探讨 ESB 是否与这两种方法相关。答
案是肯定的，自上而下和自下而上这两种 SOA 方法通常都需要
ESB。这两种方法所使用的工具没有太大的区别；只不过引入这些工具的时间不同。在自下而上方法中，可能在最初阶段就开始使用 ESB
来执行低级数据和系统集成。在自上而下方法中，最初关注的可能是构建服务，不过稍后这些服务之间需要进行互连时，就该使用 ESB 了。
常见用例[/b]详尽列出所有可能的用例将需要更长的篇幅。然而，其中一些较为常见的用例需要进行强调：服务虚拟化[/b]。服务虚拟化是实施 ESB 的主要驱动因素，其他大多数用例都是它的变形。设
计时缺少清晰的层次（或“分别考虑”）会在业务逻辑和 IT
细节之间引入不必要的耦合。起初，这些交叉相关性的影响可能不太明显，但随着集成范围的扩大，它们开始以指数级速度削弱 SOA
实施最初的优点。到端点的直接链接越多，最开始灵活、松散耦合的体系结构的僵化惯性就越大。例如，如果将端点详细信息嵌入在一个数据库中，那么将该数据库从一个网络重新定位到另一个网络将需要一个新版本的贷款审批流程。处理几个这样的链接可能还是可管理的，但如果增加到 50 个服务和数十个端点，您就会看到体系结构很快会变成一张纠缠不清的相关性网。该示例还暴露了这种设计在 IT 事件（数据库移动）和业务逻辑（贷款审批流程）之间引入的不正常关系。当复杂的核心商业资产（如贷款审批流程）根本没有变化时，日常 IT 事件难以接受触发这些资产的整个版本控制。当然，这个小示例可能已经通过仔细的配置以及使用诸如 JNDI 或 DNS 这样的技术缩减至最少，但它仍然可以方便地阐释服务虚拟化所能解决的问题。更现实的用例包括添加或删除数据库、更改 CRM 供应商，甚至吸收作为合并或并购的结果而产生的新系统。如
图 1 所示，服务虚拟化是保存面向服务体系结构的增长能力的关键。通过使用 ESB，您可以从业务逻辑中彻底消除所有端点详细信息（如 IP
地址、端口以及其他低级特定于计算机的详细信息），而是公开一个稳定的接口。最终结果是将业务需求与 IT 需求完全分离，从而允许 IT
和业务独立修改各自的资产。


图 1 服务虚拟化集中控制策略。您只需监视几个应用程序服务器日志和配置文件的日子已经一去不返。幸运的是，ESB 可以帮助您解决如今的分布式系统中固有问题的管理和监视，即，提供有关多个应用程序和协议的端到端视图，在企业范围内配置并强制执行全局策略。由
于 ESB 逻辑上作为所有集成通信的中介，因此对 SOA 基础结构的监视变得简单。ESB
管理控制台提供了流经服务的所有交换和消息的统一视图。（请参见图
2。）这些新的监视功能可用于进行被动和主动监视。例如，构建和强制执行端到端的服务级别协议 (SLA)
变成可能。实际的监视平台可能是一个外部应用程序（如 OpenView 或 Tivoli，也可能是较新的业务活动监视 (BAM)
工具，现在越来越多地用于实时基础结构监视），但 ESB 提供了所需的统一的、基于标准（SNMP、JMX、SQL）的基础结构视图。


图 2 集中控制策略使
用 ESB 可以更轻松地全局运行像安全性或可靠性这样的策略。通过将标准化的钩子（例如，WSDL 接口）公开到集成体系结构的每个步骤中，ESB
使得插入常用的安全、审计和消息处理工具成为可能。例如，您可以拦截某些站点之间的所有通信来执行安全声明标记语言 (SAML)
断言，或者在企业级别（而非每个单独的端点）支持 64 位 DES 加密。此外，ESB
还允许对专门应用程序的特定任务（如安全策略）的责任和委托进行清晰的分层。原有数据源支持 Web 服务。[/b]最初，没有将 ESB 作为原有集成的解决方案。但是现在，普遍认为必须在 SOA 中考虑原有数据源，事实上，这些数据源通常组成所涉及的大多数服务。一
般来说，访问原有应用程序（如 ERP 或 CRM 系统）中的服务意味着使用供应商协议和 API 与目标系统直接交谈。（请参见图
3。）这意味着构建服务使用方的团队必须了解目标系统，并且能够编译其客户端的供应商 API（更不用说购买这些 API
的许可证了）。因此，部署新服务使用方的成本非常高。


图 3 访问服务（专有方式）然而，大多数 ESB 供应商都提供可以连接到受欢迎的原有系统的适配器。然后，只需进行配置即可访问应用程序的服务，添加新服务使用方的成本显著降低，不用再使用供应商协议，所需的只是标准（SOAP、JMS 或 ESB 公开的任何其他入口点）。（请参见图 4。）


图 4 访问服务（基于标准的方法）进
行服务虚拟化之后，即可以在许多情况下利用 ESB 了。例如，多通道支持。（请参见图 5。）只需进行简单的配置，即可向过去只能通过单独的 API
访问的服务中添加新通道。因为使用同一个体系结构来支持多个通道，因此，确保所有访问（不论是哪个通道）都归属一个全局策略中是可能的。


图 5 多通道支持例如，通过一个 ESB，只能通过 SOAP 从客户门户访问的 Web 服务可以允许其他面向客户的系统（如可以与 JMS 或 DCOM 交谈的 IVR 或传真网关）访问相同的服务。
实施ESB 的科学[/b]虽然许多人会认为开发以业务为中心的 SOA 是一门“艺术”，但 ESB 的实施更大程度上是一门科学。遵循正确的方法、标准和体系结构原则将确保成功实施 ESB。ESB 的实施通常在两个工作流中进行；软件体系结构和支持基础结构（即“技术体系结构工作流”）；以及支持业务所必须的服务逻辑（以及支持配置）的设计、开发和部署（即“应用程序体系结构工作流”）。让我们看一下这两个工作流。技术体系结构工作流。[/b]该
工作流包括选择软件、识别常见体系结构功能和基础结构要求，以及部署可以开发服务（最终是组合应用程序）的整个基础体系结构。与传统项目相同，有必要对技
术体系结构工作流的组成部分进行需求分析。针对该分析，有必要广泛地调查期望 SOA
所具备的功能，并将它们分解到分散的服务中。需求列表示例（不详尽的）包括： 错误处理
审计
策略管理（不同的详细信息级别）
服务发现
有保证的传递
协议支持（特定于所涉及的应用程序和需求）
标准支持（通常是 WS* 标准，可能包括其他标准，这取决于规划）
智能路由只有明确了这些需求并选择了产品之后，才能开始开发。如果重用是所有 SOA 实施的主要着眼点，那么开发人员培训可以更广泛。应用程序体系结构工作流。[/b]应用程序体系结构工作流包括识别、设计、创建业务级别服务以及将其部署到总线上。通过上述的自上而下或者自下而上的方法可以处理这个特殊的工作流；然而，随方法的不同，管理实际设计和开发过程的基本原则只会略有不同。针
对 ESB 进行设计时，第一个也是最重要的决策是识别出在哪些条件下服务应该位于总线上，在哪些条件下服务应该位于（例如）业务流程管理 (BPM)
工具中。虽然这两种功能表面上看来有很大差异，但是用 BPM
工具设计类似于总线的功能是很有可能的（在某些情况下，甚至更可取)。通常，以下准则适合这种情况： ESB 上的服务应该是短生命、不连续的事务。
需要复杂规则来确定路由、访问以及其他基于数据的决策的服务应该位于 ESB 上。
具有特定于端点的逻辑的服务应该位于 ESB 上。例如，如果无法在应用程序自身内将规范的数据对象映射到特定于应用程序的对象上，就应该在总线中进行该操作（因为您在该应用程序中无法进行控制，也可能是因为您没有留下任何 COBOL 程序员来进行修改）。
ESB 服务应该不包含任何人力工作流活动。除了这些高级准则以外，您还应该在全局范围内实施一些较低级别的设计和开发准则。其中某些准则不是 ESB 所特有的，但由于 ESB 会变得更相关。我们已经在下面用斜体标明了新准则。 建立成功度量。乍一看，这似乎是显而易见的，但经常有很多 ESB（以及 SOA）项目失败，都是因为它们无法量化地演示其所支持的过程或服务中的成功。有用的度量可能包括服务的使用方数量以及服务的响应时间（平均时间和高峰时间）。
对于每个应用程序，必须识别适当的适配器以及必须应用的相应协议和封套技术。这包括识别交互中所需的所有标准（例如，Web 服务可靠的消息传递）。确保在选择适配器和协议时考虑事务模型（异步或同步的）以及可靠性需求。
必须详细定义所涉及的源数据对象和目标数据对象，并将它们映射到对应的规范对象。如果某个规范对象不存在，您必须识别、设计并开发一个。规范对象的存在对于广泛采用 ESB 范例很重要。
将度量设计到服务中。利用 BAM 工具可以轻松地访问实时度量。实时度量的示例可能包括给定值上的订单数、某种类型的客户更新数，或者一段时间内一个人（客户或其他）的请求数。
识别所有级别的安全限制。这些级别包括应用程序、事务、数据对象内容以及潜在的数据域内容。还必须将安全策略定义为支持这些要求。
在可能的情况下利用现有服务。所有企业级的 SOA 都应该有一个可搜索的服务注册表。
识别审计要求以及技术和业务级错误处理要求，相应地设计服务。某些 ESB 工具具有重要的现成功能，对这个特殊步骤有所帮助。
设计时牢记所有可用的标准。企业体系结构组发布给定的 SOA 环境中将支持的标准并且支持所有开发人员轻松地访问该列表，这是一个不错的做法。
部署服务时，定义并发布 WSDL。将服务注册到企业服务注册表中。遵循这些准则就可以成功实施 ESB，从而可以随着时间的流逝轻松地进行小改动。其他注意事项[/b]和其他所有技术一样，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 用于接口，等等。结论[/b]ESB
体系结构模式（以及相应的产品）是任何企业级 SOA 的重要组成部分。ESB 提供了一个重要的功能，可以断开特定于应用程序的逻辑与 BPM
功能的连接，同时还提供了一种支持松散耦合的、虚拟化的服务层的方法。通过精心的前期体系结构考虑以及目前正在严格强制执行的一组简单明了的设计准则，通
过 ESB 编写服务成为一门非常产业化的科学。