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

　　 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 ？

　　不同种类的操作系统，应用软件，系统软件和应用基础结构（ application infrastructure ）相互交织，这便是 IT 企业的现状。一些现存的应用程序被用来处理当前的业务流程（ business processes ），因此从头建立一个新的基础环境是不可能的。企业应该能对业务的变化做出快速的反应，利用对现有的应用程序和应用基础结构（ application infrastructure ）的投资来解决新的业务需求，为客户，商业伙伴以及供应商提供新的互动渠道，并呈现一个可以支持有机业务（ organic business ）的构架。 SOA 凭借其松耦合的特性，使得企业可以按照模块化的方式来添加新服务或更新现有服务，以解决新的业务需要，提供选择从而可以通过不同的渠道提供服务，并可以把企业现有的或已有的应用作为服务， 从而保护了现有的 IT 基础建设投资。

　　如图 1 的例子所示，一个使用 SOA 的企业，可以使用一组现有的应用来创建一个供应链复合应用（ supply chain composite application ），这些现有的应用通过标准接口来提供功能。

　
　 Figure 1. Supply chain application. Click on thumbnail to view full-sized image.

　　服务架构

　　为了实现 SOA ，企业需要一个服务架构，图 2 显示了一个例子：

　　
Figure 2. A sample service architecture. Click on thumbnail to view full-sized image.

　　在图 2 中， 服务消费者（ service consumer ）可以通过发送消息来调用服务。这些消息由一个服务总线（ service bus ）转换后发送给适当的服务实现。这种服务架构可以提供一个业务规则引擎（ business rules engine ），该引擎容许业务规则被合并在一个服务里或多个服务里。这种架构也提供了一个服务管理基础（ service management infrastructure ），用来管理服务，类似审核，列表（ billing ），日志等功能。此外，该架构给企业提供了灵活的业务流程，更好地处理控制请求（ regulatory requirement ），例如 Sarbanes Oxley （ SOX ），并且可以在不影响其他服务的情况下更改某项服务。

　　 SOA 基础结构

　　要运行，管理 SOA 应用程序，企业需要 SOA 基础，这是 SOA 平台的一个部分。 SOA 基础必须支持所有的相关标准，和需要的运行时容器。图 3 所示的是一个典型的 SOA 基础结构。接下来的章节将逐一讨论该结构的每个部分。

　　 Figure 3. A typical SOA infrastructure. Click on thumbnail to view full-sized image.

　　 SOAP ， WSDL ， UDDI

　　 WSDL ， UDDI 和 SOAP 是 SOA 基础的基础部件。 WSDL 用来描述服务； UDDI 用来注册和查找服务；而 SOAP ，作为传输层，用来在消费者和服务提供者之间传送消息。 SOAP 是 Web 服务的默认机制，其他的技术为可以服务实现其他类型的绑定。一个消费者可以在 UDDI 注册表（ registry ）查找服务，取得服务的 WSDL 描述，然后通过 SOAP 来调用服务。

　　 WS-I Basic Profile

　　 WS-I Basic Profile ，由 Web 服务互用性组织（ Web Services Interoperability Organization ）提供，是 SOA 服务测试与互用性所需要的核心构件。服务提供者可以使用 Basic Profile 测试程序来测试服务在不同平台和技术上的互用性。

　　 J2EE 和 .Net

　　尽管 J2EE 和。 NET 平台是开发 SOA 应用程序常用的平台，但 SOA 不仅限于此。像 J2EE 这类平台，不仅为开发者自然而然地参与到 SOA 中来提供了一个平台，还通过他们内在的特性，将可扩展性，可靠性，可用性以及性能引入了 SOA 世界。新的规范，例如 JAXB （ Java API for XML Binding ），用于将 XML 文档定位到 Java 类； JAXR （ Java API for XML Registry ）用来规范对 UDDI 注册表（ registry ）的操作； XML-RPC （ Java API for XML-based Remote Procedure Call ）在 J2EE1.4 中用来调用远程服务，这使得开发和部署可移植于标准 J2EE 容器的 Web 服务变得容易，与此同时，实现了跨平台（如。 NET ）的服务互用。

　　服务品质

　　在企业中，关键任务系统（ mission-critical system ，译注：关键任务系统是指如果一个系统的可靠性对于一个组织是至关重要的，那么该系统就是该企业的关键任务系统。比如，电话系统对于一个电话促销企业来说就是关键任务系统，而文字处理系统就不那么关键了。）用来解决高级需求，例如安全性，可靠性，事物。当一个企业开始采用服务架构作为工具来进行开发和部署应用的时候，基本的 Web 服务规范，像 WSDL ， SOAP ，以及 UDDI 就不能满足这些高级需求。正如前面所提到的，这些需求也称作服务品质（ QoS ， quality of services ）。与 QoS 相关的众多规范已经由一些标准化组织（ standards bodies ）提出，像 W3C （ World Wide Web Consortium ）和 OASIS （ the Organization for the Advancement of Structured Information Standards ）。下面的部分将会讨论一些 QoS 服务和相关标准。

　　安全

　　 Web 服务安全规范用来保证消息的安全性。该规范主要包括认证交换， 消息完整性和消息保密。该规范吸引人的地方在于它借助现有的安全标准，例如， SAML （ as Security Assertion Markup Language ）来实现 web 服务消息的安全。 OASIS 正致力于 Web 服务安全规范的制定。

　　可靠

　　在典型的 SOA 环境中，服务消费者和服务提供者之间会有几种不同的文档在进行交换。具有诸如“仅且仅仅传送一次”（ once-and-only-once delivery ），“最多传送一次”（ at-most-once delivery ），“重复消息过滤”（ duplicate message elimination ），“保证消息传送”（ guaranteed message delivery ）等特性消息的发送和确认，在关键任务系统（ mission-critical systems ）中变得十分重要。 WS-Reliability 和 WS-ReliableMessaging 是两个用来解决此类问题的标准。这些标准现在都由 OASIS 负责。

　　策略

　　服务提供者有时候会要求服务消费者与某种策略通信。比如，服务提供商可能会要求消费者提供 Kerberos 安全标示，才能取得某项服务。这些要求被定义为策略断言（ policy assertions ）。一项策略可能会包含多个断言。 WS-Policy 用来标准化服务消费者和服务提供者之间的策略通信。

　　控制

　　当企业着手于服务架构时，服务可以用来整合数据仓库（ silos of data ），应用程序，以及组件。整合应用意味着例如异步通信，并行处理，数据转换，以及校正等进程请求必须被标准化。在 SOA 中，进程是使用一组离散的服务创建的。 BPEL4WS 或者 WSBPEL （ Web Service Business Process Execution Language ）是用来控制这些服务的语言。 WSBPEL 目前也由 OASIS 负责。

　　管理

　　随着企业服务的增长，所使用的服务和业务进程的数量也随之增加，一个用来让系统管理员管理所有运行在多相环境下的服务的管理系统就显得尤为重要。 WSDM （ Web Services for Distributed Management ）规定了任何根据 WSDM 实现的服务都可以由一个 WSDM 适应（ WSDM-compliant ）的管理方案来管理。

　　其它的 qos 特性，比如合作方之間的溝通和通訊，多個服務之間的事務處理，都在 WS-Coordination 和 WS-Transaction 標準中描述， 這些都是 OASIS 的工作。

　　 SOA 不是 Web 服务

　　在理解 SOA 和 Web 服务的关系上，经常发生混淆。根据 2003 年 4 月的 Gartner 报道， Yefim V. Natis 就这个问题是这样解释的：“ Web 服务是技术规范，而 SOA 是设计原则。特别是 Web 服务中的 WSDL ，是一个 SOA 配套的接口定义标准：这是 Web 服务和 SOA 的根本联系。”从本质上来说， SOA 是一种架构模式，而 Web 服务是利用一组标准实现的服务。 Web 服务是实现 SOA 的方式之一。用 Web 服务来实现 SOA 的好处是你可以实现一个中立平台，来获得服务，而且随着越来越多的软件商支持越来越多的 Web 服务规范，你会取得更好的通用性。

　　 SOA 的优势

　　 SOA 的概念并非什么新东西， SOA 不同于现有的分布式技术之处在于大多数软件商接受它并有可以实现 SOA 的平台或应用程序。 SOA 伴随着无处不在的标准，为企业的现有资产或投资带来了更好的重用性。 SOA 能够在最新的和现有的应用之上创建应用； SOA 能够使客户或服务消费者免予服务实现的改变所带来的影响； SOA 能够升级单个服务或服务消费者而无需重写整个应用，也无需保留已经不再适用于新需求的现有系统。总而言之， SOA 以借助现有的应用来组合产生新服务的敏捷方式，提供给企业更好的灵活性来构建应用程序和业务流程。

　　 About the author

　　 Raghu R. Kodali is consulting product manager and SOA evangelist for Oracle Application Server. Kodali leads next-generation SOA initiatives and J2EE feature sets for Oracle Application Server ， with particular expertise in EJB ， J2EE deployment ， Web services ， and BPEL. Prior to product management ， Kodali held presales and technical marketing positions in Oracle Asia-Pacific ， based in Singapore. Prior to Oracle ， he worked as software developer with National Computer Systems ， Singapore. He holds a master's degree in computer science and is a frequent speaker at technology conferences. Kodali maintains an active blog at Loosely Coupled Corner