面向服务的分析与设计原理(1)
最初的面向服务的体系结构（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 有关的问题的答案。
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）这样的对象。假如您看得更仔细一点，您将发现这些类共享许多属性，比如都有收支平衡帐户、借方帐户和贷方帐户等等
与其重复定义和治理这些属性的代码，不如创建一个通用的帐户（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）卡）也可以用于服务建模（假如它们提升到更高层次的抽象的话）。在本文后面，我们将回过头来讨论这一点。
可见性层次和 OO、面向组件 和 SO 设计提供的重点之间的对应关系。它还展示了在 SOA 和 SOAD 背景中它们之间的相互关系。
至于表示法，统一建模语言（Unified Modeling Language，UML）——通过一些附加的定型（Stereotype）和概要加以增强——自然成为 SOAD 的重要基础。
在使用 Rational Unified Process (RUP)——被认为是支持迭代软件开发的分析与设计的主流 OOAD 流程之一——的流程方面，使用 UML 模型具有首要价值。然而，RUP 以 OOAD 的原则为基础，因而使其不轻易与 SOA 设计保持一致。从 RUP 的角度来看，系统的体系结构是其通过已定义接口交互的主要组件的体系结构。此外，这些组件还由逐渐减小到类级粒度的更小组件组成。相反，在 SOA 中，系统的体系结构通常包括满足普通业务服务需要的无状态、全封装且自描述的服务组成，它更接近于映射到 BPM。这些服务可能包括许多协作或编排服务。这并没有排除 RUP 采用的 OO 观点，而是在其上实现了另一个抽象层。这个超层的作用是封装作为正式的跨层接口结构中的 RUP 构件（软件服务）设计的组件。
更多的请看：http://www.QQread.com/windows/2003/index.Html最初的面向服务的体系结构（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 有关的问题的答案。
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）这样的对象。假如您看得更仔细一点，您将发现这些类共享许多属性，比如都有收支平衡帐户、借方帐户和贷方帐户等等
与其重复定义和治理这些属性的代码，不如创建一个通用的帐户（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）卡）也可以用于服务建模（假如它们提升到更高层次的抽象的话）。在本文后面，我们将回过头来讨论这一点。
可见性层次和 OO、面向组件 和 SO 设计提供的重点之间的对应关系。它还展示了在 SOA 和 SOAD 背景中它们之间的相互关系。
至于表示法，统一建模语言（Unified Modeling Language，UML）——通过一些附加的定型（Stereotype）和概要加以增强——自然成为 SOAD 的重要基础。
在使用 Rational Unified Process (RUP)——被认为是支持迭代软件开发的分析与设计的主流 OOAD 流程之一——的流程方面，使用 UML 模型具有首要价值。
然而，RUP 以 OOAD 的原则为基础，因而使其不轻易与 SOA 设计保持一致。从 RUP 的角度来看，系统的体系结构是其通过已定义接口交互的主要组件的体系结构。此外，这些组件还由逐渐减小到类级粒度的更小组件组成。相反，在 SOA 中，系统的体系结构通常包括满足普通业务服务需要的无状态、全封装且自描述的服务组成，它更接近于映射到 BPM。这些服务可能包括许多协作或编排服务。这并没有排除 RUP 采用的 OO 观点，而是在其上实现了另一个抽象层。这个超层的作用是封装作为正式的跨层接口结构中的 RUP 构件（软件服务）设计的组件。
