现在的Web服务实现往往是简单的，通常类似于客户端-服务器模型。然而，平台中立的交换是受支持的，这就使一系列不同的客户端实现可以与作为服务器函数的新代码或遗留代码进行交互。许多文章都介绍了使这样的应用程序直接实现的技术。现在是看一看我们能够如何使用它们的更大的图景的时候了。作者解决了如何由简单的模型转移到代表现实的任意复杂度的业务模型的问题。

　　公元前 221 年，秦始皇将以前交战的几个国家统一为一个新的国家，我们现在称之为中国。中国作为一个国家存在下来的一个可能的原因就是秦朝引入了标准，标准巩固了文化，促进了贸易：标准的轮距使得马车可以有效地行使在任何的道路，共同的书面语言使得每个人都可以交换信息（即使他们说的并不是相同的语言），而坚固的工事（比如中国的长城）使得人们可以防御外敌入侵。您可以说，他为标准化传输、消息交换和防火墙开发了一些模型。

　　同样地，现代的业务集成同样也受益于标准，它使异构的计算机系统能够有效地互操作。这些技术合在一起称作 Web 服务。Web 服务的出现是以 SOAP 1.1 的引入为标志的，SOAP 1.1 定义了将 XML 内容用于分布式系统，而同时隐藏实现的细节。四年后的今天，许多公司正在使用 Web 服务，并且可以毫无疑问地地说，业界正处在 Web 服务主流时代的开端。

　　BM 将面向服务的体系结构（Service-Oriented Architecture，SOA）视为它的按需（On demand）业务前景的互操作性和灵活性的关键。面向服务的体系结构（SOA）支持跨企业和业务合作伙伴之间间的端到端集成。这就提供了一种灵活的业务流程模型，使得客户可以迅速地响应新的顾客需求、新的业务机会以及竞争的威胁。

　　什么是面向服务的体系结构（SOA）？

　　面向服务的体系结构（SOA）表示您可以如何使用 Web 服务的大图景。Web 服务规范定义了实现服务以及与它们的交互所需要的细节。然而，面向服务的体系结构（SOA）是一种用于构建分布式系统的方法，采用 SOA 这种方法构建的分布式应用程序可以将功能作为服务交付给终端用户，也可以构建其他的服务。面向服务的体系结构（SOA）可以基于 Web 服务，但是它可能改为使用其他的技术来代替。在使用面向服务的体系结构（SOA）设计分布式应用程序时，您可以将 Web 服务的使用从简单的客户端-服务器模型扩展成任意复杂的系统。

　　因而，单个的软件资产成为开发其他应用程序的基本构件。您可以通过与新的代码和遗留代码一起使用的共同交互方式来减少系统的复杂性（CBDi 的 Lawrence Wilkes 开玩笑说，面向服务的体系结构（SOA）可以代表”节省我们的资产（Save Our Assets）”）。有一种标准的方法可以用于表示这些软件资产和与它们交互；现在人们关注的重点已经转移到基于这些构件的应用程序装配上来了。

　　虽然在这里讨论的是用于业务应用程序的面向服务的体系结构（SOA），但是面向服务的体系结构（SOA）同样也可以用于其他的分布式系统，比如网格计算和高级 Web 服务规范（例如，Web 服务分布式管理（WS-DistributedManagement）、Web 服务信任（WS-Trust）以及 UDDI）。

　　什么是服务？

　　在面向服务的体系结构（SOA）中， 服务（service）是封装成用于业务流程的可重用组件的应用程序函数。它提供信息或简化业务数据从一个有效的、一致的状态向另一个状态的转变。用于实现特定服务的流程并不重要，只要它响应您的命令并为您的请求提供高质量的服务就可以了。

　　通过定义的通信协议，可以调用服务来强调互操作性和位置透明性。一个服务表现为一个软件组件，因为从服务请求者的角度来看，它看起来就像是一个自包含的函数。然而，实际上，服务的实现可能包括在一个企业内部的不同计算机上或者许多业务合作伙伴拥有的计算机上执行的很多步骤。就封装的软件而言，服务可能是一个组件，也可能不是一个组件。如同类对象，请求者应用程序能够将服务看作是一个整体。

　　eb 服务是以使用 SOAP 消息（它是用像 HTTP 这样的标准协议上的 WSDL 来描述的）的调用为基础的。使用 Web 服务的最佳实践就是与外部的业务伙伴通信。

　　松耦合

　　服务请求者到服务提供者的绑定与服务之间应该是松耦合的。这就意味着，服务请求者不知道提供者实现的技术细节，比如程序设计语言、部署平台，等等。服务请求者往往通过消息调用操作–请求消息和响应–而不是通过使用 API 和文件格式。

　　这个松耦合使会话一端的软件可以在不影响另一端的情况下发生改变，前提是消息模式保持不变。在一个极端的情况下，服务提供者可以将以前基于遗留代码（例如，COBOL）的实现完全用基于 Java 语言的新代码取代，同时又不对服务请求者造成任何影响。这种情况是真实的，只要新代码支持相同的消息模式。

　　明确定义的接口

　　服务交互必须是明确定义的。Web 服务描述语言（Web services Description Language，WSDL）是受到广泛支持的方法，用于描述服务请求者所要求的绑定到服务提供者的细节。服务描述的重点在于与下面几部分交互所用的操作：

　　服务

　　调用操作的消息

　　构造这种消息的细节

　　关于向何处发送用于构造这种消息的处理细节的消息的信息

　　WSDL 不包括服务实现的任何技术细节。服务请求者不知道也不关心服务究竟是由 Java 代码、C#、COBOL，还是由某种其他的程序设计语言编写的。它可以描述使用 HTTP 的 SOAP 调用。由于它的扩展机制，它也可以定义其他类型的交互，比如通过 JMS 提交的 XML 内容、直接方法调用、由管理遗留代码的适配器处理的调用（CICS），等等。

　　WSDL 的通用定义允许开发工具创建各种各样类型的交互的通过接口，同时隐藏它是如何由应用程序代码调用服务的细节。例如，如果服务是以多种交互类型公开的，Web 服务调用框架（Web Services Invocation Framework，WSIF）通过允许运行时决定调用高质量服务的最优方法来使用这种能力。

　　无状态的服务设计

　　服务应该是独立的、自包含的请求，在实现时它不需要从一个请求到另一个请求的信息或状态。服务不应该依赖于其他服务的上下文和状态。当需要依赖时，它们最好定义成通用业务流程、函数和数据模型，而不是实现构件（比如会话密钥）。当然，请求者应用程序需要服务调用之间的持久状态，但是这不应该与服务提供者分开。

　　这里有一个定义会话的 错误方法的示例：

　　Requester: “What is Bruce’s checking account balance?”

　　Provider: “$x”

　　Requester: “And what is his credit limit?”

　　Provider: “$y”

　　提供者被要求记住请求之间 Bruce 的帐号，这就在服务实现中引入了复杂性。无状态的服务设计将重新定义会话，如下所示：

　　Requester: “What is Bruce’s checking account balance?”

　　Provider: “$x”

　　Requester: “What is Bruce’s credit limit?”

　　Provider: “$y”

　　服务粒度

　　操作的粒度是一项重要的设计要点。对于外部的消耗推荐使用粗粒度的接口，而细粒度的接口可能用于企业内部。粗粒度接口可能是特定服务的完整处理，例如 SubmitPurchaseOrder ，在这里消息包括定义订购单所需的所有业务信息。细粒度接口可能具有用于以下方法的不同操作： CreateNewPurchaseOrder 、 SetShippingAddress 、 AddItem ，等等。

　　虽然细粒度的接口为请求者应用程序提供了更多的灵活性，它同样也意味着交互的模式可能随着不同的服务请求者而不同。这可能使对于服务提供者的支持更加困难。粗粒度接口保证服务请求者将以一致的方式使用服务。面向服务的体系结构（SOA）不要求使用粗粒度接口，但是推荐使用它们作为外部集成的最佳实践。服务编排可以用来创建运行由细粒度操作组成的业务流程的粗粒度接口。

　　服务质量需要考虑的问题

　　面向服务的体系结构（SOA）设计将跨越计算机系统，并且还可能跨越企业边界。您不得不考虑在使用 Internet 时安全性功能和需求以及如何链接伙伴的安全域。Internet 协议并不是为可靠性（有保证的提交和提交的顺序）而设计，但是您不得不确保消息被提交并被处理一次。当这不可能时，请求者必须知道请求并没有被处理。

　　例如，您可能需要考虑您所部署服务的度量、可靠性以及响应时间，以便确保它们在承诺的范围之内。当您设计使用来自其他业务伙伴的服务的系统时，您就不得不考虑面向服务的管理来以协作方式管理伙伴之间的服务。

　　结束语

　　本文的重点讲解的是，在面向服务的体系结构（SOA）中扩大软件资产价值的同时控制分布式应用程序中的复杂性所带来的好处。它也定义了服务的性质并分析了它们的特征、以及一些最佳实践。