【IT168 技术文档】

        最初的面向服务的体系结构（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 方法在加强已经制定的良好通用软件体系结构原则（如信息隐藏、模块化和问题分离）的同时，还增添了附加的主题，例如，服务编排、服务库和服务总线中间件模式，在建模时需要对它们给予特别的关注。

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

        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 中的原理，并且融入了一些具有创新性的原理。这种新的方法的 SOAD 资源（原理和技术）：

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 有关的问题的答案。