最近半年以来，在企业级应用开发领域，谈论最多的一个词，恐怕非soa(service-oriented architecture，面向服务架构)莫属。那么soa究竟拥有什么样的魔力，能够让众多的软件厂商对他趋之若骛，掀起新的一轮企业架构浪潮。让我们在本文中一探soa的究竟。
那么什么是soa，让我们先从基本概念开始讲起。

什么是soa?

soa是一种架构模型，它可以根据需求通过网络对松散耦合的粗粒度应用组件进行分布式部署、组合和使用。服务层是soa的基础，可以直接被应用调用，从而有效控制系统中与软件代理交互的人为依赖性。

soa的关键是“服务”的概念，w3c将服务定义为：“服务提供者完成一组工作，为服务使用者交付所需的最终结果。最终结果通常会使使用者的状态发生变化，但也可能使提供者的状态改变，或者双方都产生变化”。

service-architecture.com将soa定义为：“本质上是服务的集合。服务间彼此通信，这种通信可能是简单的数据传送，也可能是两个或更多的服务协调进行某些活动。服务间需要某些方法进行连接。所谓服务就是精确定义、封装完善、独立于其他服务所处环境和状态的函数。”
looselycoupled.com将soa定义为：“按需连接资源的系统。在soa中，资源被作为可通过标准方式访问的独立服务，提供给网络中的其他成员。与传统的系统结构相比，soa规定了资源间更为灵活的松散耦合关系。”

gartner则将soa描述为：“客户端/服务器的软件设计方法，一项应用由软件服务和软件服务使用者组成……soa与大多数通用的客户端/服务器模型的不同之处，在于它着重强调软件组件的松散耦合，并使用独立的标准接口。”

gartner相信bpm和soa的结合对所有类型的应用集成都大有助益??“soa极大的得益于bpm技术和方法论，但是soa面临的真正问题是确立正确的企业意识，即：强化战略化的soa计划（针对供应和使用）并鼓励重用。”

虽然不同厂商或个人对soa有着不同的理解，但是我们仍然可以从上述的定义中看到soa的几个关键特性：一种粗粒度、松耦合服务架构，服务之间通过简单、精确定义接口进行通讯，不涉及底层编程接口和通讯模型。

需着重注意的是，soa并不是新生事物??大型it组织成功构建和部署soa应用已有多年的历史??这要比现有的xml和web服务长很多。ibm cics和bea tuxedo就是过去被用于构建soa应用的两种技术范例。

重点说明的是soa并不是一种现成的技术，而是一种架构和组织it基础结构及业务功能的方法。soa是一种在计算环境中设计、开发、部署和管理离散逻辑单元（服务）的模型。这一定义阐明了soa的范围。

soa要求开发人员将应用设计为服务的集合。soa要求开发人员跳出应用本身进行思考，考虑现有服务的重用，或思索他们的服务如何能够被其他项目重用。“单独的”、“独立的”、“封装完善的”服务所具有的一个关键的好处是，可以采用多种不同方法将它们组合成较大型的服务，由此来实现重用。

但是，soa并不仅仅是一种开发方法??它还具有管理上的优点。例如，现在管理员可直接管理开发人员所构建的相同服务，这远胜于以往管理单个应用的方式。通过分析服务间的交互，soa可以帮助企业了解何时以及为什么业务逻辑被切实执行了，这使管理员或分析师能够有针对性的优化业务流程。

soa的基本特征

soa的实施具有几个鲜明的基本特征。实施soa的关键目标是实现企业it资产的最大化重用。要实现这一目标，就要在实施soa的过程中牢记以下特征：
可从企业外部访问
随时可用
粗粒度的服务接口
分级
松散耦合
可重用的服务
服务接口设计管理
标准化的服务接口
支持各种消息模式
[li]精确定义的服务契约 [/li]

我们现在开始依次讨论以上概念。

1 可从企业外部访问

通常被称为业务伙伴的外部用户也能像企业内部用户一样访问相同的服务。业务伙伴采用先进的b2b协议（ebxml或rosettanet）相互合作。当业务伙伴基于业务目的交换业务信息时，他们就参与了一次会话。会话是业务伙伴间一系列的一条或多条业务信息的交换。会话类型（会话复杂或简单、长或短等）取决于业务目的。

除了b2b协议外，外部用户还可以访问以web服务方式提供的企业服务。

2 随时可用

当有服务使用者请求服务时，soa要求必须有服务提供者能够响应。大多数soa都能够为门户应用之类的同步应用和b2b之类的异步应用提供服务。同步应用对于其所使用的服务具有很强的依赖性。
许多同步应用通常部署在前台，其最终用户很容易受到服务提供者短缺的影响。很多情况下，同步应用利用分布式服务提供者，这样可以响应更多的用户请求。但是，随着提供特定服务功能的服务器数量的增长，出现短缺的可能性也呈指数级上升。
相比之下，异步应用要更为稳健，因为其采用队列请求设计，因此可以容许出现服务提供者短缺或迟滞的情况。异步应用大多数情况下部署在后台，用户通常不会觉察到短暂的短缺。大部分情况下异步应用能够稳健应对短时间短缺，但是长时间短缺则会引发严重问题。在服务短缺解决、队列引擎将罕见的大量工作推到共享的应用资源中时，可能会出现队列溢出甚至服务死锁。
服务使用者要求提供同步服务时，通常是基于其自身理解或使用习惯。在多数情况下，采用异步模型可以达到同样的效果，但更能够体现soa的最佳特性。
当然，并不是所有情况下都应当采用异步设计模式。但大多数情况下，异步消息可以确保系统在不同负荷下的伸缩性，在接口响应时间不是很短时尤其如此。

3 粗粒度服务接口

粗粒度服务提供一项特定的业务功能，而细粒度服务代表了技术组件方法。举个例说明最为清楚??向计费系统中添加一个客户是典型的粗粒度服务，而你可以使用几个细粒度服务实现同一功能，如：将客户名加入到计费系统中，添加详细的客户联系方式、添加计费信息等等。
采用粗粒度服务接口的优点在于使用者和服务层之间不必再进行多次的往复，一次往复就足够。internet环境中有保障的tcp/ip会话已不再占据主导、建立连接的成本也过高，因此在该环境中进行应用开发时粗粒度服务接口的优点更为明显。
除去基本的往复效率，事务稳定性问题也很重要。在一个单独事务中包含的多段细粒度请求可能使事务处理时间过长、导致后台服务超时，从而中止。与此相反，从事务的角度来看，向后台服务请求大块数据可能是获取反馈的唯一途径。

4 分级

一个关于粗粒度服务的争论是此类服务比细粒度服务的重用性差，因为粗粒度服务倾向于解决专门的业务问题，因此通用性差、重用性设计困难。解决该争论的方法之一就是允许采用不同的粗粒度等级来创建服务。这种服务分级包含了粒度较细、重用性较高的服务，也包含粒度较粗、重用性较差的服务。
在服务分级方面，须注意服务层的公开服务通常由后台系统（bes's）或soa平台中现有的本地服务组成。因此允许在服务层创建私有服务是非常重要的。正确的文档、配置管理和私有服务的重用对于it部门在soa服务层快速开发新的公开服务的能力具有重要影响。

5 松散耦合

soa具有“松散耦合”组件服务，这一点区别于大多数其他的组件架构。该方法旨在将服务使用者和服务提供者在服务实现和客户如何使用服务方面隔离开来。
服务提供者和服务使用者间松散耦合背后的关键点是服务接口作为与服务实现分离的实体而存在。这是服务实现能够在完全不影响服务使用者的情况下进行修改。
大多数松散耦合方法都依靠基于服务接口的消息。基于消息的接口能够兼容多种传输方式（如http、jms、tcp/ip、mom等）。基于消息的接口可以采用同步和异步协议实现，web服务对于soa服务接口来讲是一个重要的标准。
当使用者调用一个web服务时，被调用的对象可以是cics事务、dcom或corba对象、j2ee ejb或tuxedo服务等，但这与服务使用者无关。底层实现并不重要。
消息类web服务通常是松散耦合和文档驱动的，这要优于与服务特定接口的连接。当客户调用消息类web服务时，客户通常会发送的是一个完整的文档（如采购订单），而非一组离散的参数。web服务接收整个文档、进行处理、而后可能或者不会返回结果信息。由于客户和web服务间不存在紧密耦合请求响应，消息类web服务在客户和服务器间提供了更为松散的耦合。

6 可重用的服务及服务接口设计管理

如果完全按照可重用的原则设计服务，soa将可以使应用变得更为灵活。可重用服务采用通用格式提供重要的业务功能，为开发人员节约了大量时间。设计可重用服务是与数据库设计或通用数据建模类似的最有价值的工作。由于服务设计是成功的关键因此，因此soa实施者应当寻找一种适当的方法进行服务设计过程管理。
服务设计管理根本上讲是服务设计问题，服务设计需要在两点间折衷??走捷径的项目战术与企业构建可重用通用服务的长期目标。
超越项目短期目标进行服务接口的开发和评估是迈向精确定义服务接口的重要一步，同时还需要为接口文档、服务实现文档及所有重要的非功能性特征设立标准。
在大型组织中实现重用的一个先决条件是建立通用（设计阶段）服务库和开发流程，以保证重用的正确性和通用性。此外，对记述服务设计和开发的服务文档进行评估也是成功利用服务库的关键。
简言之，不按规则编写服务将无法保证可提供重用性的soa的成功实施。在执行规则的过程中会产生财务费用，需要在制定soa实施计划时加以考虑。

7 标准化的接口

近年来出现的两个重要标准xml和web服务增加了全新的重要功能，将soa推向更高的层面，并大大提升了soa的价值。尽管以往的soa产品都是专有的、并且要求it部门在其特定环境中开发所有应用，但xml和web服务标准化的开放性使企业能够在所部署的所有技术和应用中采用soa。这具有巨大的意义！
web服务使应用功能得以通过标准化接口（wsdl）提供，并可基于标准化传输方式（http和jms）、采用标准化协议（soap）进行调用。例如，开发人员可以采用最适于门户开发的工具轻松创建一个新的门户应用，并可以重用erp系统和定制化j2ee应用中的现有服务，而完全无须了解这些应用的内部工作原理。采用xml，门户开发人员无须了解特定的数据表示格式，便能够在这些应用间轻松地交换数据。
你也可以不采用web服务或xml来创建soa应用，但是这两种标准的重要性日益增加、应用日趋普遍。尽管目前只有几种服务使用者支持该标准，但未来大多数的服务使用者都会将其作为企业的服务访问方法。

8 支持各种消息模式

soa中可能存在以下消息模式。在一个soa实现中，常会出现混合采用不同消息模式的服务。
q 无状态的消息。使用者向提供者发送的每条消息都必须包含提供者处理该消息所需的全部信息。这一限定使服务提供者无须存储使用者的状态信息，从而更易扩展。
q 有状态的消息。使用者与提供者共享使用者的特定环境信息，此信息包含在提供者和使用者交换的消息中。这一限定使提供者与使用者间的通信更加灵活，但由于服务提供者必须存储每个使用者的共享环境信息，因此其整体可扩展性明显减弱。该限定增强了服务提供者和使用者的耦合关系，提高了交换服务提供者的服务难度。
q 等幂消息。向软件代理发送多次重复消息的效果和发送单条消息相同。这一限定使提供者和消费者能够在出现故障时简单的复制消息，从而改进服务可靠性。

9 精确定义的服务接口

服务是由提供者和使用者间的契约定义的。契约规定了服务使用方法及使用者期望的最终结果。此外，还可以在其中规定服务质量。此处需要注意的关键点是，服务契约必须进行精确定义。
meta将soa定义为：“一种以通用为目的、可扩展、具有联合协作性的架构，所有流程都被定义为服务，服务通过基于类封装的服务接口委托给服务提供者，服务接口根据可扩展标识符、格式和协议单独描述。”该定义的最后部分表明在服务接口和其实现之间有明确的分界。

soa的优点

了解了soa的定义和基本特征，最后我们再来看看soa潜在的优点：

编码灵活性

可基于模块化的低层服务、采用不同组合方式创建高层服务，从而实现重用，这些都体现了编码的灵活性。此外，由于服务使用者不直接访问服务提供者，这种服务实现方式本身也可以灵活使用。

明确开发人员角色

例如，熟悉bes的开发人员可以集中精力在重用访问层，协调层开发人员则无须特别了解bes的实现，而将精力放在解决高价值的业务问题上。

支持多种客户类型

借助精确定义的服务接口和对xml、web服务标准的支持，可以支持多种客户类型，包括pda、手机等新型访问渠道。

更易维护

服务提供者和服务使用者的松散耦合关系及对开放标准的采用确保了该特性的实现。

更好的伸缩性

依靠服务设计、开发和部署所采用的架构模型实现伸缩性。服务提供者可以彼此独立调整，以满足服务需求。

更高的可用性

该特性在服务提供者和服务使用者的松散耦合关系上得以体现。使用者无须了解提供者的实现细节，这样服务提供者就可以在weblogic集群环境中灵活部署，使用者可以被转接到可用的例程上。

soa可以看作是b/s模型、xml/web service技术之后的自然延伸。soa将能够帮助我们站在一个新的高度理解企业级架构中的各种组件的开发、部署形式，它将帮助企业系统架构者以更迅速、更可靠、更具重用性架构整个业务系统。较之以往，以soa架构的系统能够更加从容地面对业务的急剧变化。