1.1 SOA的基本概念和设计思想

近年来SOA如此火热，在架构师研讨会和论坛中永远是讨论的焦点。甚至一些软件厂商在对SOA一知半解的情况下，也为自己的产品贴上了SOA的标签，以此作为促销的噱头。SOA的火热，反而让人们对SOA这个本就含糊的术语更加摸不着头脑，于是也对SOA有了一些误解。对SOA最为典型的误解就是：

SOA就是采用Web服务的架构

面向服务（SO：Service Orientation）代表的是一种设计理念，和面向对象（OO：Object Orientation）、面向组件（CO：Component Orientation）一样，体现的是一种对关注点进行分解的思想，面向服务是和技术无关的。

Web服务（这里指的是广义的Web服务，包括微软平台下的ASP.NET Web服务和WCF，也包含其他平台的Web服务）是一种实现SOA最理想的技术手段。但是，如果你设计的理念还停留在COM或DCOM的层面，即使采用了Web服务来构建你的应用，也不能说你的应用是基于SOA的。另一方面，实现SOA并非只有Web服务一种手段。很多人认为面向服务架构仅仅是由若干Web服务堆砌而成，这是一个非常普遍而危险的想法。它会导致采用SOA的组织都热衷于关注某种基于SOA的技术平台，而忽略了对面向服务思想的把握，在我看来，这是一种本末倒置的做法。正是有了这样的误解，很多人采用了WCF，却还是在按照传统分布式架构的思想在设计他们认为是面向服务的应用。所以采用SOA多地是要求设计人员在思想上转变观念。

对SOA其实没有一个统一的定义，不同的人站在不同的角度会对SOA有不同的认识。但是，不管对SOA存在怎样的分歧，SOA的一些基本特性还是被大家普遍接受的。接下来，我们就来简单介绍一些SOA的基本特性。

服务是自治的

服务的自治原则要求单个服务在底层逻辑控制方面尽可能是独立和自包含的，服务不依赖于访问它的客户端和其他服务。服务可以独立地进行部署及实施版本策略和安全策略。

SOA依赖于开放的标准

SOA的一个目标是让不同厂商开发的服务能够进行互操作，要实现这样一个宏图伟业，就必须依赖于一种开放的、能够被不同的厂商普遍接受的标准。SOA采用基于消息的通信方式，从消息交换的角度来讲，就是要求消息自身标准化，在此方面，SOAP消息的采用对消息承载的内容提供了一致性的表示。此外，客户端进行服务调用的前提是对服务描述的理解，所以服务描述也需要一种标准化的表示，在此方面，SOA采用XML、XSD及WSDL作为服务描述的“语言”。

此外，当SOA真正地被用于企业级应用时，还须要考虑一些额外的因素，比如消息安全、可靠传输、事务的支持等。要实现真正意义上的跨平台互操作，实现这些特性的互操作方式同样需要通过一种开放的标准确定下来。在这方面，一些主流的IT厂商，比如微软、IBM和BEA等联合一些国际标准组织，比如W3C（World Wide Web Consortium：万维网联盟）、OASIS（Organization for the Advancement of Structured Information Standards：结构化信息标准促进组织）和WS-I（Web服务互操作性组织）等，对标准或规范的制定做出了极大的贡献，这些标准或规范定义在WS-*规范中。

SOA支持跨平台

能够让不同的平台进行通信是SOA产生的最主要动机。正因为SOA采用了开放的标准，才使跨平台得以实现。跨平台性最大的好处就是促进了异质系统的集成，使J2EE平台下的应用能够调用.NET平台暴露出来的WCF服务。此外，使用标准的服务对现有逻辑的封装，实现了对历史遗留应用的重用，也给企业提供了一种节约成本的捷径。

SOA鼓励创建可组合的服务

按照提供功能大小的差异，不同的服务具有不同的粒度。我们可以把提供具有最小粒度功能实现的服务称为原子服务。多个原子服务可以通过合理的组合、编排构成一个新的聚合型服务。比如，我们把通过一系列独立服务承载的活动（Activity），按照相应的规则进行编排构成一个聚合型的工作流（Workflow）服务。

SOA鼓励服务的复用

功能的复用是软件设计思想不变的主题，SOA鼓励创建具有高复用度的服务。服务的组合性另一方面也促进了服务的重用。为了提高服务复用的程度，SOA甚至强调了创建与场景无关的服务，这样，同一个服务就能在不同场景的解决方案中使用了。

SOA强调松耦合

基于类型系统交互方式面向组件的不同，SOA通过“契约”实现客户端对服务的调用。双方只须要采用能够匹配的契约就能保证正常的交互。基于契约的服务交互，又进一步地促进了服务的自治，只要契约不发生改变，服务本身的实现就可以自由的变化。