影响服务导向的主要因素之一是对象导向的设计的成功创建，这并不是什么大秘密。两者的设计理念之间虽然有显著的差异，但也有许多共同点。事实上，如果不是因为对象导向形成的创新设计原则及模式，现在将不会出现服务导向的架构模型及Web服务框架。这两篇文章由《SOA：服务设计的原则》一书中的摘录组成。

　　引言：两个设计范式的故事

　　对象导向的分析与设计，主要应用于推广由可复用的柔性软件组成的流线化程序的创建。借助先进的处理方法、统一建模语言（UML）规范及一套一流的改变了分布式应用程序设计界面的设计模式提供的进一步支持，对象导向已成为一种成熟的，能适应多种情况的设计框架。

　　OOAD最初是为了满足把命令（order）引入非结构化开发进程中的需要，该进程曾造成多种问题，包括创建了spaghetti代码。OOAD学习了程序编程方法中的最佳方法，并把这些最佳方法与将软件塑造为更能真实反映现实世界的部件的设计理念结合。

　　对象导向希望能在程序生命周期内最大限度地实现业务需求，包括其部署后的升级和扩展。因此，它提供了众多的规则和向导，管理程序逻辑的分离过程以及数据的分离过程。从数据分离出的对象可以被单独保存，从而能从整体上将程序改变的影响减至最低。

　　为表述客户需求及可预见的运行时程序操作，许多UML规范和文献技术更提供了一种全面的方法。结合既定的原则及做法，UML图表类和规范类可以为设计师提供帮助，确保创建的程序功能强大而灵活。此外，对象导向程序的创建还需要可复用代码的培养。继承和多态（讨论见此文章系列的第二部分）等关键技术，也已经部署到位，从而使不同的软件程序可以从其他已创建的程序中获得支持。

　　正如在下面的《目的比较》部分中所阐释的，服务导向与OOAD有很多相同的目的。它旨在建立一个灵活的设计架构，从而能灵活的适应不断变化的业务需求。与OOAD类似，服务导向十分注重减少改变已部署和已使用的软件程序的影响。许多原则，如服务松耦合原则和服务可构性原则，也提出了许多要求，比方说长期的管理要求，从而使已实现的服务能适应业务的变化，继续发展。

　　两种设计范式之间存在不同，其中一个是范围的不同（图1）。虽然对象导向从不明确限制其原则的适用程度，但是在现实世界环境中，它们都在单一程序中或相关程序集合中得到了实现。如果实现了复用，通常将其应用于公用程序方面，从而使“公用构件”的程序库可以被自定义开发程序共享。

　　图1：从应用历史上说，对象导向已应用于企业的某些部门。而服务导向，目的则是协调企业的大多数部门，或理想的情况下，协调整个企业。

　　此外，对象导向的几个设计原则及模式，都是在大多数IT企业使用RPC技术构建组件式或分布式程序时形成和发展的。而每一个特定对象都仅限于在RPC平台上实现复用。因此，在由多种技术平台组成的较大环境下，一个RPC实现就代表一个具体的建筑区。为了能实现与其他区的连接，还需要桥接技术或集成技术。而跨程序及跨平台连通性不断增加的需求，导致了EAI（顺便说一下，这是服务导向的另一个重大影响）的出现。

　　虽然对象导向发挥了许多作用，但SOA和服务导向目前的主流地位却都源于Web服务框架的出现和成功应用。虽然第一代Web服务平台所提供的功能设置是原始中最好的，但它同时也确定了超越专有程序及平台界限的可能性，从而激发了人们的设想，实现真正的、跨企业的内部连通及联合。

　　作为SOA和服务导向原则基础的构架模型，就是在这一设想的支持下发展而成的。因此，SOA和服务导向与日趋成熟的第二代Web服务平台有相当多的协同作用。图2说明服务导向的影响因素主要包括对象导向、EAI、Web服务以及BPM。

　　图2：虽然对象导向是从其他方法中演变而来，其中包括程序性编程方法，但是服务导向却是基于对象导向的设计范式建立，结果是，创建了一个独特的、独立的设计范式。

　　在服务导向中，被设计成服务的求解逻辑，有意部署为企业资源，有时甚至是整个企业的资源。这个以企业为中心的观点是导致对象导向原则中只有一个子集可以进行到服务导向中的一个主要原因（解释见此文章系列的第二部分）。

　　目的比较

　　在我们开始概念及原则比较之前，重要的是在每一个设计方法背后，我们都建立了基本目标。与服务导向计算有关的战略目标如下：

　　·增强内在的互操作性
　　·增强联合
　　·增加供应商的多样化选择
　　·增强商业与技术领域的组合
　　·提高ROI
　　·增强组织灵活性

　　减少IT负担

　　WhatIsSOA.com对每一个目标都进行了描述，因此，我们在此将不再复述。其中，有几项目标直接对应于对象导向的最初目标。不过，有一些目标不同，它们仅限于服务导向的以企业为中心的范围。

　　下面列出了共同的OOAD目标，并讨论了这些目标与服务导向原则及目标之间的比较和关系：

　　·增强业务需求的实现

　　·增强功能

　　·增强延展性

　　·增强灵活性

　　·增强复用性及生产能力

　　为了更好地了解服务导向如何关系到，以及如何支持对象导向的这些特定目标（图3），我们需要仔细的对每个目标进行分析。

　　图3：服务导向继承了OOAD所有的主要目标（圆圈内），但进一步扩大了目标范围，并增加了其他目标（圆圈外）。

　　增强业务需求的实现

　　借助专门的分析技术和设计技术（包括以业务为中心的交互技术，如use cases）， OOAD主张程序的设计与开发应更能满足特定的业务需求。

　　同时，增强业务需求的实现也是服务导向优先考虑的要求，还是设计原则时考虑的主要因素之一。随着业务需求范围的扩大，这些原则衍生出许多设计特色，以适应允许创建先进组合配置的设计时进程。

　　服务导向的战略目标，如“增加供应商的多样性选择”，打算建立一个准许企业不断利用技术创新的环境，从而为最大限度地实现潜在的业务需求提供支持。此外， OOAD的重点——将解决方案逻辑分割成更像现实世界中的物体的单位，与“增加商业和技术领域的组合”的目标一致，而后者的目的是把现实世界在域和企业的层面表示。

　　增强功能

　　由于适用于各部分（对象）的额外设计考虑组成了解决方案，以及正式设计时交付——如活动，序列，状态图，描绘潜在的运行时使用情况——的使用，对象导向解决方案可以实现对例外条件的抵制。

　　无论从短期实现的角度，还是从长期管理的角度来说，增强功能都是服务导向的目标。服务组合的设计要实现一部署就能立即发挥其应有的作用，同时在单个服务的目的被更新时，仍然保持强大的功能，支持不同的业务需求实现为不同的组合部分。

　　服务自主性和服务无国籍性代表了两个关键的原则，它们在支持多解自动计算的同时，致力于确保服务在运行期间的可靠性和可扩展性。

　　增强延展性

　　一旦实现并投入使用，对象导向解决方案可以利用其程序设计的组合性质，实现功能范围的扩大，而不需要对其进行规模宏大的重新开发工作。

　　许多服务导向原则的目标是，创建扩展或重组服务组合的自由，以适应业务需求范围的扩大。事实上，功能的上下文需要小心建模和定义，从而使遵循个人服务契约的每一个服务，能够不受现有的用户程序的干扰，干净的延展出新的能力。

　　“增强联合”和“增强内在互操作性”的目标，目的是通过纳入新的服务能力，对服务组合构成的解决方案进行修改和扩展，在产生影响极小的情况下（这是由于支持内在互操作性的标准创建了本地兼容能力），对企业进行协调。  

　　增强灵活性

　　对象导向解决方案部署之后，可以通过关键设计技术的目标程序，如包含，抽象和继承，得到进一步发展和加强，而与用户间会发生极短的中断。

　　使公司自由的管理和发展服务是服务松耦合原则与服务抽象原则的主要目的，这两个原则都保护企业免于有害相关性扩散的影响。这创建了一种可以根据要求，决定重构或增强个别服务能力的环境。

　　服务增加的灵活性可以引起更大的灵活性，从而导致服务库的发展，以及根本的服务导向架构本身的发展。事实上，灵活性正是“增强组织灵活性”目标的核心。

　　增强复用性及生产能力

　　可以将对象导向解决方案的逻辑设计成可复用的，从而能够在建立相同逻辑类型的程序时减少相应的工作量。服务可复用性的原则，明确对应于这一目标，但值得一提的是，服务导向的其他设计原则也进行了定位，全力支持可复用服务逻辑的广泛实现。 

　　因此，可复用性作为SOA的一部分，比实际的目标更具有可预期的、高级的设计特点。“ROI的提高”与这一原则的成功应用密切相关。 

　　基本概念的比较

　　从概念上来讲，对象导向和服务导向有许多相似之处，但它们并不相同。下面确定了几个在所有设计方法中都用到的、与共同概念和不同概念皆有关的术语及定义： 

　　类和对象

　　方法和属性

　　信息

　　接口

　　注意，下面的文章中，各例均应用UML规范。为了将UML规范应用于XML架构设计和Web服务设计，出现了许多种处理方法。本文的重点不是如何对UML规范进行调整，以表示XML架构或WSDL定义结构。除非另有说明，这项比较专门指基本服务导向与对象导向之间的比较，而这自然会引起UML是如何涉及到服务（不论其实现与否）等问题。 

　　类和对象

　　类基本上是作为定义相关行为及属性的容器，对象导向提供了一种将求解逻辑添加到类的方法（图4）。 

　　类运行时的实例是对象（这一点与服务运行时的实例是服务很像）。因此，类可以被看作是各种对象产生的设计模板，每个都有自己独特的运行状态和数据。 

　　类可与技术服务契约相比，却并不等同于技术服务契约。类可以定义公共访问与私人实现细节的结合，而服务契约只能表示公共信息。在这方面，服务契约更类似于类实现的接口（解释见接口部分）。

　　图4：类符号（左）及弦圈符号（右）都创建了与Invoice有关功能相关联的容器及功能状态。

　　方法和属性

　　对象导向类定义方法和属性，从而将行为和数据与对象进行关联。行为代表类可以实现的功能。每个行为由独立的方法定义进行表示和描述。方法有时也被称为操作；不过，操作这个术语，现在更多的已成为使用Web服务的同义词。 

　　类的性质代表一种与类相关的预定义的状态数据，并通过定义属性表示。属性也可以被称为变量。 

　　方法和属性可以被宣布为类专用或类公用。它已成为一种只允许公众通过公用方法（进一步描述为“访问方法”）进入或修改属性的最佳方式。 

　　服务可以将行为抽象为能力进行表示。如果将服务实现为组件，那么一种能力就对应于一种方法；如果将服务部署为Web服务，那么，一种能力就对应于一种操作。Web服务契约并不能定义专用操作。由于侧重于无国籍性，服务契约无法对属性进行定义，如图5所示。 

　　图5：类符号（左）表示了属性和方法，而服务符号（右）只定义了能力。

　　信息

　　对象调用程序和调用方法的对象之间的通信，通过信息的交换进行。它作为OOAD词汇的一部分，是一个抽象的术语，因此并不能说明现实世界中的信息的结构组成。 

　　因为对象导向典型应用于基于非工业标准（往往是基于RPC）通信协议的组件，因此信息最常见的表现形式为二进制单位的同步交换通信。信息的内容依赖于输入或输出值的数据类型，而这些数据类型的定义是方法及配套技术平台的一部分。RPC平台，支持多种数据类型，包括可以表示对象本身的数据类型。

　　作为Web服务实现的服务，其所用的信息通常体现为基于文本的通信单位，可以同步交换或异步交换。在此背景下，它们更像是传统意义上我们所说的信息（如电子邮件系统或面向信息中间件中所使用的信息）。

　　Web服务操作的输入和输出值可以用信息表述，这些信息通常是XML语句的复杂类型结构。它们可以实现由无数的值组成的、以文件为中心的复杂类型层次，而每一层都是不同的数据类型。这就是为什么基础的弦圈符号不需要具体的数据类型，就可以表示服务契约。 

　　对象方法的设计，经常是出于交换细粒度参数数据的目的。这是因为他们用其他对象（无论是本地或远程）建立的连接一般都比较持久。一旦连接到位，就可以实现高效而可靠的数据交换。 

　　Web服务普遍基于无国界的HTTP协议进行信息交换。因为持久的本地连接并没有给Web服务带来好处，因此我们往往需要对操作进行设计，来交换以文件为中心的信息；以及由大量数据组成的信息，比方说，整个商业文件。几乎服务导向的每一个设计原则，都会影响能力、数据及验证粒度，进而影响服务信息的大小。

　　图6说明了类的设计过程在遵循对象导向和服务导向的原则时所受到的不同影响，并进一步将其与典型的服务契约进行了对比。注意这三类中各自方法与操作粒度的不同；服务导向设计鼓励增加粗粒度能力，它更强调以信息为中心，而且支持XML文件的交换。这不仅影响了能力的粒度，而且影响到数据类型的选择。 

　　图6：对象导向类（左），服务导向类（中），以及服务契约（右）。注意，服务导向类忽略的属性是公开的。 

　　接口

　　所有的相关方法都可以在接口（图7）中被定义（但不能被实现），那么，为了实现接口，就可以对类进行设计，将形式端点创建到类涵盖的逻辑中。那么，接口就可以从外界中摘要出与类有关的其他细节。

　　图7：表述两种方法的Invoice接口。

　　服务导向的重点是服务契约的定义及定义背后的求解逻辑。独立的服务契约可以相比于已实现的类接口，它为公众使用服务功能提供了形式入口点，同时也对基本服务细节做出了摘要。

　　在作为Web服务实现时，服务契约是解耦架构部件，这一点与类列出其属性及方法（使用接口或不使用接口）作为本身的嵌入式延伸不同。

　　Web服务契约可以被视为技术接口潜在的高级形式，因为它能够表述多种逻辑，包括数据交换要求，验证规则，端口、连接等实现细节，甚至是语义规则。

　　WSDL定义，用于定义含有端口类型元结构的Web服务契约，已正式建立了Web服务操作。在这方面， Web 服务的端口类型与对象导向的接口很像（事实上，在WSDL 2.0版中，“端口类型”要素已被更名为“接口”）。要注意，WSDL定义中可以包含多个端口类型结构，这与类可以实现多个接口的方式完全一样。 

　　Web服务中的某个服务，可能会，也可能不会包含对象导向的逻辑。如果确实包含的话，那么服务导向的设计原则就能够影响类的设计方式，这一点将在这篇文章系列的第二部分中研究。 

　　结论

　　要记住，对象导向和服务导向是相辅相成的设计范式，这一点很重要。我们越了解它们之间的不同，我们就能更好地判断什么时候分别使用，以及如何成功的将两者结合使用。在这篇文章系列的第二部分，我们将继续两者间的比较研究，对比主要由这两种范式构成的设计原则。