内容


再论企业服务总线

更新这种已发展成熟的技术的概念和术语

Comments

简介

2007 年发表了一个 IBM developerWorks 文章系列 探索企业服务总线,当时面向服务架构及相关的概念和术语还不成熟。比如说这个文章系列的 第 1 部分,对 “服务” 这个术语使用得很含混(这依然是一个常见的问题);把 ESB 定位为 “集成层”,并提出 ESB 不能包含 “业务逻辑”。

从那时到现在,情况发生了变化。本文要定义一些清晰明了、含义明确的概念和术语,以消除关于服务的歧义,还要解释(和纠正)SOA 中 ESB 和集成之间以及 ESB 和业务逻辑之间的关系。此外,还指出必须实现面向服务架构这一事实,对实现方法提供指导,重点放在维护关注点隔离的所有重要因素上。

SOA 中的 “服务”

SOA 利用服务简化和形式化业务解决方案的创建并提供敏捷性。理想的 SOA 如图 1 所示,在这种架构中,请求者通过与提供者交互,完成某个与业务相关的任务。

图 1. SOA 的抽象视图:直接服务交互
图 1. SOA 的抽象视图:直接服务交互

“服务” 在图 1 中的什么地方?

请考虑以下说法:

  • “我们确定 Process Order 服务是运营业务所需的服务之一。”
  • “服务是可重用的业务任务。”

这些话表明 “服务” 并不是物理的东西,而是抽象、逻辑或概念性的东西,根本上说,是通过交互完成的业务任务或业务结果。这个解释与 The Open Group SOA Work Group 对 “服务” 的正式定义一致:“具有指定的结果的可重用活动的逻辑表示”。您不能发布 “服务” 或与它交互,但是这些活动通常与 “服务” 相关联。根据这个定义,您一定会得出结论:“服务” 并没有显示在图 1 中,而是隐含在其中。还可以进一步看出,“服务” 是由提供者执行的。

现在,考虑以下说法:

  • “我们将在注册表中发布 Process Order 服务。”
  • “设计新的解决方案时,在注册表中发现服务。”

这些话表明 “服务” 比较具体,也就是说,是某种东西的规范,但仍然不是请求者可以与之交互的东西。根据这个定义,您一定会得出结论:“服务” 根本没有显示在图 1 中。还可以进一步看出,与提供者的所有交互都由 “服务” 指定。

最后,考虑以下说法:

  • “在这个使用场景中,我们调用 Process Order 服务。”
  • “我的 SOA 有可重用的服务,任何应用程序都可以调用它们。”

这些话表明 “服务” 是某种物理的东西,请求者可以与之交互。根据这个定义,对图 1 的解释是:提供者就是 “服务”。

因此,对于 “服务” 这个术语,至少有三种非常不同的解释:

  • 在比较正式的上下文中,“服务” 指业务任务的抽象或逻辑表示。
  • 在不太正式的上下文中,“服务” 指业务任务的具体描述或规范,但是也常常指业务任务的物理实现。
  • 实际上,“服务” 在某些上下文中可以指所有含义,比如在服务生命周期的不同阶段。

上面的讨论表明,如果没有上下文和限定,使用术语 “服务” 可能会引起混淆,甚至导致误解。有时候可以根据上下文推断出含义,有时候不可以。

本文的其余部分不使用 “服务” 这个经常含义模糊的术语,而是使用下面这些特定的术语,以求更准确地表达含义:

  • 受治理的服务:指由 SOA 提供的业务任务,并不明确指出谈论的是业务任务、规范、实现,还是某种组合。例如,“我们有一套用于管理客户账户的受治理的服务。”
  • 服务规范:与服务交互有关的形式化的特征集,包括:通过交互完成的业务任务、交互方式的技术方面以及与交互相关的各种服务性质。服务规范是 “服务” 的形式化表示,是具体的物理的表示。在为企业定义可重用服务(逻辑)或在注册表中发布服务(物理)的上下文中,规范是准确的术语。
  • 服务实现:服务规范的物理实现。因为实现是物理实体,所以可以调用它。这是 “服务” 的非正式含义,但也是最常用的含义。在与服务交互调用服务 的上下文中,实现是准确的术语。本文将讨论服务实现可能需要的东西,包括澄清中介、集成、企业服务总线和提供者等术语。

广泛使用这些更准确的术语会大大减少围绕 SOA 的交流的不明确性,但是我们不指望马上在一般的对话中普及它们。尽管说“调用 Process Order 服务实现”“发布 Process Order 服务规范” 更准确,但是对话更倾向于简化,而不是重视准确性。

本文力求通过澄清术语来减少混淆,试图通过尽可能使用以上术语而避免任何不明确性。另外,您还会看到其他一些常见的术语组合:服务操作、服务公开、服务治理和服务模型。这些术语的含义在文中都有清楚的解释。

服务与服务操作

使用 “服务” 这个术语经常导致的另一种混淆是,它是指一套相关操作,还是指单一操作。

这个术语的正式定义允许但并不强制有多个操作。用于定义部分服务规范的常用机制(比如 Web Services Definition Language (WSDL))支持这种关系。

例如,假设需要能够添加、删除、搜索和更新 "customer" 业务实体的业务任务。可以用一个包含四个操作的服务规范定义一个受治理的服务;也可以用四个服务规范定义四个受治理的服务,每个规范包含一个操作。

但是在一般的对话中,无论是谈论服务规范还是服务实现,经常使用 “服务” 作为服务操作的简称。这会造成混淆。请记住,The Open Group SOA Work Group 把 “服务” 定义为“具有指定的结果的可重用活动的表示”。这个定义本身对术语的使用也比较含糊。如果执行单一活动,那么它实际上是指服务操作。

在讨论服务规范中描述的特征时,服务与服务操作之间的差异很重要。一些特征是整个服务共有的,例如通信传输。一些特征专门针对某一服务操作,例如响应时间。

好在这里提出的许多概念、现象和建议并不受是服务还是服务操作的影响,但是在会影响讨论的准确性的地方我们使用准确的术语 “服务操作”。在需要准确性的地方,您也应该这么做。

SOA 中的服务治理

应该把 SOA 中的 “服务” 看作受治理的服务,即认识到它们由服务规范定义并符合组织的治理策略。这有助于更明确地区分碰巧以比较易用的形式公开的功能(例如,一个提供基于 HTTP/SOAP 的 API 的应用程序)与真正的与业务相关的受治理的服务。

我们来深入讨论一下 “受治理” 在这个上下文中的含义。

SOA 与以前的企业架构设计方法之间的主要差异是什么?SOA 把与业务相关的核心功能作为可重用的服务公开。我们把这分为两个重要的方面:

  • 治理服务对业务的契合度关注哪些业务功能应该是可重用的。简单地说,受治理的服务必须有助于实现业务目标。治理包括预先识别核心业务功能。但是,正如业务不是静态的,SOA 也不是静态的;随着业务的发展和变化,SOA 会慢慢地成熟和演化。因此,治理必须确保受治理的服务(以及整个服务模型)一直符合业务的需要。由 SOA(而不是 ESB)负责治理服务模型的定义和演化,但是 ESB 有助于实施这种治理,这就引出了第二个方面。
  • 治理服务公开关注如何让这些业务功能成为可重用的。对于可重用的(或更准确地说,可共享的)受治理服务,公开它们的方式必须满足许多重要的条件,这些条件也由 SOA 治理。合适的公开包括协议和传输、服务质量目标、组织的安全需求、监视、日志记录和审计、版本战略和所有权。治理的这些方面都与如何 公开受治理的服务有关,ESB 必须实施它们。注意,这些都是非语义性的特征;也就是说,它们不影响公开的业务功能的含义。在架构层面,把这些特征与语义性内容隔离开是有意义的,后面会讨论如何保持这样的隔离。

如何实现服务治理?作为描述与服务交互相关的重要特征的方法,形式化的服务规范在服务治理中起关键作用。在实践中,逻辑性的服务规范可以被编制成物理的,从而支持自动的治理过程(常常通过服务注册表或存储库),确保服务符合组织的业务目标。

显然,要想让 “服务” 对企业有价值,就必须按上述方法治理它们。如果不这样做,它们就不是服务模型的一部分,只能被看作是为有限的特定的用途而创建的 SOA 实现的一部分。因此,SOA 应该由 “受治理的服务” 组成,我们应该使用 “受治理的服务” 这个术语,以提醒自己注意这些服务与传统接口的区别。

对于服务治理,还要注意两点:

  • 在一些组织中,有不同的治理域(例如部门、企业内部、企业外部等等),它们采用不同的治理方法,我们必须接受这个事实。这意味着,在一个域中受治理的服务不一定符合其他域的治理策略,因此可能需要进一步处理才能在另一个域中使用。这个主题很大,我们不在这里详细讨论。但是毫无疑问,随着 SOA 的发展和受治理的环境交互越来越频繁,这个问题会越来越普遍。
  • 服务治理只是企业总体 IT 治理的一部分。服务治理主要涉及识别、公开和管理服务的方式,不应该把它与其他方面(比如代码标准或实现技术)的 IT 治理形式相混淆。这些治理形式是总体 IT 治理的重要部分,但是与服务治理无关。

服务规范

由于服务规范的重要性,我们来仔细研究一下。图 2 说明服务规范在比较全面、成熟(但仍然理想化)的 SOA 中的位置,强调逻辑服务规范和物理服务实现(这里的提供者)之间的关注点隔离。

图 2. SOA 和服务规范
图 2. SOA 和服务规范
图 2. SOA 和服务规范

图 3 显示服务规范的各个方面。执行服务交互的主要原因是什么?服务请求者通过与服务实现进行交互来完成业务任务。在图中的 (a) 部分中可以看到,业务任务由一组语义特征描述,语义特征中包括对所执行的业务任务(例如根据购物车创建订单)的描述以及对任务相关的业务实体(例如客户、账户、购物车和订单)的业务接口的定义。可以把这些语义特征看作是通过与服务实现进行交互完成的、使用与业务相关的术语描述的东西。

图 3. 服务规范的各个方面
图 3. 服务规范的各个方面
图 3. 服务规范的各个方面

图中的 (b) 部分显示句法特征,这是指与服务实现进行实际交互所需的机制;例如,通信协议、消息格式和安全设置。可以把这些特征看作成功交互所需的语法或绑定。

图中的 (c) 部分是操作特征,比如响应时间、吞吐量和可用性。这些特征意味着服务实现最终在一个或多个物理容器中运行,容器具有有限的 CPU 周期、存储空间、内存、网络带宽等资源。可以把操作特征看作服务质量,它们取决于提供者容器的大小和配置,因此在图 3 中提供者容器包含提供者/服务实现。

关注点隔离要求服务规范中的所有特征都是外部的,都是由服务实现公开 的。因此,这些特征独立于服务实现。可以更改、改进或升级实现,只要这些特征不变,就不会影响服务请求者。这也意味着服务规范适用于实现的所有用户。

根据服务规范的定义,可以从图 1 和图 2 所示的直接服务交互得出结论:因为服务提供者 服务实现,所以:

  • 提供者提供的句法特征必须符合服务规范中的句法特征。
  • 提供者提供的操作特征(服务质量)必须符合服务规范中的操作特征。

因此,在图 1 和图 2 中服务提供者实现服务规范的语义(它执行业务任务),它还通过实现句法和操作特征公开与业务相关的语义。

在后面的一些讨论中,为了方便,把与业务任务相关的特征与不相关的特征区分开。在这些讨论中,把句法和操作特征合称为非语义特征,因此只提到语义和非语义特征。

在 SOA 中使用中介进行服务公开

在图 2 所示的过分简化的场景中,提供者已经提供得到适当治理的服务,在现实中很少是这样的。我们来看看提供者的非语义特征不符合治理策略(包括服务规范)的情况。

在图 1 和图 2 所示的直接服务交互中,提供者必须满足服务规范中描述的所有特征。提供者还必须符合组织的所有服务治理策略。根据域中治理的性质,这很难实现,甚至不可能。大多数提供者无法满足得到良好治理的服务规范,而且我们要保持关注点隔离,因此在 SOA 中需要经过中介的服务交互,见图 4。

图 4. SOA 的抽象视图:经过中介的服务交互
图 4. SOA 的抽象视图:经过中介的服务交互
图 4. SOA 的抽象视图:经过中介的服务交互

注意图 2 和图 4 之间的显著差异。第一个差异是,中介作为提供者与请求者之间的媒介。通过引入中介,请求者可以与具有不同特征的提供者交互,但是哪些方面不一样?

前面提到的文章系列的 第 1 部分 说,“服务实现与达到业务目标相关联的语义”,而中介 “仅仅修改与完成必要的互连相关联的语法”。根据前几节的讨论,我们应该调整这些说法。

如果正确地解释的话,这篇文章表明中介不能改变交互的语义特征。根据对服务规范的理解,更好的说法是中介可以操纵交互的非语义特征。非语义特征包括服务规范中的句法和操作(服务质量)特征。中介对通过它们传递的消息执行一组操作以协调非语义特征;这些操作包括协议切换、转换、加密和路由。

图 2 和图 4 之间的下一个差异是,提供者不再单独构成服务实现。这反映提供者不符合得到良好治理的服务规范。提供者提供一组语义、句法和操作特征;但是,在大多数情况下,这些特征并没有在服务模型的范围内正式地定义或治理。为了区分这些未得到治理的特征与服务规范,我们使用提供者描述这个术语表示它们。

图 2 和图 4 之间的最后一个差异是,服务实现实际上是中介和提供者的组合。可以说中介根据服务规范公开提供者,从而增强提供者;也就是说,它帮助提供者满足服务规范中的特征。因此,在这个上下文中中介执行服务公开,也就是使用中介协调非语义特征,从而让未得到治理的功能符合域的治理策略。

现在可以认为中介在 SOA 中的作用是公开服务。更准确的说法是,中介用于根据服务规范公开提供者;它产生的结果是服务实现。

现在研究一下,在经中介的服务交互中,服务规范的性质。根据关注点隔离的要求,中介把实现服务规范中的语义特征的责任都委托给提供者。因此,服务规范的语义特征反映(正式或非正式的)提供者描述中的语义特征,见图 4 中的实线箭头。

中介提供服务规范的所有句法特征,因为它是请求者的交互点,包装了提供者的所有句法特征,在图中它与提供者描述之间没有联系就暗示了这一点。服务规范中的操作特征源自提供者的操作特征(在正式或非正式的提供者描述中)和中介本身的操作特征的组合。例如,响应时间和吞吐量等特征显然会受到中介和提供者的操作容器的影响。这由图中的虚线箭头表示。

现在重申一下我们对服务交互(这次是经过中介的交互)的观察结果。由于 SOA 中强调关注点隔离,所以提供者和中介在执行服务公开方面承担着不同的职责:

  • 提供者提供的语义特征必须满足服务规范中的语义特征。
  • 提供者提供的句法特征不必满足服务规范中的句法特征,因为有中介作为媒介。
  • 提供者提供的操作(服务质量)特征必须超过服务规范中的操作特征,因为中介通常只能降低这些特征。对于这一点,有一些例外情况,比如中介实际上可以把请求路由到适当环境中的其他提供者,从而提高提供者的可用性,但是这超出了本文的范围。

中介与提供者之间的差别对于关注点隔离很重要。如果中介提供服务规范中的语义特征,就会成为提供者。这明显违反关注点隔离原则,会导致各种问题,比如在需要更改业务任务的实现时不确定在哪里 “寻找” 实现,从更改控制点的角度来看不确定谁 “拥有” 实现。

根据上面的讨论,可以确定从架构的角度用于服务公开的中介应该遵守的一些原则:

  • 语义透明:中介不增加语义功能。它通过满足服务规范中的其他特征公开提供者。
  • 反应式而不是前瞻式:中介只在请求者发起与它的交互时才会与提供者交互。
  • 一进一出:因为提供者提供服务规范的所有语义特征,所以对于每个服务操作请求,逻辑上只调用提供者一次,就可以满足服务操作的语义特征。
  • 无状态:在满足请求之后(例如把响应返回给请求者之后),中介并不保存与请求相关的状态。

这些原则对于识别用于服务公开的中介和提供者的职责之间的细微差异非常重要。

SOA 中的 ESB

注意,图 4 中没有显示 ESB,相关的讨论中也没有提到 ESB。为什么呢?ESB 文章系列的 第 1 部分 指出 ESB 是 SOA 中的架构模式;这是对的,但是不准确。那篇文章还提出 ESB 支持中介流(多个中介);这是对的而且很准确。尽管现在常见的说法是 “ESB 公开服务”(在撰写那篇文章时这种说法还不常见),但更准确的说法是 “各个中介根据服务规范公开提供者”。

这意味着,从纯粹的架构角度来说,通过中介的服务公开(支持上述原则)是 SOA 中重要的架构模式。因此,更准确的说法是 “ESB 架构模式是对执行服务公开的中介集合的支持”。在前一篇文章中,“中介” 这个术语总是指执行服务公开。但是,我们经常看到这个术语用来指执行集成方面的其他功能(比如转换和切换)。这通常是由于混淆了服务公开的作用,或者使用的产品既支持用于服务公开的中介也支持其他功能。我们将在后面几节详细讨论这些误解。

因此,可以认为 ESB 是执行服务公开的中介的架构容器,见图 5。此图还表明,ESB 本身驻留在一个或多个操作容器中,ESB 中驻留有用于把提供者公开为受治理服务的中介。这种方式有助于方便地构造、配置和管理中介。这些容器常常采用产品的形式。

图 5. SOA 拓扑
图 5. SOA 拓扑
图 5. SOA 拓扑

服务总线与企业服务总线

注意,图 5 实际上没有使用 ESB 这个术语,而是使用服务总线表示这个架构模式。这是因为术语的发展要反映 SOA 的真实状态。非常常见的做法是在某一域(例如部门、应用程序或业务线)中把提供者公开为受治理的服务;假设所有受治理的服务都在 “企业” 级上公开常常是不正确的。在这些情况下,域使用域服务总线公开服务,大多数服务只在这个域内使用,但是一部分服务可以在整个企业内使用。“企业” 服务总线只在逻辑上存在,服务联合(见第 4 部分)支持在整个企业内共享受治理的服务。

总之,ESB 是一个普遍接受的术语,在一段时间内还会广泛使用。但是,应该认识到并非所有 "ESB" 都是覆盖整个企业的。另外,认识到这一点有助于避免使用 “企业 ESB” 这样的术语。

服务注册表和存储库

在考虑操作容器时,服务规范应该放在哪里?因为服务规范代表受治理的实体,理想情况下它们应该放在服务注册表和存储库中,服务注册表和存储库支持完整的受治理服务生命周期管理,包括服务模型、产生的服务规范和相关的元数据。在某种程度上,服务注册表和存储库是服务规范的容器(图 5)。一定要理解服务总线的存在并不是为了定义服务模型,或者强制提供服务规范或服务注册表和存储库;而是为了实施治理。

SOA 上下文中的集成

本节讨论 SOA 上下文中集成层的性质,以及它与中介和服务总线的关系。前一篇文章把 ESB 定位为 “集成层”。为了减少混淆并与本文描述的概念和术语契合,需要澄清这种说法。

“集成层” 和 “集成” 都是含义非常模糊的术语,它们的定义取决于上下文。在几乎所有上下文中(包括 SOA),集成的定义都源于企业应用程序集成 (EAI),其定义是 “让一个应用程序能够与另一个应用程序交互的东西”。在 EAI 中,集成肯定要处理应用程序之间的非语义不匹配,但是在 EAI 中集成常常也处理应用程序之间的语义不匹配。

如果执行调用的应用程序期望完成某个任务或得到某个结果,但是与另一个应用程序的任何单一交互都不能实现此目标,就会出现语义不匹配。关键是,任何单一交互都不能实现所需的服务操作的目标。bookTripItineray() 操作是一个明显的例子,它可能需要多次交互,包括 takePayment()、reserveAccomodation()、bookFlight()、updateItineraryStatus() 等等。没有任何后端操作执行 “预订旅行” 这个语义。因此,某处的某个东西必须了解这些交互的含义并把它们组合在一起。因此,在 EAI 中 “集成” 包括语义和非语义操作,“集成层” 可以执行这两类操作。

在 SOA 中需要这种集成吗?绝对需要。现有的提供者有时候提供了服务规范要求的语义特征,但是不符合非语义特征。因此,引入中介来处理非语义不匹配,从而公开受治理的服务。在 SOA 和 EAI 中,必须认识到现有的提供者不总是能够提供服务规范要求的语义特征。实际上,在 SOA 发展的早期,组织把大多数时间花在定义和实现 “集成” 方面,力求从现有的提供者资产构建出服务模型。因此,实际上集成在 SOA 中的重要性不亚于在 EAI 中的重要性。

在 SOA 中如何实现集成?实际上,采用的方法与 EAI 很相似,但是有一些显著的差异;EAI 的目的是让应用程序能够与其他应用程序进行一对一的交互,而 SOA 要处理的是由所有应用程序使用的全组织范围的共享的可重用服务模型。与成熟的 EAI 一样,在 SOA 中关注点隔离是关键,因此 SOA 中的 “集成层” 可以执行语义和非语义这两类操作,但是必须在架构层面上把它们隔离开。

正如前面指出的,用于服务公开的中介只能操纵交互的非语义特征。因此,在 SOA 中服务总线只能提供集成层中的非语义 “子层”。如果现有的提供者无法满足服务规范的语义特征的要求,集成层的其他部分必须操纵语义特征。显然,服务总线并不单独构成整个集成层,至少不是符合定义的集成层。但是,因为服务总线执行集成中包含的非语义服务公开,所以它显然是集成层的组成部分,而用于服务公开的中介是集成的一种形式。为了全面,我们应该指出,在现有提供者正好匹配服务模型的语义这一很少见的情况下,可以把服务总线看作功能有限的集成层。

我们通过图 6 来详细说明它们的关系。图中顶部的服务实现与图 4 所示的相同。中介用于公开服务,是服务总线的一部分,它处理服务规范与现有提供者之间的非语义不匹配。因此,服务总线提供服务公开层,功能更全面的集成层包含服务公开层。

图 6. 集成层、中介和创建
图 6. 集成层、中介和创建
图 6. 集成层、中介和创建

现在,看一下图中底部的服务实现。本例中,现有提供者都不匹配服务规范提出的语义。通常,当业务任务的粒度比任何提供者交互的粒度都大时,会出现这种情况。创建与语义匹配的大粒度业务任务需要一系列交互,常常需要干预 “逻辑”(包括创建业务实体和执行复杂的错误处理)。这些功能与中介应该提供的功能很不一样。

需要由一个在架构上独立的层来处理这些语义工作。一般来说,这一层用小粒度的业务任务创建大粒度的业务任务。在某些上下文中,这称为服务创建,大体上就是创建以前不存在的业务任务 —— 换句话说,实现新的语义特征。更准确的说法是,这一层执行提供者创建,因为新语义一定意味着没有语义匹配的现有提供者。新的提供者不需要(甚至不能)提供服务规范中的非语义特征。

图 6 展示了集成层与服务公开层、提供者创建层、现有提供者、服务规范和服务实现的关系。此图强调中介(用于服务公开)和提供者创建都对服务实现有贡献,但是由于关注点隔离的要求,它们在架构上是分离的。一定要注意,在架构上服务总线只提供服务公开层。

现在通过研究两个场景说明服务公开与提供者创建之间的差异。

在第一个场景中(见图 7),假设一个现有提供者完全符合服务操作的服务规范的要求(业务任务、业务和技术接口、协议/格式等等),惟一的例外是需要通过 HTTPS 保护对提供者的每个请求。

图 7. 集成层中的服务公开
图 7. 集成层中的服务公开
图 7. 集成层中的服务公开

增加加密是处理服务规范的非语义特征的好例子。这个提供者实现了业务任务和大多数(但不是全部)非语义特征。中介启用 HTTPS,而不需要修改提供者。在这个场景中,中介显然不会增加语义。与前面一样,用于服务公开的中介只存在于服务总线中。

在第二个场景中(见图 8),现有提供者都不提供服务操作的服务规范中的语义特征。要想满足服务规范的语义特征,就需要与多个提供者交互,常常要使用干预逻辑。中介功能常常被利用来支持与现有提供者的交互,而不是用于服务公开。实际上,我们要把一组细粒度的业务任务组合成一个粗粒度的、符合服务操作的服务规范的业务任务。

以获取客户账户为例,您需要来自一个系统的账户信息和来自另一个系统的客户信息。没有提供者提供全部语义特征,所以显然必须通过语义活动以有意义的方式合并这些实体;这超出了服务公开的范畴,属于提供者创建的范畴。关注点隔离确保执行非语义服务公开的中介的实现独立于组合活动。

图 8. 集成层中的提供者创建和中介
图 8. 集成层中的提供者创建和中介
图 8. 集成层中的提供者创建和中介

总之,SOA 中的集成层包含纯粹非语义的服务公开子层(由服务总线模式实现)和提供者创建子层(包含丰富的语义功能)。前者总是存在,后者几乎总是存在。服务总线(也称为 ESB)本身一般不足以构成 SOA 中的集成层。

业务逻辑与集成逻辑

接下来,讨论前面的文章在集成层和服务总线的上下文中使用的术语 “业务逻辑” 和 “集成逻辑”。在本节中,我们要说明这两个术语的含义都很模糊,对于描述服务总线或集成层的性质没有帮助。我们还要推荐更有意义、更有帮助的替代术语。

前一篇文章说,“业务逻辑处理与实现业务目标相关联的语义”,而 “集成逻辑只修改与实现必要的互连相关联的语法”。根据前面对集成层和服务总线的讨论,您可以看出矛盾之处;例如,业务逻辑集成逻辑的一种形式。这个问题被过分简化了,而且缺少准确的术语。不应该把逻辑划分为业务逻辑与集成逻辑,而是应该按影响所有权分类。

逻辑影响与服务规范中的特征相关:

  • 语义影响意味着只影响语义特征。
  • 非语义影响意味着只影响非语义特征。

逻辑所有权与定义和修改逻辑的角色或组相关。在集成层中,有两个所有权角色:

  • 业务定义所有业务目标(即 “为什么”),包括语义和非语义的。业务可以定义和修改任何对实现业务目标有语义或非语义影响的逻辑。
  • IT 实现基础设施以帮助实现业务目标(即 “如何”)。IT 只能定义和修改对实现业务目标有非语义影响的逻辑。

图 9 显示由此产生的三个有效逻辑类别:业务拥有的语义逻辑、业务拥有的非语义逻辑和 IT 拥有的非语义逻辑。根据定义,IT 拥有的语义逻辑是非法的;语义涉及的是业务任务的含义。

图 9. 集成层中的逻辑
图 9. 集成层中的逻辑

显然,业务拥有的语义逻辑存在于提供者创建子层中。实际上,这个子层的目的就是引入新语义。

IT 拥有的非语义逻辑存在于中介/服务公开子层中。这包括 IT 拥有的 “策略” 或 “规则”,它们也可以根据提供者健康状态等操作因素影响路由。我们认为 IT 拥有的非语义逻辑也存在于提供者创建子层中。为什么呢?例如,假设新的提供者需要使用另一种消息格式与现有提供者交互;实现交互需要通过非语义逻辑转换消息,IT 应该拥有这些逻辑。这保持了关注点隔离。

不太显而易见的逻辑类型是业务拥有的非语义逻辑,它们存在于提供者创建子层和服务公开子层中。这种逻辑不改变基本语义,只改变非语义特征,比如基本语义中涉及的参数值。对于服务公开子层,一个例子是提供者之间的路由;可以根据业务拥有的 “策略” 或 “规则” 做出路由决策,从而为优质客户的请求提供更好的服务质量。这些是业务拥有的策略,但是它们对于满足请求的语义含义没有影响。

现在,在讨论 SOA 中的集成层时,可以更准确地表述逻辑。服务公开层中的中介只能包含非语义逻辑。这些逻辑常常是 IT 拥有的,但可以是业务拥有的。因此,中介(和服务总线)可以包含业务逻辑,但是这些逻辑只能是非语义的。提供者创建层可以包含业务拥有的语义逻辑和两类非语义逻辑。

关注不同类型的逻辑之间的差异是因为独立地实现它们是很重要的;它们需要由不同的角色更新,具有不同的更改周期,常常使用不同的工具,有不同的治理规则 —— 为了保持关注点隔离,必须隔离它们。IT 拥有的逻辑和业务拥有的逻辑之间的差异相当明显,这里提出的新观念是,在两类业务拥有的逻辑之间也应该清楚地隔离,因为它们很可能由不同的业务用户拥有和修改。

架构与实现

与前面的文章系列一样,本文讨论的是架构、架构层、架构角色和架构原则,比如关注点隔离。但是,架构不能单独提供业务价值;必须使用适当的技术或产品实现架构。接下来,讨论 SOA(尤其是集成层)的架构设计和实现。

关注点隔离对于 SOA 很重要,需要通过定义必要的架构层实现清晰的关注点隔离。因此,要定义集成层并在集成层中定义中介/服务公开子层和提供者创建子层。SOA 实现失败的常见原因之一是,没有定义有助于关注点隔离的分层的架构,导致实现不灵活且难以维护。例如,一些企业没有认识到集成层与服务总线之间的差异,因此把服务公开和提供者创建混在一起,这实际上会不适当地把业务和 IT 的职责混在一起。

但是,这并不意味着必须实现理想化的分层架构。实际上,由于性能、成本、技术限制等原因,几乎总是要做出妥协。例如,使用清晰的逻辑分层而不是物理分层可能能够改进性能。问题不是是否要妥协,而是在什么地方以什么方式做尽可能少的妥协,同时保持架构的目标,实现尽可能充分的关注点隔离。

显然,要想实现架构,就必须为每个架构层选择实现技术。对于 SOA,产品常常是专门针对某一层的。这样的产品对于处理这一层的开发、维护和运行时方面非常合适,但是对于其他层不理想。为架构层选择实现技术不但要考虑目标层的需要,还要考虑其他条件;这些条件包括技能、现有的产品、开发成本(工具会显著影响开发成本)、服务质量、总拥有成本等等。如果其他条件更重要,完全可以用一种技术实现它原本不针对的层。重要的考虑因素并不是产品与层多么匹配,而是确保在最终的解决方案中仍然能够轻松地识别出各个架构层,从而尽可能保持关注点隔离。

图 10 显示集成产品的一种非常常见的情况,包括针对服务总线 (ESB) 模式的产品。ESB 产品主要提供非语义功能,比如适应、转换、路由等等,还能够把这些基本功能依次组合起来。当然,可以使用这些功能实现服务公开层中的中介。

图 10. 架构和集成产品
图 10. 架构和集成产品
图 10. 架构和集成产品

也可以在提供者创建层中使用这些功能。但是,提供者创建层中的集成场景需要复杂的决策逻辑、异常处理和状态管理,服务总线中介流功能不是针对这些设计的。另一方面,面向业务流程的其他产品(例如 BPEL 引擎)主要提供复杂的流功能,适合处理复合的逻辑和异常逻辑,还能够保持和表示长时间运行的流程的状态。提供者创建层常常需要这些功能。正如前面提到的,服务公开层可以使用先进的功能(比如规则)提供更强的敏捷性,同时不影响语义。

例如,请考虑图 8 中的提供者创建场景。假设一个环境包含针对业务流程的 IBM WebSphere® Process Server。WebSphere Process Server 包含针对中介的 IBM WebSphere ESB。最好的解决方案是使用 WebSphere ESB 中的中介技术实现中介,这样可以利用目标环境的开发和运行时功能。WebSphere Process Server 技术非常适合创建新的提供者,因为它提供合适创建提供者的先进工具和运行时功能。但是,根据新提供者的复杂程度和开发团队的技能,也可以考虑使用 WebSphere ESB 技术创建提供者。同样,重要的目标是保持关注点隔离。

总之,要想实现成功的 SOA,必须设计出关注点隔离清晰的架构层,然后在实现层时尽可能保持关注点隔离。只要妥协是合理的而且对关注点隔离的影响最小,可以使用任何技术实现某一层,无论这种技术是否针对这一层。在建模和组合阶段进行良好的治理有助于确保适当的关注点隔离。

结束语

本文试图澄清与 SOA 架构模式企业服务总线相关的许多主题和术语,从而提高术语的准确性。实际上,我们指出了 “企业服务总线” 这个术语常常不合适,如果不太了解组织的具体情况,最好使用 “服务总线” 这个术语。尽管这么说,我们也承认 ESB 这个术语不太可能被抛弃。

我们还指出,如果没有上下文和限定,“服务” 这个术语会引起混淆,甚至导致误解。强烈建议使用 “纯逻辑的受治理服务”,这个术语更准确,但是仍然有点儿含糊。更准确的术语是,使用 “服务规范” 表示受治理服务的外部语义、句法和操作特征的形式化表示,使用 “服务实现” 表示服务规范的物理实现。

我们指出,“服务总线” 实际上是中介的集合的逻辑表示(在物理上是其容器),中介执行语义透明的 “服务公开”;也就是根据服务规范公开提供者。服务注册表和存储库为服务规范提供必需的治理(可以认为它们是服务规范的容器)。

我们指出,服务总线并不是完整的集成层,至少不是 EAI 风格的集成层(这样的集成层要执行语义和非语义两类操作)。中介是集成的一种形式,服务总线提供 SOA 集成层中的非语义 “服务公开” 子层。SOA 中的集成层还包含 “提供者创建” 子层,它负责用一个或多个小粒度的提供者创建大粒度的提供者。

我们指出了如何更准确地表述 SOA 集成层中的 “逻辑”。“业务逻辑” 和 “集成逻辑” 这两个术语会导致混淆,更准确的术语是业务拥有的语义逻辑、业务拥有的非语义逻辑和 IT 拥有的非语义逻辑。服务公开层只能包含非语义逻辑,但是其中包括业务拥有的非语义逻辑,因此在服务总线 (ESB) 中可以有业务逻辑。

我们指出,要想实现成功的 SOA,应该先设计出保证关注点隔离所需的层,然后为每一层选择实现技术,尽可能只做必要的妥协,从而保持关注点隔离。我们还指出,针对某一架构层的产品也可以用于其他层,只要保持关注点隔离即可。

致谢

作者要感谢以下各位对本文所做的贡献:Andy Garratt、Guy Hochstetler、Andy Humphreys、Brian Petrini、Rachel Reinitz、Marc-Thomas Schmidt 和 Andre Tost。


相关主题


评论

添加或订阅评论,请先登录注册

static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=10
Zone=WebSphere
ArticleID=682035
ArticleTitle=再论企业服务总线
publish-date=06232011