封装：软件对象就是包含模拟真实世界的对象的物理属性（数据）和功能（行为）的离散包。例如，帐户对象保持收支平衡并且包含平衡中的借贷机制。
信息隐藏：结构良好的对象有简单的接口，并且不向外界显漏任何内部机制。真实世界信息隐藏的例子是，您不需要详细了解汽车的工作原理就能够驾驶它。
类和实例： 类是定义特定类型的软件对象具有什么类型的属性和行为的模板，而 实例是具有这些属性值的个别对象。创建类的新实例称为 实例化。利用生物学进行类比，人就是一个类。所有的人都具有一些属性，比如身高、体重、头发和眼睛颜色等等。我们中的每个人都是这个类 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 支持应用程序分析、设计和开发的完整生命周期：
1.OOAD试图找到最优的对象和最自然的类继承来实现它们。
2.OO 开发集中于应用程序的渐进式开发，每次实现一个业务场景或用况。像 IBM WebSphere Studio Application Developer 这样的工具有助于开发人员快速地构造和测试 OO 应用程序。
3.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 原理，就可以在需要时确定额外的原理。
必须有结构化的方法来概念化服务：
1.OOAD 为我们提供了应用程序层上的类和对象，而 BPM 具有事件驱动的流程模型。SOAD 需要将它们结合在一起。
2.方法不再是面向用况的，而是由业务事件和流程驱动的。用况建模是在更低的层次上作为第二步进行的。
3.方法包括语法、语义和策略。这就需要特别的组合、语义代理和运行时发现。
4.SOAD 必须提供定义良好的品质因素和非常好的实践（例如回答粒度问题）。必须回答 BPEL 提出的角色问题。例如，谁为哪部分工作负责：是开发人员、架构师，还是分析人员？
5.SOAD 活动还必须回答这样的问题：什么 不是好的服务？例如：不可重用的任何东西都不可能成为好的一流 SOA 成员（即服务）。另一个例子就是带有挑战性的非功能要求的嵌入式实时系统，它们不能承受任何 XML 处理开销。
6.SOAD 必须易于进行端到端建模，并且有全面的工具支持。假如 SOA 给业务带来了灵活性和敏捷性，就应该对从企业到体系结构和应用程序设计领域产生的支持方法有相同的期望。
品质因素
一些通用原则或品质因素已经确定，并且可以作为 SOAD 中的设计基准：
1.构思良好的服务给业务带来了灵活性和敏捷性；它们通过松散耦合、封装和信息隐藏使重构更加容易。
2.设计良好的服务是有意义的，并且不只适用于企业应用程序；服务之间的依赖性减到最少，并且是显式声明的。
3服务抽象是内聚、完整和一致的；例如，在设计服务和它们的操作签名时应该考虑 创建（Create）、 读取（Read）、 更新（Update）、 删除（Delete）和 搜索（Search）(CRUDS) 隐喻。
4.常常声明的假定是，服务是无状态的（例如非对话式的）；为了要求服务在特定的问题域和上下文中是无状态的，将削弱这种声明。
5.领域专家无需深奥的专业知识就可以理解服务命名。
6.在 SOA 中，所有的服务都遵循相同的设计体系（通过模式和模板连接的）和交互模式；底层体系结构形式可以容易地标识（例如在体系结构复审期间）。
7.服务和服务使用者的开发除了领域知识之外只需要基本的编程语言技能；中间件专业知识只有少数的专业人员才需要，在理想的情况下，这种知识是为工具和运行时厂商所用，而不是为制作像 SOA 这样的企业应用程序的公司所用。
服务标识和定义
自顶向下的业务级建模技术（如 CBM）可以为 SOA 建模活动提供起点。但是正如我们在前面提到的，SOA 实现很少是在全新的项目中开始的；创建 SOA 解决方案几乎总需要涉及集成现有的遗留系统，方法是将它们分解成服务、操作、业务流程和业务规则（同时参见 图 6）：
将现有的应用程序和厂商软件包分解成表示相关操作组的离散服务集（自底向上方法）。
从应用程序中将业务流程和规则抽象为由业务编排模型管理的单独 BPM。
图 6： 服务分解
