面向服务的体系结构(SOA)和 Web 服务的基本观念是成为我们日常语言的一部分，并可看作是适于设计现代企业应用程序的体系结构形式。在这种背景下， 什么构成好的服务这个基本问题就成为确保成功实现 SOA 的关键。

　　像 面向对象的分析与设计(Object-Oriented Analysis and Design，OOAD)、 企业体系结构(Enterprise Architecture，EA)框架和 业务流程建模(Business Process Modeling，BPM)这样的现有建模规则为我们提供了高质量的实践，可以长期帮助标识和定义体系结构内的适当抽象。然而经验表明，这些实践各自单独应用时达不到要求。

　　在本文中，我们将研究 OOAD、EA 和 BPM 中的适当原理。我们还将推动对混合方法的需求，这种方法把所有这些规则中的原理与许多独特的新原理组合起来。这样得到的交叉学科 OOAD 方法使成功地进行 SOA 开发更容易，我们称之为 面向服务的分析与设计(Service-Oriented Analysis and Design，SOAD)，它还有待正式定义。我们还只是刚刚跨入 SOAD 的殿堂。

　　面向服务的概念

　　在发现新的商机或威胁的预期下，SOA 体系结构形式旨在提供企业业务解决方案，这些业务解决方案可以 按需扩展或改变。SOA 解决方案由可重用的服务组成，带有定义良好且符合标准的已发布接口。SOA 提供了一种机制，通过这种机制，可以集成现有的遗留应用程序，而不管它们的平台或语言。

　　从概念上讲，SOA 中有三个主要的抽象级别：

• 　　操作：代表单个逻辑工作单元(LUW)的事务。执行操作通常会导致读、写或修改一个或多个持久性数据。SOA 操作可以直接与面向对象 (OO) 的方法相比。它们都有特定的结构化接口，并且返回结构化的响应。完全同方法一样，特定操作的执行可能涉及调用附加的操作。
• 　　服务：代表操作的逻辑分组。例如，如果我们将 CustomerProfiling视为服务，则 按照电话号码查找客户、 按照名称和邮政编码列出顾客和 保存新客户的数据就代表相关的操作。
• 　　业务流程：为实现特定业务目标而执行的一组长期运行的动作或活动。业务流程通常包括多个业务调用。业务流程的例子有： 接纳新员工、 出售产品或服务和 完成订单。

　　在 SOA 术语中，业务流程包括依据一组业务规则按照有序序列执行的一系列操作。操作的排序、选择和执行称为服务或流程 编排。典型的情况是调用已编排服务来响应业务事件。

　　从建模的观点来看，由此带来的挑战是如何描述设计良好的操作、服务和流程抽象的特征以及如何系统地构造它们。这些相关问题都是当前行业内和学术界最常讨论的问题。据我们所知，最近几乎所有的 SOA 项目或专题研讨会都将这样的服务建模方面作为重要的主题，并引起了许多的争论。因此，让我们更近地作一番审视。

　　为什么 BPM、EA 和 OOAD 还不够?

　　早期的 SOA 实现项目经验表明，诸如 OOAD、EA 和 BPM 这样的现有开发流程和表示法仅仅涵盖支持 SOA 范式所需的部分要求。SOA 方法在加强已经制定的良好通用软件体系结构原则(如信息隐藏、模块化和问题分离)的同时，还增添了附加的主题，例如， 服务编排、 服务库和 服务总线中间件模式，在建模时需要对它们给予特别的关注。

　　图 1展示了现有的 EA、BPM 和 OOAD 建模方法的主要应用领域，也是我们随后讨论 SOAD 的出发点。图中的水平轴表示 项目生命周期阶段;垂直轴表示不同抽象层或 领域之间的区别，而建模活动通常就是在其上进行的。

　　图 1. BPM、EA 和 OOAD 的位置

　　

　　SOA 的远景是相当容易理解的，因为它的技术基础众所周知。例如，在任何 SOA 工作中，应用通用的软件体系结构原则和 OO 技术都是一个有效的开端。然而，正如我们已经提到的，早期采用者最常询问的问题是如何标识正确的服务。如前所述，OOAD、EA 和 BPM 在各自独立地应用时不能提供满意的答案，而这正是我们现在要说明的。

　　在由 Booch 和 Jacobson撰写的开创性的书(大约 10 年前出版的)中介绍的 OOAD 方法在定义 SOA 方面提供了非常好的起点。同样地，虽然许多年来在体系结构层次中应用 OOAD 技术和统一建模语言(Unified Modeling Language，UML)表示法是一个常见的实践，但是 OOAD 还是与像类和单独的对象实例这样的微观层次的抽象有关。由于每个问题域常常都创建单独的用况模型，因此，应用程序开发项目，这个企业的大方向在许多情况下变得模糊。此外，由于种种原因，用况模型并不总是与其对等的 BPM 保持同步。

　　诸如 Treasury 企业体系结构框架(Treasury Enterprise Architecture Framework，TEAF)、 面向特征的领域分析(Feature-Oriented Domain Analysis，FODA)和 Zachman这样的 EA 方法都将城市规划级的观点加在解决方案体系结构之上，但是并没有解决如何找到易于重用且具有持久性的高质量企业抽象的问题。

　　虽然 BPM 方法(如 BPMI)在功能工作单元之上提供了端到端视图，但是它们通常都没有触及体系结构和实现领域。例如，在像 用于 Web 服务的业务流程执行语言(Business Process Execution Language for Web Services，BPEL)这样的语言出现之前，BPM 表示法缺少操作语义。此外，我们还看到了许多流程建模与开发活动彼此分离的情况。

　　最后，现有的规则中没有一个可以解决如何为 SOA 启用 现有的应用程序的问题;大部分时间都采用自顶向下流程。现有的系统通常都存放有大量的重要数据和业务逻辑，并且不能简单地加以替代。因此，为了研究包装和重构策略，必须对这些系统进行自底向上的分析。因此，对现有应用程序的考虑会将我们带到中间相遇的流程。

　　由于这些原因的存在，所以需要混合 SOAD 建模方法。这种方法以最佳的方式组合了 OOAD、BPM 和 EA 中的原理，并且融入了一些具有创新性的原理。 图 2展示了这种新的方法的 SOAD 资源(原理和技术)：

　　图 2. SOAD 及其组成部分：OOAD、BPM 和 EA

　　

　　EA

　　将企业应用程序和 IT 基础设施发展成 SOA 可能是一个大的负担，会影响多个业务线和组织单元。因此，需要应用 EA 框架和参考体系结构(如 开放组织体系结构框架(The Open Group Architecture Framework，TOGAF))以及 Zachman，以努力实现单独的解决方案之间体系结构的一致性。

　　根据过去的经验，大多数现有的 EA 框架都在一个或多个方面有限制。例如，如果主要的问题是表示技术设备的低级构块如何在宏观层次互连，则无法获得业务层流程或服务视图。然而，在 SOA 的背景下，这种考虑问题的方式必须转换为以表示业务服务的逻辑构件为中心，并且集中于定义服务之间的接口和 服务级协定(Service Level Agreements，SLA)。

　　此外，许多企业级参考体系结构和框架是相当普通的，并没有触及设计领域。这样的高级体系结构无法为架构师和开发人员提供具体的战术意见，并且常常导致企业体系结构和解决方案体系结构之间出现根本性的分歧。

　　SOAD 必须帮助 SOA 架构师定义服务前景的整体业务级视图。这是当今的 EA 框架所无法提供的，它们需要未来特定于 SOA 的增强; 按需操作系统(On Demand Operating Environment，ODOE) 是 IBM 针对这种趋势制定的主要战略。

　　BPM

　　BPM 是一个不完整的规则，其中有许多不同的形式、表示法和资源。另一种常用的技术是定义表示概念性流程流的 事件驱动流程链，正如 Barker 和 Longman所定义的。这第二种技术使用了不同于 UML 的表示法。

　　此外，还有许多专用方法(如 BPM 技术)可能被咨询公司和企业资源规划(Enterprise Resource Planning，ERP)软件包厂商视为具有竞争优势。ARIS Implementation Platform 就是这样的产品的一个例子。其他的方法包括： Line of Visibility Enterprise Modeling(LOVEM) 和 IBM 的组件业务建模(Component Business Modeling，CBM)战略。

　　最近的趋势是定义表示可执行流模型(如 用于 Web 服务的业务流程执行语言(Business Process Execution Language for Web Services，BPEL) )的标准方法。BPEL 将流程的范围从分析扩展到实现。这样的可执行模型引发了一系列的新问题，其中包括：

• 　　哪些方面应该用 BPEL 描述，哪些方面应该用 WSDL 描述?流程模型和传统的编程模型之间的区别在什么地方?
• 　　如何将非功能性要求和服务质量特征这样的方面加入模型之中?
• 　　同更传统的编码(例如在 J2EE 中)相比，在 BPEL 引擎的编程语言扩展中执行多少逻辑?
• 　　如何评定可执行流程模型的质量，其应用的最佳实践是什么?
• 　　什么工作角色进行 BPEL 流管理;是业务专家(分析人员)，还是开发角色(软件架构师)?

　　必须利用所有现有的 BPM 方法作为 SOAD 的起点;然而，必须使用流程模型中用于驱动 候选服务和它们的操作的附加技术来对其加以补充。此外，SOAD 中的流程建模必须与设计层用况建模保持同步，并且必须给出与 BPEL 有关的问题的答案。

OO 范式与面向服务 (SO) 范式

 

　　OO 分析是一种非常强大且广为赞誉的方法，同样，SOAD 应该尽可能多地利用 OO 分析技术。要将 OO 分析成功地应用于 SOA 项目，您就必须一次分析多个系统。用况模型必须继续扮演重要的角色。然而，SOAD 必须主要是 流程，而不是 用户驱动的。因此，SOAD 需要 BPM 和用况建模活动之间的强链接。

　　在 设计层，OO 的目标是能够进行快速而有效的设计、开发以及执行灵活且可扩展的应用程序。对象是软件构造，其行为就像它们建模的真实世界的实体。例如，顾客 (Customer) 将有名称和联系信息，并且还可能有一个或多个与之相关的帐户对象。从 OO 的角度看，每件事情都是对象。

　　OO的基本原则是：

• 　　封装：软件对象就是包含模拟真实世界的对象的物理属性(数据)和功能(行为)的离散包。例如，帐户对象保持收支平衡并且包含平衡中的借贷机制。
• 　　信息隐藏：结构良好的对象有简单的接口，并且不向外界显漏任何内部机制。真实世界信息隐藏的例子是，您不需要详细了解汽车的工作原理就能够驾驶它。
• 　　类和实例： 类是定义特定类型的软件对象具有什么类型的属性和行为的模板，而 实例是具有这些属性值的个别对象。创建类的新实例称为 实例化。利用生物学进行类比，人就是一个类。所有的人都具有一些属性，比如身高、体重、头发和眼睛颜色等等。我们中的每个人都是这个类 HumanBeing 的实例，具有一些特定的身高、体重以及其他的属性值。类是一直存在的，而实例具有有限的生命周期。
• 　　关联和继承：在 OO 中，表达类和对象之间的关联的能力是一个关键的概念;继承是关联的强形式，用于表达有关系：按照同样的方式，生物物种由这样的层次构成：界 (Kingdom)、门 (Phylum)、纲 (Class)、目 (Order)、科 (Family)、类 (Genus)、种 (Species)。我们常常发现软件对象的自然层次。例如，当您创建一个财务应用程序实体时，您可能需要构造像 经常帐户(CheckingAccount) 、 储蓄帐户(SavingsAccount) 和 贷款帐户(LoanAccount) 这样的对象。如果您看得更仔细一点(请参见 图 3)，您将发现这些类共享许多属性，比如都有收支平衡帐户、借方帐户和贷方帐户等等

　　图 3. UML 类继承示例

　　

　　与其重复定义和管理这些属性的代码，不如创建一个通用的 帐户(Account) 类，该类具有现金收支平衡并且可以处理借贷事务。所有其他的类都是这个 帐户(Account) 对象的专门形式。例如， 贷款帐户(LoanAccount) 将在零和某个约定的最大值之间具有负平衡，而 储蓄帐户(SavingsAccount) 将具有负平衡，并且将展示增加利息的行为，等等。

　　消息传递：为了完成一些有用的工作，软件对象需要相互通信。它们通过相互发送消息来这样做。例如，假定我们想将 00 从经常帐户转到储蓄帐户，要达到此目的，可以将带有参数 00 的 借消息发送到 经常帐户(CheckingAccount) 实例，并且将相应的 贷消息发送到 储蓄帐户(SavingsAccount) 实例。当实例接收消息时，它执行相应的功能，称为 方法，它有与消息相同的名称。

　　多态：这个术语描述两个或两个以上的类接受相同的消息但是以不同的方式进行实现的情况。例如， 自由经常帐户(FreeCheckingAccount) 实例和 经常帐户(CheckingAccount) 实例将响应 借 (0) 消息，但是 自由经常帐户(FreeCheckingAccount) 实例将正好 00 记入它的帐户平衡的借方，而 经常帐户(CheckingAccount) 实例将 00 加上交易费记入它的帐户平衡的借方。

　　OO 支持应用程序分析、设计和开发的完整生命周期：

　　OOAD试图找到最优的对象和最自然的类继承来实现它们。

　　OO 开发集中于应用程序的渐进式开发，每次实现一个业务场景或用况。像 IBM WebSphere Studio Application Developer 这样的工具有助于开发人员快速地构造和测试 OO 应用程序。

　　OO 运行时环境，例如由 Java 虚拟机提供的，提供应用程序服务(如垃圾收集(删除因使用它们的对象已经被丢弃而不再使用的资源))以及框架(如 J2EE)来为驻留在不同的服务器上的对象提供相互通信的机制。

　　目前与 SO 有关的 OO 设计实践的主要问题在于，它的粒度级别集中在类级，对于业务服务建模来说，这样的抽象级别太低了。诸如继承这样的强关联产生了相关方之间一定程度的 紧耦合(因而具有依赖性)。与此相反，SO 范式试图通过 松耦合来促进灵活性和敏捷性。目前，在 SOA 中还没有服务 实例的跨平台继承支持和一流的表示法来避免需要处理服务生命周期维护管理问题(如远程垃圾收集)。

　　这些考虑事项使 OO 难以与 SO 体系结构样式直接保持一致。然而，对于设计已定义的服务中的底层类和组件结构，OO 仍然是一种有价值的方法。此外，许多 OOAD 技术(例如类、责任、协作(CRC)卡)也可以用于服务建模(如果它们提升到更高层次的抽象的话)。在本文后面，我们将回过头来讨论这一点。

　　图 4展示了可见性层次和 OO、 面向组件和 SO 设计提供的重点之间的对应关系。它还展示了在 SOA 和 SOAD 背景中它们之间的相互关系。

　　图 4. 设计层次

　　

　　至于表示法，统一建模语言(Unified Modeling Language，UML)——通过一些附加的定型(Stereotype)和概要加以增强——自然成为 SOAD 的重要基础。

　　在使用 Rational Unified Process (RUP)——被认为是支持迭代软件开发的分析与设计的主流 OOAD 流程之一——的流程方面，使用 UML 模型具有首要价值。然而，RUP 以 OOAD 的原则为基础，因而使其不容易与 SOA 设计保持一致。从 RUP 的角度来看，系统的体系结构是其通过已定义接口交互的主要组件的体系结构。此外，这些组件还由逐渐减小到类级粒度的更小组件组成。相反，在 SOA 中，系统的体系结构通常包括满足普通 业务服务需要的无状态、全封装且自描述的服务组成，它更接近于映射到 BPM，如 图 5所示。

　　图 5. SOAD 服务定义层次

　　

　　这些服务可能包括许多协作或编排服务。这并没有排除 RUP 采用的 OO 观点，而是在其上实现了另一个抽象层。这个超层的作用是封装作为正式的跨层接口结构中的 RUP 构件( 软件服务)设计的组件。

SOAD 原理

 

　　在这一部分中，我们将更详细地描述 SOAD 的需求，并且开始确定它的主题和原理。目的是将关于这个主题的讨论引到进一步的设计工作。进一步的工作无疑需要形式化 SOAD 方法。

　　SOAD 必须提供什么?

　　已经为 SOAD 确定了下列需求：

　　正如任何其他的项目和方法一样，必须正式(至少半正式)地定义 流程和 表示法。通过选择和组合 OOAD、BPM 和 EA 原理，就可以在需要时确定额外的原理。

　　必须有结构化的方法来概念化服务：

　　OOAD 为我们提供了应用程序层上的类和对象，而 BPM 具有事件驱动的流程模型。SOAD 需要将它们结合在一起。

　　方法不再是面向用况的，而是由业务事件和流程驱动的。用况建模是在更低的层次上作为第二步进行的。

　　方法包括语法、语义和策略。这就需要特别的组合、语义代理和运行时发现。

　　SOAD 必须提供定义良好的品质因素和最佳实践(例如回答粒度问题)。必须回答 BPEL 提出的角色问题。例如，谁为哪部分工作负责：是开发人员、架构师，还是分析人员?

　　SOAD 活动还必须回答这样的问题：什么 不是好的服务?例如：不可重用的任何东西都不可能成为好的一流 SOA 成员(即服务)。另一个例子就是带有挑战性的非功能要求的嵌入式实时系统，它们不能承受任何 XML 处理开销。

　　SOAD 必须易于进行端到端建模，并且有全面的工具支持。假如 SOA 给业务带来了灵活性和敏捷性，就应该对从企业到体系结构和应用程序设计领域产生的支持方法有相同的期望。

　　品质因素

　　一些通用原则或品质因素已经确定，并且可以作为 SOAD 中的设计基准：

• 　　构思良好的服务给业务带来了灵活性和敏捷性;它们通过松散耦合、封装和信息隐藏使重构更加容易。
• 　　设计良好的服务是有意义的，并且不只适用于企业应用程序;服务之间的依赖性减到最少，并且是显式声明的。
• 　　服务抽象是内聚、完整和一致的;例如，在设计服务和它们的操作签名时应该考虑 创建(Create)、 读取(Read)、 更新(Update)、 删除(Delete)和 搜索(Search)(CRUDS) 隐喻。

　　常常声明的假定是，服务是无状态的(例如非对话式的);为了要求服务在特定的问题域和上下文中是无状态的，将削弱这种声明。

　　领域专家无需深奥的专业知识就可以理解服务命名。

　　在 SOA 中，所有的服务都遵循相同的设计体系(通过模式和模板连接的)和交互模式;底层体系结构形式可以容易地标识(例如在体系结构复审期间)。

　　服务和服务使用者的开发除了领域知识之外只需要基本的编程语言技能;中间件专业知识只有少数的专业人员才需要，在理想的情况下，这种知识是为工具和运行时厂商所用，而不是为制作像 SOA 这样的企业应用程序的公司所用。

　　服务标识和定义

　　自顶向下的业务级建模技术(如 CBM)可以为 SOA 建模活动提供起点。但是正如我们在前面提到的，SOA 实现很少是在全新的项目中开始的;创建 SOA 解决方案几乎总需要涉及集成现有的遗留系统，方法是将它们分解成服务、操作、业务流程和业务规则(同时参见 图 6)：

　　将现有的应用程序和厂商软件包分解成表示相关操作组的离散服务集(自底向上方法)。

　　从应用程序中将业务流程和规则抽象为由业务编排模型管理的单独 BPM。

　　图 6. 服务分解

　　

　　所有的 OOAD 都同标识和定义服务有关;但是还需要具有更高层的观点。此外，当 SOA 致力于比经典开发项目层次更高的开发时，就有了发挥其他创造性思维的空间。

　　直接和间接业务分析

　　通过项目相关人员的会谈和 CBM 来进行 BPM 和 直接需求分析是一个容易理解且非常合适的标识候选服务的方法。

　　过去的经验表明，这条主要的途径应该通过补充 间接技术来加以改进。在选择候选服务时，产品经理和其他业务领导应该进行协商。例如，什么是计划付款和开票模型?应该商议假定使用正在构建中的系统的企业的组织结构图。建议还考虑一下非 SOA 项目中任何现有的用况模型。用于对正在构造的系统进行营销介绍的术语是另一个很好的关于服务操作候选者的来源(特别是动词，很少关注营销动词!)。

　　域分解

　　在 Endrei中定义的域分解、子系统分析、目标模型创建和相关技术是 SOA 流程构造方法或 服务概念化框架(它是基于 Levi and Arsanjani先前完成的工作构建的)最有希望的提议。来自 SEI的 FODA 工作也为这方面的讨论做出了贡献。

　　服务粒度

　　选择正确的抽象级别是服务建模的一个关键问题。您常常会听到 进行粗粒度建模的建议。这有点过于简单化了。您应该将其改为在不损失或损害相关性、一致性和完整性的情况下 尽可能地进行粗粒度建模。在任何 SOA 中，都有细粒度服务抽象的空间(假定有业务要求的话)。由于 SOA 并不等同于 Web 服务和 SOAP，因此可以使用不同的协议绑定来访问抽象级别不同的服务。另一种选择就是将一些相关的服务捆绑成粗粒度的服务定义，这是门面模式的变种。

　　命名约定

　　应该定义企业命名模式(XML 名称空间、Java 包名、Internet 域)。简单的例子就是始终用名词来命名服务，而用动词来命名操作。这种最佳实践来源于 OOAD 空间。

第一类 SOAD 原理

 

　　除了组合 OOAD、BPM 和 EA 技术之外，还有几个重要的 SOAD 概念和方面有待充实：

• 　　服务分类和聚合
• 　　策略和方面
• 　　中间相遇流程
• 　　语义代理
• 　　服务获取和知识代理

　　服务分类和聚合

　　服务有不同的用法和用途;例如，软件服务可以不同于业务服务(如前面的 图 5所示)。此外，还可以将原子服务编排成级别更高、功能齐全的服务。

　　服务组合可以通过可执行模型(如 BPEL 建模的模型)来加以简化;这是传统的建模工具和方法不能处理的事情。

　　策略和方面

　　服务具有语法、语义和 QoS 特征，所有这些都必须进行建模;正式的接口契约必须涵盖的比 Web 服务描述语言(Web Services Description Language，WSDL)的多。因此， Web 服务策略(WS-Policy) 框架是一个重要的相关规范。

　　除了已经制定的良好 体系结构可跟踪性原则之外， 业务可跟踪性也是一个理想的品质：应该有可能将所有的运行时构件直接与非技术领域专家可以理解的语言联系起来。这对于直接在业务和服务层公开的抽象非常重要。Sarbanes-Oxley (SOX) 法案是需要这种业务可跟踪性的业务驱动程序的一个例子。

　　流程：中间相遇

　　在真实世界中，并没有全新的项目，必须始终考虑遗留系统( 遗留系统是现有系统的同义词)。因此，需要 中间相遇的方法，而不是单纯的自顶向下或自底向上的流程。

　　在设计取决于现有的 IT 环境而不是现在和将来的业务需要的情况下，自底向上的方法往往会导致不好的业务服务抽象。而自顶向下的方法可能会产生不足的非功能性需求特征，并且损害其他的体系结构品质因素(例如因域模型中缺乏标准化而导致的性能问题)，另外，也会在服务和组件中产生不匹配的不良问题。

　　服务获取和知识代理

　　这是一个知识管理和生命周期问题：如何成功地准备好服务并且使其在概念化之后可以重用?

　　应该将重用看作是标识和定义服务最主要的推动标准之一。如果组件(或服务)不可能重用，就不无法将其作为服务进行部署。它可以连接到另一个与企业体系结构相关的服务，但是不能单独作为一个服务而存在。

　　然而，即使从开始就计划好了重用，还必须形式化服务获取流程。由多个使用者使用服务是明确的 SOA 设计目标。构建时服务注册中心(例如企业 UDDI 目录)可能能够解决部分问题。

　　示例：汽车工作订单

　　汽车工作订单(Automotive Work Order)描述了一家汽车维修公司管理其顾客运营的流程。我们将通过这个领域中的问题来阐述 SOAD 的观点。

　　工作订单代表汽车服务公司和顾客之间的约定，以进行一系列例行维修或应急维修，例如例行 50,000 英里服务，更换刹车片或轮胎，或者换油。

　　业务场景(如 图 7所示)如下：

• 　　当顾客打电话预约时创建工作订单。
• 　　为每个计划的维修活动或操作创建一个独立的工作订单项，其中包括需要使用的零件、备件和劳务的详细情况。
• 　　在安排预约之前确保所有必需的零件都有库存。
• 　　需要为每个工作订单项安排具有适当的装备的维修间以及具备适当的条件的机器。
• 　　计算估计的总成本，接着顾客认可该预约;或者方案终止，随即取消工作订单。
• 　　在预约之前，立即在选定的维修间装配必需的零件、备件、工具和设备。
• 　　当顾客到达时，进行计划的活动以及在检查交通工具时显得有必要的任何其他活动。
• 　　记录所用的零件和备件的实际价值以及劳务。
• 　　在完成所有的维修时计算总费用。
• 　　创建发票并且将其交给顾客。

　　图 7. 工作订单的宏流示例

　　

　　如果您将此作为一个独立的应用程序从头开始创建，您就可能创建一组如 图 8所示的类。

　　图 8. 工作订单的类图示例

　　

　　如果您将工作订单构造为一个 OO 应用程序，这些软件对象将包含所有必需的业务规则，并且理解应该遵循的业务流程。

　　然而，这种方法在实践方面存在着一些缺点：

　　许多步骤涉及与现有遗留系统和数据库(例如帐单编制、日程安排以及库存系统)的连接，它们不可能遵循 OO 范式进行设计(在这样的情况下，应用适配器或仲裁器会有所帮助)。

　　为了使系统尽可能地灵活，将一些规则外化是有帮助的，这样就可以在不更改代码的情况下修改流程或工作流。例如像下面这样的规则：

• 　　标准的 24,000 英里服务包括四公升油。只是在使用四升以上的油或顾客要求优质油(如合成油)时才应该收取额外的邮费。
• 　　在遗留应用程序中有一套工业标准为普通汽车维修活动进行劳务估价。除非维修人员收取的费用超过该估价的 X% 并且报告产生差别的有根据的原因，否则顾客就应该支付标准的劳务费。
• 　　如果超过估价的 Y% 以上，就应该联系顾客以进行确认。

SOAD 为这些问题提供了极好的解决方案。由于它基于相关的行为对服务进行分组，而不是进行封装(行为及数据)，所以这组服务与业务对象略有不同。

 

　　例如，您可能将工作订单(Work Order)和工作订单项(Work Order Item)一起分到工作订单服务(Work Order Services)，并且创建日程安排(Scheduling)、目录(Catalog)和库存(Inventory)服务。另外，因为没有服务实例，所以没有与服务之间的关系等价的东西。工作订单的服务模型可能看起来如 图 9所示。

　　图 9. 工作订单的服务模型示例

　　

　　与 OO 范式不同，这个模型并不表示功能系统。既没有考虑流，也没有描述业务事件或规则。在 SOA 范式中，在服务外面维护的业务流程编排决定了执行服务调用的顺序和时间。

　　从概念上讲，从第一次顾客联系到完成工作和帐单支付的整个业务表示单个宏观层次的工作单元，并具有数天到数周不等的生命周期。毕竟，从企业的角度来看，工作单元会产生收入。

　　然而，实际出现的情况是在一段相对长的时间内单独发生的一系列集中活动，例如，定义活动、安排预约、选择零件和备件、进行维修活动等等。在 IT 系统中，没有实际的 流程会持续几分钟以上;事件之间的业务流程状态以数据的形式保存在数据库中。

　　这种类型的流程可以用状态转换模型(例如 UML 中可用的)很好地进行表示。 图 10显示了用有限状态机(finite-state machine)方法如何对业务流进行建模的示例。它是在业务流程进行时工作订单的状态如何改变的高级视图。

　　图 10. 工作订单的业务流程模型

　　

　　业务流程编排集中于状态之间的这些转变。单独的操作永久地记录相关的状态改变。

　　图 11显示了部分编排的示例，其中包括 图 10所示的业务场景中的步骤 1 到 5(例如，顾客定义他们的交通工作所需的工作，并且安排预约以进行实施)。

　　图 11. 工作订单的业务交互模型

　　

　　总结和展望

　　在本文中，我们已经讨论和激发了对创新的中间相遇的方法的需求，这种方法搭建了业务和 IT 之间的桥梁，并且支持 SOA 项目的分析和设计阶段。我们还提议将这种新的交叉学科的 SOAD 方法作为一个整体的建模规则，它以现在构建良好且广为赞誉的 OOAD、EA、和 BPM 为基础。

　　在详细定义 SOAD 表示法和流程的同时，还确定了关键的原理，比如服务概念化(或标识)、服务分类或聚合、策略和方面、中间相遇流程、语义代理和服务获取(以供重用)。

　　SOAD 需要增强现有的软件开发方法，进一步提高企业应用程序开发项目的可用性和适用性。随着时间的推移，还将发展相关的最佳实践。

　　我们还认识到，UML 在流程的表示法选择方面将继续占支配地位;可能需要进行增强以满足更广泛的 SOAD 的要求。

　　完成 SOAD 方法的下一步就是定义所需的端到端流程和表示法，复审活动中的角色和它们的责任，并且继续检查所提议的方法在项目中的有效性。