亲亲宝宝

什么让解决方案具有面向服务的特征？

SOA 处理解决方案规范和实现的方法不是指定和实现新代码，而更多的是通过现有解决方案得到新的解决方案。在本文的讨论中，我们将解决方案称为“系统”。

事实上，可以将考虑的事项归为两个主要部分：向用户提供行为的面向服务的系统和组成这些系统的各个部件。

为了对一些定义进行简化，让我们首先看看系统和部件这两个词的一般含义：

* 系统：事物（部件）的集合或组合，形成复杂或单一的整体
* 部件：属于整体的独立或明确的部分

为了进一步深入讨论，让我们看看取自“现实世界”的非软件示例：汽车就是由不同部件（车轮、发动机、底盘、车门等）组成的系统。

其中的每个部件都具有明确的差别，按照定义良好的方式组装到一起后，就形成了一个新的实体，即汽车。汽车中的每个部件都扮演着高度专门化的角色。汽车制造商经常会在多款不同型号的车辆（系统）中使用相同的部件。例如，里程表部件可以组装到赛车和越野车中。之所以可以这样做，是因为部件经过精心设计，使其能够在多重组装上下文（多种车型）中以个体的方式加以重用。如果里程表和仪表盘作为一个原子部件提供，则会减少该部件在不同的车型间进行重用的几率。当将部件组装为汽车后，新的实体（汽车）由多个独立部件组成这一事实将不再重要，直到某个部件出现错误而需要替换才会引起注意。或者，直到购买了其他部件并添加到车上来扩展其功能时才会引起注意——驾驶员听 CD 时使用的 CD 播放器或帮助驾驶员在不熟悉的路上驾驶的 GPS。

在我们所述的这个例子中，部件 这个词具有两种使用方式，这两种使用方式具有一些细微差别：

1. 现有车辆的部件，或整体的部件
2. 可以用于制造新车或添加到现有车辆的部件。

下面的图 1 将上面示例中的这些概念对应到了 SOA 世界的类似概念。请注意，尽管并非这里所使用的所有术语都是“正式”术语，但它们能够帮助我们对 SOA 一些有意义的方面进行讨论。

图 1. 在汽车和面向服务的系统之间的对应关系
在汽车和面向服务的系统之间的对应关系

接下来让我们对图中的几个词进行说明，以便了解其中所体现出来的关系：

* 汽车 映射到面向服务的系统（Srvice-Oriented system，SO system）。此术语用于描述单个面向服务的解决方案，解决方案由一组部件组装而成。
* 汽车的部件（图中为一个后视镜）映射到 SO 系统部件。此术语用于描述面向服务的解决方案整体中的单个部件。
* 汽车部件 映射到面向服务的部件。这是面向服务的软件的个体组成部分，能够与其他面向服务的部件组装为面向服务的解决方案。请注意，虽然 SO 系统与其所属的 SO 解决方案具有相同的生命周期，但面向服务的部件具有自己的生命周期。

接下来让我们对面向服务的部件进行进一步讨论。

顾名思义，这些部件的本质是面向服务的概念。SOA 治理插件（请参见参考资料部分）为我们提供了服务的定义：“服务是执行可重复任务的可发现资源，由外部化的服务规范进行描述。”这个本质表明部件将提供或使用服务。因此我们将讨论两种不同类型的面向服务的部件：服务使用者 和服务提供者。

图 2. 两种面向服务的部件类型
两种面向服务的部件类型

服务使用者

服务使用者是仅仅使用服务的面向服务的部件类型——其本身并不提供任何服务。服务使用者充当系统外实体的代理，如人员或其他系统（请参见参考资料部分列出的“组件业务模型”），是访问系统提供的功能的入口。用户界面就是这方面的例子，其中外部实体为用户或软件适配器（为其他系统的情况下）。尽管它们本身并不实际提供服务，但服务使用者扮演着重要的角色，如果没有它们，系统就断绝了与外部世界的联系。

服务提供者

服务提供者提供一个或多个服务，而且也可能和服务使用者一样使用服务。服务提供者提供系统的功能。如果服务“执行可重复任务”，则服务提供者就是执行这个可重复任务的部分。请注意，服务提供者可能提供多个服务。这非常重要，因为有一个特殊的事实只有在两个服务均由相同服务提供者提供时才成立，而在属于不同的服务提供者时则不成立。这就是，相同服务提供者提供的服务的实现可以共享内部细节（最重要的是内部数据）。

因此，我们为服务提供者划定的边界非常重要，因为这将限制其提供的服务的可能性。如果存在由两个服务管理的相关表格，而且希望第一个服务上的特定操作能直接访问第二个服务管理的表，则这两个服务需要位于相同的服务提供者中。如果位于独立的服务提供者上，则第一个服务的实现将仅能通过服务本身访问第二个服务的数据。

通常，您将总是希望使用服务访问数据。不过，我们这里所指出的是，位于相同服务提供者上的多个服务能够共享对相同的表格集合的直接访问。因此，如果您拥有相同服务提供者提供的 OrderService 和 OrderLineService，则 OrderService 可以直接访问关于订单行的某些信息，如订单的行号等，而不用对 OrderLineService 本身进行服务操作调用。同样，对 OrderLineService 的调用也能返回一些基本订单信息，因此 OrderLineService 实现不用对 OrderService 进行调用。

为何企业级别的视角对 SOA 非常重要？

回到“现实世界”的真实类比汽车上，如果您在设计一款独特的定制一次性汽车，则将会采用与为汽车制造商设计一系列车型时不同的态度处理各个部件。同样，这主要是因为您希望在多个不同的车型间重用相同的部件。我们可以看到，这只会因为命题的规模（单个车型与一系列车型）而变得重要。

类似地，在设计整个企业中的多个面向服务 (SO) 的解决方案时，您需要采取与设计单个 SO 解决方案不同的思维方式。我们在讨论“采取企业级别的视角”时讨论的就是这种思维方式。务必确保这一点，即各个面向服务的部件所采用的形式必须能够允许其在整个企业中的多个 SO 解决方案中使用。

下面我们将给出企业级别视角的四个不同方面：创建业务模型上下文、对体系结构模式进行标准化、对实现框架和运行时平台进行标准化以及采用基于资产的开发原则。

建模业务上下文

在本系列的第 2 部分，我们介绍了组件业务建模（Component Business Modeling，CBM）。下面让我们对此进行一下回顾：企业级别的业务模型提供非常重要的上下文，将根据其形成我们的 IT 系统的框架。IBM 提出了名为组件业务建模 (CBM) 的战略方法，可通过其获得业务体系结构，其中将企业这个整体划分为了一系列业务组件。

此方法将产生一个业务模型，其中将企业描述为一组业务组件，其中每个组件都是具有自主运作的有潜能的企业（例如，作为独立公司或作为其他公司的一部分）的一部分。

业务组件的细节通过以下术语描述：

* 人员：人员在业务组件的上下文中扮演的业务角色。
* 流程：业务组件所涉及到的业务流程。
* 技术：业务组件所拥有的 IT 系统。

图 3 重新给出了我们在本系列的第 2 部分给出的业务体系结构图。请注意，其中的业务组件按责任级别（行）和业务领域（列）组织。

图 3. 业务体系结构图中的业务组件
业务体系结构图中的业务组件

此类业务模型描述的业务体系结构类型可为我们的 SO 系统提供非常宝贵的上下文。企业中现有的或将要出现的 IT 系统集可以放入其支持的业务组件上下文中。而且，业务组件的业务流程应该准确地表明这些业务流程的何处将使用 SO 系统。

这是将 IT 部门负责的软件与其支持业务进行相关的一个重要机制。在企业级业务模型上下文中考虑这些系统，可在其支持的业务组件的上下文中考虑这些系统，从而防止 IT 系统之间出现功能重叠。

业务领域中要进行建模的另一个极为重要的方面（我们绝对没有过分强调其重要性）是业务信息。也就是说，对于每个业务领域，业务中属于该领域的人员日常处理事务的一部分的重要内容有哪些？这些可以是物理事项（如 products）或逻辑事项（如 orders）的组合。拥有业务信息及其在企业中的结构方式（不包括逻辑方式；例如，我们这里不会讨论数据库表）的清晰视图，对于负责标识整个组织中的软件服务的 IT 架构师非常重要。

我们向您推荐 developerWorks 上的一篇教程“Model Service-Oriented Architectures with Rational Software Architect: Part 2. Modeling the business domain”（请参见参考资料部分提供的链接），其中提供了领域建模的详细处理方法。本系列后面的教程将详细地说明如何从此领域模型派生出体系结构中的部件。

对体系结构模式进行标准化

确保为解决方案指定的部件具有多个解决方案间的通用重用性的最重要方法是，在整个企业中应用一组一致的体系结构模式。体系结构模式是软件模式，可提供对软件工程中的体系结构问题的良好解决方案。它们给出了软件的基本组织模式。也就是说，它们提供了创建您的 SO 系统以及作为其组装元素的面向服务的部件的规则。

务必在整个企业都采用相同的模式。这将增加为 SO 系统创建的部件的可重用性，能在以后与其他部件结合（组装到一起）形成新的面向服务的解决方案。通过这样，企业中面向服务的软件的百分比将随着时间的增加而增加，而不必在以后重新进行体系结构设计或重构。

IBM 红皮书第 4 章“Building SOA Solutions using the Rational SDP”的“Reusing architecture and design experience”部分（请参见参考资料部分提供的链接）给出了体系结构模式的一组示例。这些模式正式化为一组规则，用于将解决方案中的功能构建为一组部件。其中对将功能构建为可执行流程、组合服务和原子服务进行了特别关注。

对编程模型进行标准化

整个企业内的体系结构模式的一致应用将会帮助您以事半功倍的方式创建具有通用重用性的面向服务的部件。您可能会应用相同的体系结构模式来创建两个服务提供者，然后却因为集成框架或运行时平台中的不兼容性无法将其组装到相同的面向服务的解决方案中。

应该引入标准化编程模型来避免技术不兼容性问题。请注意，我们讨论的不是必须采用某种编程语言（如 Java™）、某个实现框架（如 J2EE）或绑定机制（如 SOAP）来实现标准化。相反，我们讨论的是关注服务组件间的集成点的编程模型，如基于服务组件体系结构（Service Component Architecture，SCA）和服务数据对象（Service Data Objects，SDO）标准的编程模型。SCA 和 SDO 专门设计用于支持服务组件间的互操作性，以便能在不用更改服务组件的基本结构的情况下更改服务绑定和服务实现。

我们在参考资料部分提供了指向 SCA 和 SDO 的更多信息的链接。

采用基于资产的开发原则

创建具有通用可重用性的面向服务的部件可在重用这些部件时提供最大的好处。不过，仅仅创建这些部件并不能保证其可重用性。这里还需要采用有组织的资产治理和在整个生命周期中支持资产的工作流：规范、产生和使用。这些关键工作流的视图如图 4 中所示。

图 4. 基于资产的开发活动
基于资产的开发活动

面向服务的部件应该作为资产指定、产生、管理和使用。产生之后，应将其发布到资产存储库，并提供可搜索元数据，以便能找到和使用这些资产。这个做法需要在整个企业范围内采用（组织资产治理），以实现最大的好处。

本系列中的下一部分（第 4 部分）将介绍支持资产生命周期的一个重要 IBM 产品：IBM Rational® Asset Manager (RAM)。

总结

在本文中，我们了解了什么让解决方案具有面向服务的特征以及其实际意义。我们了解了面向服务的体系结构中的不同部件类型。最后，我们了解了在从企业的角度看待 SOA 时要考虑的四个不同方面的更多信息：创建业务模型上下文、对体系结构模式进行标准化、对编程模型进行标准化以及采用基于资产的开发原则。