面向服务的体系结构（Service-Oriented Architecture，SOA）是一个组件模型，它将应用程序的不同功能单元（称为服务）通过这些服务之间定义良好的接口和契约联系起来。接口是采用中立的方式进行定义的，它应该独立于实现服务的硬件平台、操作系统和编程语言。这使得构建在各种这样的系统中的服务可以一种统一和通用的方式进行交互。

这种具有中立的接口定义（没有强制绑定到特定的实现上）的特征称为服务之间的松耦合。松耦合系统的好处有两点，一点是它的灵活性，另一点是，当组成整个应用程序的每个服务的内部结构和实现逐渐地发生改变时，它能够继续存在。而另一方面，紧耦合意味着应用程序的不同组件之间的接口与其功能和结构是紧密相连的，因而当需要对部分或整个应用程序进行某种形式的更改时，它们就显得非常脆弱。

对松耦合的系统的需要来源于业务应用程序需要根据业务的需要变得更加灵活，以适应不断变化的环境，比如经常改变的政策、业务级别、业务重点、合作伙伴关系、行业地位以及其他与业务有关的因素，这些因素甚至会影响业务的性质。我们称能够灵活地适应环境变化的业务为按需（On demand）业务，在按需业务中，一旦需要，就可以对完成或执行任务的方式进行必要的更改。

虽然面向服务的体系结构不是一个新鲜事物，但它却是更传统的面向对象的模型的替代模型，面向对象的模型是紧耦合的，已经存在二十多年了。虽然基于 SOA 的系统并不排除使用面向对象的设计来构建单个服务，但是其整体设计却是面向服务的。由于它考虑到了系统内的对象，所以虽然 SOA 是基于对象的，但是作为一个整体，它却不是面向对象的。不同之处在于接口本身。SOA 系统原型的一个典型例子是通用对象请求代理体系结构（Common Object Request Broker Architecture，CORBA），它已经出现很长时间了，其定义的概念与 SOA 相似。

然而，现在的 SOA 已经有所不同了，因为它依赖于一些更新的进展，这些进展是以可扩展标记语言（eXtensible Markup Language，XML）为基础的。通过使用基于 XML 的语言（称为 Web 服务描述语言（Web Services Definition Language，WSDL））来描述接口，服务已经转到更动态且更灵活的接口系统中，非以前 CORBA 中的接口描述语言（Interface Definition Language，IDL）可比了。

Web 服务并不是实现 SOA 的惟一方式。前面刚讲的 CORBA 是另一种方式，这样就有了面向消息的中间件（Message-Oriented Middleware）系统，比如 IBM 的 MQseries。但是为了建立体系结构模型，您所需要的并不只是服务描述。您需要定义整个应用程序如何在服务之间执行其工作流。您尤其需要找到业务的操作和业务中所使用的软件的操作之间的转换点。因此，SOA 应该能够将业务的商业流程与它们的技术流程联系起来，并且映射这两者之间的关系。例如，给供应商付款的操作是商业流程，而更新您的零件数据库，以包括进新供应的货物却是技术流程。因而，工作流还可以在 SOA 的设计中扮演重要的角色。

此外，动态业务的工作流不仅可以包括部门之间的操作，甚至还可以包括与不为您控制的外部合作伙伴进行的操作。因此，为了提高效率，您需要定义应该如何得知服务之间的关系的策略，这种策略常常采用服务级协定和操作策略的形式。

最后，所有这些都必须处于一个信任和可靠的环境之中，以同预期的一样根据约定的条款来执行流程。因此，安全、信任和可靠的消息传递应该在任何 SOA 中都起着重要的作用。

我可以用面向服务的体系结构做什么？

对 SOA 的需要来源于需要使业务 IT 系统变得更加灵活，以适应业务中的改变。通过允许强定义的关系和依然灵活的特定实现，IT 系统既可以利用现有系统的功能，又可以准备在以后做一些改变来满足它们之间交互的需要。

下面举一个具体的例子。一个服装零售组织拥有 500 家国际连锁店，它们常常需要更改设计来赶上时尚的潮流。这可能意味着不仅需要更改样式和颜色，甚至还可能需要更换布料、制造商和可交付的产品。如果零售商和制造商之间的系统不兼容，那么从一个供应商到另一个供应商的更换可能就是一个非常复杂的软件流程。通过利用 WSDL 接口在操作方面的灵活性，每个公司都可以将它们的现有系统保持现状，而仅仅匹配 WSDL 接口并制订新的服务级协定，这样就不必完全重构它们的软件系统了。这是业务的水平改变，也就是说，它们改变的是合作伙伴，而所有的业务操作基本上都保持不变。这里，业务接口可以作少许改变，而内部操作却不需要改变，之所以这样做，仅仅是为了能够与外部合作伙伴一起工作。

另一种形式是内部改变，在这种改变中，零售组织现在决定它还将把连锁零售商店内的一些地方出租给专卖流行衣服的小商店，这可以看作是采用店中店（store-in-store）的业务模型。这里，虽然公司的大多数业务操作都保持不变，但是它们现在需要新的内部软件来处理这样的出租安排。尽管在内部软件系统可以承受全面的检修，但是它们需要在这样做的同时不会对与现有的供应商系统的交互产生大的影响。在这种情况下，SOA 模型保持原封不动，而内部实现却发生了变化。虽然可以将新的方面添加到 SOA 模型中来加入新的出租安排的职责，但是正常的零售管理系统继续如往常一样。

为了延续内部改变的观念，IT 经理可能会发现，软件的新配置还可以以另外的一种方式加以使用，比如出租粘贴海报的地方以供广告之用。这里，新的业务提议是通过在新的设计中重用灵活的 SOA 模型得出的。这是来自 SOA 模型的新成果，并且还是一个新的机会，而这样的新机会在以前可能是不会有的。

垂直改变也是可能的，在这种改变中，零售商从销售他们自己的服装完全转变到专门通过店中店模型出租地方。如果垂直改变完全从最底层开始的话，就会带来 SOA 模型结构的显著改变，与之一起改变的还可能有新的系统、软件、流程以及关系。在这种情况下，SOA 模型的好处是它从业务操作和流程的角度考虑问题而不是从应用程序和程序的角度考虑问题，这使得业务管理可以根据业务的操作清楚地确定什么需要添加、修改或删除。然后可以将软件系统构造为适合业务处理的方式，而不是在许多现有的软件平台上常常看到的其他方式。

正如您可以看到的，在这里，改变和 SOA 系统适应改变的能力是最重要的部分。对于开发人员来说，这样的改变无论是在他们工作的范围之内还是在他们工作的范围之外都有可能发生，这取决于是否有改变需要知道接口是如何定义的以及它们相互之间如何进行交互。与开发人员不同的是，架构师的作用就是引起对 SOA 模型大的改变。这种分工，就是让开发人员集中精力于创建作为服务定义的功能单元，而让架构师和建模人员集中精力于如何将这些单元适当地组织在一起，它已经有十多年的历史了，通常用统一建模语言（Universal Modeling Language，UML），并且描述成模型驱动的体系结构（Model-Driven Architecture，MDA）。

对于面向同步和异步应用的，基于请求/响应模式的分布式计算来说，SOA是一场革命。一个应用程序的业务逻辑（business logic）或某些单独的功能被模块化并作为服务呈现给消费者或客户端。这些服务的关键是他们的松耦合特性。例如，服务的接口和实现相独立。应用开发人员或者系统集成者可以通过组合一个或多个服务来构建应用，而无须理解服务的底层实现。举例来说，一个服务可以用.NET或J2EE来实现，而使用该服务的应用程序可以在不同的平台之上，使用的语言也可以不同。

Service-Oriented Device Architecture (SODA),即“面向服务的设备架构”，是一个由IBM和美国Florida大学发起的倡议(Initiative)和联盟(Alliance)，通过引入基于服务（SOA）的编程模型，以规范和简化智能设备（Devices）与企业应用的集成。SODA致力于充分利用嵌入式系统和IT领域已有的标准，为智能设备与SOA技术的融合提供一个标准平台。 SODA的目标是让软件开发者能够像用SOA技术实现IT业务集成那样在诸如远程医疗、军事、以及RFID等物联网系统中实现与传感器和执行器的集成。

具体来说，SODA提供标准接口，把硬件设备功能转换成与硬件无关的可调用的软件服务，实现如下目标：

1. 实现应用集成商与设备和传感器制造商的无缝对接；

2. Integrate once, deploy everywhere, 使用户专注于整体应用方案而不是陷于设备连接工作；

3. 在应用和众多（泛在）设备协议之间建立一个通用接口和DDL，形成统一数据交换标准；

4. 作为一个中间件平台，为众多行业应用提供应用支持。

在这个架构中，设备集成接口定义是关键，也就是所谓的API（Application Programming Interface）和设备描述语言（Device Description Language）的定义。 由于末端设备对实时性以及footprint大小要求较高，一般用REST而不是用SOAP来定义和实现Web Services接口。

SOA的实施具有几个鲜明的基本特征。实施SOA的关键目标是实现企业IT资产的******化重用。要实现这一目标，就要在实施SOA的过程中牢记以下特征：

可从企业外部访问

随时可用

粗粒度的服务接

口分级

松散耦合

可重用的服务

服务接口设计管理

标准化的服务接口

支持各种消息模式

精确定义的服务契约

SOA服务具有平台独立的自我描述XML文档。Web服务描述语言（WSDL， Web Services Description Language）是用于描述服务的标准语言。

SOA 服务用消息进行通信，该消息通常使用XML Schema来定义（也叫做XSD， XML Schema Definition）。消费者和提供者或消费者和服务之间的通信多见于不知道提供者的环境中。服务间的通讯也可以看作企业内部处理的关键商业文档。

在一个企业内部，SOA服务通过一个扮演目录列表（directory listing）角色的登记处（Registry）来进行维护。应用程序在登记处（Registry）寻找并调用某项服务。统一描述，定义和集成（UDDI， Universal Description， Definition， and Integration）是服务登记的标准。

每项SOA服务都有一个与之相关的服务品质（QoS， quality of service）。QoS的一些关键元素有安全需求（例如认证和授权），可靠通信（译注：可靠消息是指，确保消息“仅且仅仅”发送一次，从而过滤重复信息。），以及谁能调用服务的策略。
随着全球信息化的浪潮，信息化产业不断发展、延伸，已经深入了众多的企业及个人，SOA系统架构的出现，将给信息化带来一场新的革命。

纵观信息化建设与应用的历程，尽管出现过XML、Unicode、UML等众多信息标准，但是许多异构系统之间的数据源仍然使用各自独立的数据格式、元数据以及元模型，这是信息产品提供商一直以来形成的习惯。各个相对独立的源数据集成一起，往往通过构建一定的数据获取与计算程序来实现，这样的做法需要花费大量工作。信息孤岛大量存在的事实，使信息化建设的ROI大大降低，ETL成为集中这些异构数据的有效工具。 ETL常用于从源系统中提取数据，将数据转换为与目标系统相兼容的格式，然后将其装载到目标系统中。数据经过获取、转换、装载后，要产生应用价值，还需另外的数据展现工具予以实现，如此复杂的数据应用过程，必定产生高昂的应用成本。
结构化的数据管理尚可通过以上方法，予以实现其集成应用。在非结构化的内容方面，这些具有挑战性的问题令人生畏。内容管理的应用方案基于不同的信息化应用系统，而且大部分是纵向的以组织部门为界限的。在目前的内容管理市场中，经常使用来自不同厂商的产品来提供这些解决方案。即使是同一个厂商的产品，相互之间的功能也是经常重叠，并且无法集成。

随着信息化建设的深入，不同应用系统之间的功能界限已趋于模糊。同时企业资源计划系统和协同商务系统，又需要商业智能的分析展现数据提供用户操作依据。

在激烈竞争且多变的市场环境下，企业的管理模式很难固化，应用传统的信息化软件，当企业要做出一些改动时需要面对巨大的挑战。

微软大中华区服务部总经理辛儿伦介绍说，从上世纪60年代应用于主机的大型主机系统，到80年代应用于PC的CS 架构，一直到90年度互联网的出现，系统越来越朝小型化和分布式发展。2000年WebService出现后，SOA被誉为下一代Web服务的基础框架，目前已经成为计算机信息领域的一个新的发展方向。

SOA的出现给传统的信息化产业带来新的概念，不再是各自独立的架构形式，能够轻松的互相联系组合共享信息。

可复用以往的信息化软件。基于SOA的协同软件提供了应用集成功能，能够将ERP、CRM、HR等异构系统的数据集成。

松散耦合方式，只要充分了解业务的进程，就可以不用编写一行代码，通过流程图实现一套我们自己的信息系统。就像已经给你准备好了砖瓦和水泥，只需要想好盖什么样的房子就可以轻松的盖起。加快开发速度，并且减少了开发和维护的费用。软件将所有的管理提炼成表单和流程，以记录管理的内容，指定过程的流转方向。

更简便的信息和数据集成。信息集成功能可以将散落在广域网和局域网上的文档、目录、网页轻松集成，加强了信息的协同相关性。同时，复杂、成本高昂的数据集成，也变成了可以简单且低成本实现的参数设定。创建了完全集成的信息化应用新领域。

在具体的功能实现上，SOA协同软件所实现的功能包括了知识管理、流程管理、人事管理、客户管理、项目管理、应用集成等，从部门角度看涉及了行政、后勤、营销、物流、生产等。从应用思想上看，SOA协同软件中的信息管理功能，全面兼顾了贯穿整个企业组织的信息化软硬件投入。尽管各种IT技术可以用于不同的用途，但是信息管理并没有任意地将信息分为结构化或者非结构化的部分，因此ERP等结构化管理系统并不是信息化建设的全部;同时，信息管理也没有将信息化解决方案划分为部门的视图，因此仅仅以部分为界限去构建软件应用功能的思想未必是不可撼动的。基于SOA的协同软件与 ERP、CRM等传统应用软件相比，关键的不同在于它可以在合适的时间、合适的地点并且有正当理由而需要它提供服务的任何用户提供服务。