最初的面向服务的体系结构（Service-Oriented Architecture，SOA） 的实现项目的经验表明，诸如面向对象的分析与设计（Object-Oriented Analysis and Design，OOAD）、企业体系结构（Enterprise Architecture，EA）框架和业务流程建模（Business Process Modeling，BPM）这样的现有开发流程和表示法仅仅涵盖了支持目前出现在SOA中的体系结构模式所需的部分要求。

　　在Info World最近的访谈（请参见参考资料）中，Grady Booch 宣称“像对问题的良好抽象和良好的分离这样的工程基础决不会过时”，不过，他也指出“还是有现实的机会提升抽象的级别。过去的经验表明，必须将抽象的级别提升到公司处理的业务领域，从而将整个企业IT前景都纳入考虑的范畴。

　　正如Mark Colan在文章 “面向服务的体系结构扩展Web服务的前景，第1部分”中介绍的，SOA是一种新兴的企业结构形式，可以用于设计下一代企业应用程序。SOA方法在有力地加强已经制定的良好通用软件体系结构原则（如信息隐藏、模块化和问题分离）的同时，还增添了一些其他的主题，例如服务编排、服务库和服务总线中间件模式。

　　需要结构化方法或 分析与设计方法来设计高质量的SOA。因为现有的方法中没有一种能够满足程序设计人员对最新的SOA项目的要求，所以他们建议将已经形成的良好实践（如 OOAD、EA和BPM）中的原理组合起来，并且使用根据需要创新的原理来对其加以补充。

　　引言

　　面向服务的体系结构（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 &#101xecution 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 &#101xecution 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）将具有负平衡，并且将展示增加利息的行为，等等。

　　·消息传递：为了完成一些有用的工作，软件对象需要相互通信。它们通过相互发送消息来这样做。例如，假定我们想将$1000从经常帐户转到储蓄帐户，要达到此目的，可以将带有参数$1000的借消息发送到 经常帐户（CheckingAccount）实例，并且将相应的 贷消息发送到 储蓄帐户（SavingsAccount）实例。当实例接收消息时，它执行相应的功能，称为方法，它有与消息相同的名称。
　　·多态：这个术语描述两个或两个以上的类接受相同的消息但是以不同的方式进行实现的情况。例如，自由经常帐户（FreeCheckingAccount）实例和 经常帐户（CheckingAccount）实例将响应 借($100)消息，但是 自由经常帐户（FreeCheckingAccount）实例将正好$1000记入它的帐户平衡的借方，而 经常帐户（CheckingAccount）实例将$1000加上交易费记入它的帐户平衡的借方。

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

　　作者简介

　　Olaf Zimmermann是IBM worldwide Applied Web Services组的顾问IT构架师。他在分布式计算、面向服务体系结构、Web服务/XML和J2EE方面颇有专长。在过去的几年里，Olaf指导了大量与Web服务有关的交流项目，包括几本产品参考书。他是Springer教科书Perspectives on Web Services（ISBN 3-540-00914-0）的作者。他还参与了几本IBM ITSO红皮书（比如Web Services Wizardry with WebSphere Studio Application Developer （SG24-6292-00））的写作。Olaf从1994年开始就与IBM合作，涉及的领域非常广泛，其中包括产品开发、技术预售咨询、教学以及系统集成。Olaf在位于德国Braunschweig的Technical University获得计算机科学学位。您可以通过ozimmer@de.ibm.com与他联系。
 
　　Pal Krogdahl是一名解决方案架构师，在IGS的IBM Business Consulting Services（位于瑞典）工作。他从1998年开始就职于IBM，涉及了多个领域，比如软件开发、售前技术咨询和解决方案体系结构。他擅长的领域包括分布式计算、中间件和应用程序服务体系结构，主要集中在EAI和SOA。Pal最近撰写了一些范围广泛的文章，探讨的主题有基于SOA的EA、以及它们与IBM用于电子商务和按需操作系统环境的模式的关系。到目前为止，他已经完成了IBM International Technical Support Organization的一些高级培训，在该组织中，他同人合著了一些与WebSphere有关的红皮书，这些红皮书主要集中在Web服务和SOA方面，例如Patterns: Service-Oriented Architecture and Web Services(ISBN 073845317X)。在过去的18个月里，他一直在向IBM内外的技术人员介绍Web服务和基于SOA的按需操作环境的实现方面的知识。您可以通过pal.krogdahl@se.ibm.com与他联系。
 
　　Clive Gee是一名高级解决方案架构师，工作在IBM Enterprise Integration Services部。他于1976年加入IBM Europe并于1997年调到IBM US。1990年，作为创立IBM European Object Technology Practice的一员，他是IBM中第一位OO的支持者。从那以后，他获得了领导企业OO交流项目的大量实践经验，涉及多个行业（如公用事业、金融业、运输业、零售业和电信业）的复杂系统集成和应用程序开发。目前，他正忙于为一个重要的美国客户配置部署SOA解决方案。Clive从苏格兰的University of Stirling大学获得理论物理博士学位。您可以通过clive@us.ibm.com与他联系。