面向服务的体系结构（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 的需要来源于需要使业务
下面举一个具体的例子。一个服装零售组织拥有 500 家国际
另一种形式是内部改变，在这种改变中，零售组织现在决定它还将把连锁零售商店内的一些地方出租给专卖流行衣服的小商店，这可以看作是采用店中店（store-in-store）的业务模型。这里，虽然公司的大多数业务操作都保持不变，但是它们现在需要新的内部软件来处理这样的出租安排。尽管在内部软件系统可以承受全面的检修，但是它们需要在这样做的同时不会对与现有的供应商系统的交互产生大的影响。在这种情况下，SOA 模型保持原封不动，而内部实现却发生了变化。虽然可以将新的方面添加到 SOA 模型中来加入新的出租安排的职责，但是正常的零售管理系统继续如往常一样。
为了延续内部改变的观念，IT 经理可能会发现，软件的新配置还可以以另外的一种方式加以使用，比如出租粘贴海报的地方以供广告之用。这里，新的业务提议是通过在新的设计中重用灵活的 SOA 模型得出的。这是来自 SOA 模型的新成果，并且还是一个新的机会，而这样的新机会在以前可能是不会有的。
垂直改变也是可能的，在这种改变中，零售商从销售他们自己的服装完全转变到专门通过店中店模型出租地方。如果垂直改变完全从最底层开始的话，就会带来 SOA 模型结构的显著改变，与之一起改变的还可能有新的系统、软件、流程以及关系。在这种情况下，SOA 模型的好处是它从业务操作和流程的角度考虑问题而不是从应用程序和程序的角度考虑问题，这使得业务管理可以根据业务的操作清楚地确定什么需要添加、修改或删除。然后可以将软件系统构造为适合业务处理的方式，而不是在许多现有的软件平台上常常看到的其他方式。
正如您可以看到的，在这里，改变和 SOA 系统适应改变的能力是最重要的部分。对于开发人员来说，这样的改变无论是在他们工作的范围之内还是在他们工作的范围之外都有可能发生，这取决于是否有改变需要知道接口是如何定义的以及它们相互之间如何进行交互。与开发人员不同的是，架构师的作用就是引起对 SOA 模型大的改变。这种分工，就是让开发人员集中精力于创建作为服务定义的功能单元，而让架构师和建模人员集中精力于如何将这些单元适当地组织在一起，它已经有十多年的历史了，通常用统一建模语言（Universal Modeling Language，UML），并且描述成模型驱动的体系结构（Model-Driven Architecture，MDA）。
构成 SOA 的技术是什么？
SOA 本身是应该如何将软件组织在一起的抽象概念。它依赖于用 XML 和 Web 服务实现并以软件的形式存在的更加具体的观念和技术。此外，它还需要安全性、策略管理、可靠消息传递以及会计系统的支持，从而有效地工作。您还可以通过分布式事务处理和分布式软件状态管理来进一步地改善它。
SOA 服务和 Web 服务之间的区别在于设计。SOA 概念并没有确切地定义服务具体如何交互，而仅仅定义了服务如何相互理解以及如何交互。其中的区别也就是定义如何执行流程的战略与如何执行流程的战术之间的区别。而另一方面，Web 服务在需要交互的服务之间如何传递消息有具体的指导原则；从战术上实现 SOA 模型是通过 HTTP 传递的 SOAP 消息中最常见的 SOA 模型。因而，从本质上讲，Web 是实现 SOA 的具体方式之一。
尽管我们觉得 Web 服务是实现 SOA 的最好方式，但是 SOA 并不局限于 Web 服务。其他使用 WSDL 直接实现服务接口并且通过 XML 消息进行通信的协议也可以包括在 SOA 之中。正如在别处指出的，CORBA 和 IBM 的 MQ 系统通过使用能够处理 WSDL 的新特征也可以参与到 SOA 中来。如果两个服务需要交换数据，那么它们还会需要使用相同的消息传递协议，但是数据接口允许相同的
既为了建立所有这些信息的适当控制，又为了应用安全性、策略、可靠性以及会计方面的要求，在 SOA 体系结构的框架中加入了一个新的软件对象。这个对象就是企业服务总线（Enterprise Service Bus，ESB），它使用许多可能的消息传递协议来负责适当的控制、流甚至还可能是服务之间所有消息的传输。虽然 ESB 并不是绝对必需的，但它却是在 SOA 中正确管理您的业务流程至关重要的组件。ESB 本身可以是单个引擎，甚至还可以是由许多同级和下级 ESB 组成的分布式系统，这些 ESB 一起工作，以保持 SOA 系统的运行。在概念上，它是从早期比如消息队列和分布式事务计算这些计算机科学概念所建立的存储转发
从开发人员的角度来说，他们使用的工具必须知道 SOA 的能力，并允许开发人员有效地使用 SOA 对象。这将设计 SOA 模型、开发服务和服务对象以及测试 SOA 应用程序这些过程包括进来并组成一个整体。因而，开发人员的工作必须为面向服务的应用程序设计/开发（Service-Oriented Application Design/Development，SOAD）做好准备。
SOA 与其他技术的关系如何？
SOA 可以与许多其他技术结合在一起使用，然而，组件的封装和聚合在其中扮演着重要的角色。如前所述，SOA 可以是一个简单对象、复杂对象、对象的集合、包含许多对象的流程、包含其他流程的流程，甚至还可以是输出单一结果的应用程序的整体集合。在服务之外，它可以看作是单个实体，但是在其自身中，它可以具有任何级别的复杂性（如果必要的话）。出于性能方面的考虑，大多数 SOA 服务并没有下降到单一对象的粒度，并且更适合于大中型组件。
除了可能离不开 XML 和 WSDL 之外，SOA 并不是特定于语言的。可以用任何编程语言来实现服务，只要这种编程语言可以生成服务并且可以与 WSDL 结合在一起使用就可以了。SOAP 本身并不是绝对需要的，但它是通用的消息传递系统。因此，可以使用几乎任何一种编程语言和支持 WSDL 的平台来实现 SOA 中的成员服务。
基于通用对象请求代理体系结构（Common Object Broker Request Architecture，CORBA）的应用程序有许多组件必须连接到 SOA 中。虽然 CORBA 中的接口描述语言（Interface Description Language，IDL）在概念上类似于 WSDL，但它不是严格的，因而首先需要将其映射到 WSDL。另外，需要使用更高级的 SOA 协议（比如用于流程和策略管理的协议），而不是 CORBA 中的类似的概念。请记住，这是 CORBA 组件（表示为服务）需要与 SOA 服务交互的情况；在 CORBA 模型中，所有的独立子集仍然可以像以前一样工作。
由对象管理组（Object Management Group）提出并在许多 IBM Rational 产品中得以实现的模型驱动体系结构在一个更抽象的层次上与 SOA 的概念具有很强的相关性。MDA 基于这样的概念，任何软件流程都可以定义为模型甚至是元模型（即模型的模型），然后可以将这些模型和元模型转换成应用程序的实际组件。因此，MDA 创建了一个模型，这个模型先编译成软件应用程序，而软件应用程序接着又编译成可执行程序，这样就可以在平台上运行了。MDA 并不区分服务和对象这两个概念，但是它确实允许模型由其他子集模型本身组成，这类似于 BPEL（SOA 的一个核心组件）中的流程聚合的概念。
SOA 和 Web 服务是独立于编程语言的，但 Java 是主要的开发语言之一。可以使用定义良好的
SOA 与 Web 的另一个重要的关系是自主计算和网格计算的概念。自主计算的概念应用于管理分布式服务体系结构的范围，具体来说，就是帮助维护策略和服务级协议以及 SOA 系统的总稳定性。
另外，网格计算可以以两个级别与 SOA 系统一起使用。网格是分布式计算的一种形式，它利用分布式特性和服务之间的交互来为 SOA 应用程序提供计算支持。在这种情况下，网格起到了框架的作用，其中实现了一些或所有单独的服务。因此，SOA 应用程序可以是网格服务的消费者。
在另一方面，网格本身也可以构建在 SOA 之上。在这种情况下，每个操作系统服务都是构成整个 SOA 应用程序的成员，而 SOA 应用程序就是网格本身。因此，单独的网格组件既可以使用 Web 服务进行通信，又可以以 SOA 的方式进行交互。总而言之，网格系统可以是 SOA 本身，也可以提供服务来在其上构建应用程序级 SOA 模型。
