SOA(Service Oriented Architecture ，面向服务的体系结构 ) 是由组件、服务、业务过程组成的可以满足机构业务需求的体系结构，是一种非常好的建立复杂系统的体系架构的模型。 SOA 有助于代码重用、降低成本、风险，还可缩短产品进入市场的时间。 <?xml:namespace prefix = o ns = "urn:schemas-microsoft-com:office:office" />

从某种意义上说， SOA 更多是一些指导原则，并不依赖具体的实现技术。尽管 SOA 可以使用其它技术实现 ( 如 CORBA 、 DCOM 、 RMI 、 RPC 可以提供同步通信，而 MOM 则可实现异步通信 ) ， SOA 概念的提出和 Web 服务技术的发展紧密相关，二者通常结合使用。 SOA 规范系统的体系结构， Web 服务技术则提供一种定义服务、提供通信的机制。而且 Web 服务可以集成基于不同应用、不同软件或分布在不同的硬件平台上、由各种不同的系统提供的服务，大大降低成功实施 SOA 的复杂程度。

在 SOA 中，服务是通过接口定义的，并在运行时被调用。服务并不专门针对特定客户，它可以由众多客户共享。这就意味着服务不保留和它所服务的客户对话的状态信息，它是无状态的。无状态并不意味着服务不能有实例数据和在数据库中保存数据。但是，除了在接口中暴露的数据，这些数据对客户来说是不可见的。进一步说，当服务被调用执行时，它并不知道在此之前执行的请求和后面将执行的请求。这给服务带来了一个非常关键的特性 : 每个服务所需信息全部通过调用参数来传递。服务的所有相关任务在一次服务被调用时完成，因为服务通常并不保存从一次调用转移到另一次调用的信息。

用 SOA 建立的系统具有很高的扩展性，由于服务的无状态性也很高效。由于不用保留会话的信息，负载均衡和错误恢复等更易实现。如需提高系统的性能，只用增加新的服务实例的实现 ( 添加更多的服务器 ) 即可。而且，由于每一个服务并不是专门为特定的客户提供服务，大量的客户能共享较少的服务实例 ( 在多线程实现时就是线程 ) 。使用有状态的服务尽管也可以实现上述功能，但复杂性成倍增长，因此通常不这么做。

SOA 的核心概念“重用”和“互操作”己存在了 20 多年。尽管其他分布式技术和标准未能取得成功， SOA 还是有成功的可能。这取决于以下几个因素 :

1. 基于松散藕合产生的灵活性 :SOA 是第一个考虑了业务发展长期性的 IT 架构，它认为变化是永恒的。从本质上说， SOA 是一组松散藕合的服务，服务的建立和替换成本相对低廉。与传统的紧藕合架构相比，松散藕合架构更能适应业务的变化。在 SOA 中可以用一个服务替换另一个服务而无须关心其底层的实现技术，唯一要考虑的服务接口是用通用的 Web 服务和 XML 标准定义的。灵活性带来的另一个好处是可以充分利用现有的 IT 资产 : 遗留应用和数据库，通过将它们纳入 SOA 而不是替换它们来使其成为企业整体解决方案的一部分。这种架构最终将使企业的 IT 架构能够更快速、更有效地适应业务需求的变化，换句话说，就是能够“随需应变”。

2. “业务相关”。 SOA 与其他 TI 架构的最大区别在于它与业务的关联性，一直以来， IT 存在的主要问题是 IT 人员与业务的脱节，而 SOA 中的每一项服务都可以完成实际业务流程中的一项任务，例如，可以把一项服务叫做“更新客户订单状态”。如此一来，服务立刻与业务发生了密切的关系，业务人员可以参与服务的创建并且用它们定义新的业务流程，从而实现服务驱动型企业的目标。由于 Web 服务屏蔽了底层的技术细节，因此业务人员和 IT 人员都可以专注于业务逻辑的实现，二者的共同语言就是“服务”。这是一种全新的思路并且将对企业 IT 系统的建设产生深远的影响。

SOA 带来的两大优势灵活性和业务关联性是过去的 TI 系统不曾提供的，为什么 CORBA 或其他分布式计算技术不具备这些特点 ? 与 SOA 相比， CORBA 更强调技术，它需要一批精通相关技术的开发人员，而这样的技术专家实在不多。 SOA 则相对简单并基于真正的通用标准 Web 服务系列规范，这使得很多人都能掌握其实现技术。

更进一步地来看， CORBA 与 SOA 在架构途径和哲学上都存在一些根本差异。在 SOA 中，分布式的资产是“粗粒度 (coarse grained) ”的服务，它们完成一些有用的功能，诸如“更新客户订单状态”等。而在 CORBA 中，分布式的资产是对象，每一个对象都有自己的属性和方法。例如， Order 对象具有 Status 属性和 Update 方法，对于架构设计师来说处理这些对象是非常烦琐的并且需要具备相当的知识和技能。要保持这些“细粒度”对象的一致性是非常困难的。在 SOA 中，控制和功能可能要弱一些，但是它很容易管理，这种方法的技术性可能不够强，但它却能很好地协调机构和人在 IT 项目中的作用。

SOA 可能成功的一个根本原因是“业务驱动”。仅由 IT 部门设计开发的 IT 架构由于缺少重用能力和企业范围内的一致性，很难获得长期的成功。 SOA 的出现将使我们能看到 IT 与业务完美结合的成功实例 : 业务伙伴帮助推动企业 IT 架构的实现，这并不是因为他们喜欢架构设计，而是因为他们看到了 SOA 与业务的紧密联系。