面向服务的体系结构扩展Web服务的前景

面向服务的体系结构扩展Web服务的前景

撰文/ Mark Colan

公元前221年，秦始皇将连年征战的几个国家统一为一个新国家，我们现在称之为中国。中国作为一个国家存在下来的一个可能原因就是秦朝引入了标准，标准巩固了文化，促进了贸易：标准的轮距使得马车可以有效地行使在任何的道路，共同的书面语言使得每个人都可以交换信息（即使他们说的并不是相同的语言），而坚固的工事（比如中国的长城）使得人们可以防御外敌入侵。您甚至可以说，他们为标准化传输、消息交换和防火墙开发了一些模型。
同样地，现代的业务集成同样也受益于标准，它使异构的计算机系统能够有效地互操作。这些技术合在一起称作Web服务。Web服务的出现是以 SOAP 1.1 的引入作为标志的，SOAP 1.1 定义了将 XML 内容用于分布式系统，而同时隐藏实现的细节。四年后的今天，许多公司正在使用 Web 服务，并且可以毫无疑问地说，业界正处在 Web 服务主流时代的开端。
IBM 将面向服务的体系结构（Service-Oriented Architecture，SOA）视为它的随需应变（On Demand）业务前景的互操作性和灵活性的关键。面向服务的体系结构（SOA）支持跨企业和业务合作伙伴之间的端到端（End to End）集成。这就提供了一种灵活的业务流程模型，使得客户可以迅速地响应新的顾客需求、新的业务机会以及竞争的威胁。

什么是面向服务的体系结构（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）是封装成用于业务流程的可重用组件的应用程序函数。它提供信息或简化业务数据从一个有效的、一致的状态向另一个状态的转变。用于实现特定服务的流程并不重要，只要它响应您的命令并为您的请求提供高质量的服务就可以了。
通过定义的通信协议，可以调用服务来强调互操作性和位置透明性。一个服务表现为一个软件组件，因为从服务请求者的角度来看，它看起来就像是一个自包含的函数。然而，实际上，服务的实现可能包括在一个企业内部的不同计算机上或者许多业务合作伙伴拥有的计算机上执行的很多步骤。就封装的软件而言，服务可能是一个组件，也可能不是一个组件。如同类对象，请求者应用程序能够将服务看作是一个整体。
Web 服务是以使用 SOAP 消息（它是用像 HTTP 这样的标准协议上的 WSDL 来描述的）的调用为基础的。使用 Web 服务的最佳实践就是与外部的业务伙伴通信。

松耦合
服务请求者到服务提供者的绑定与服务之间应该是松耦合的。这就意味着，服务请求者不知道提供者实现的技术细节，比如程序设计语言、部署平台，等等。服务请求者往往通过消息调用操作——请求消息和响应——而不是通过使用 API 和文件格式。
这个松耦合使会话一端的软件可以在不影响另一端的情况下发生改变，前提是消息模式保持不变。在一个极端的情况下，服务提供者可以将以前基于遗留代码（例如，COBOL）的实现完全用基于 Java 语言的新代码取代，同时又不对服务请求者造成任何影响。这种情况是可实现的，只要新代码支持相同的消息模式。

明确定义的接口
服务交互必须是明确定义的。Web 服务描述语言（Web Services Description Language，WSDL）是受到广泛支持的方法，用于描述服务请求者所要求的绑定到服务提供者的细节。服务描述的重点在于与下面几部分交互所用的操作：
l 服务
l 调用操作的消息
l 构造这种消息的细节
l 关于向何处发送用于构造这种消息的处理细节的消息的信息
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、SetShipping-Address、AddItem，等等。
虽然细粒度的接口为请求者应用程序提供了更多的灵活性，它同样也意味着交互的模式可能随着不同的服务请求者而不同。这可能使对于服务提供者的支持更加困难。粗粒度接口保证服务请求者将以一致的方式使用服务。面向服务的体系结构（SOA）不要求使用粗粒度接口，但是推荐使用它们作为外部集成的最佳实践。服务编排可以用来创建运行由细粒度操作组成的业务流程的粗粒度接口。

服务质量需要考虑的问题
面向服务的体系结构（SOA）设计将跨越计算机系统，并且还可能跨越企业边界。您不得不考虑在使用 Internet时安全性功能和需求以及如何链接伙伴的安全域。Internet协议并不是为可靠性（有保证的提交和提交的顺序）而设计，但是您不得不确保消息被提交并被处理一次。当这不可能时，请求者必须知道请求并没有被处理。
例如，您可能需要考虑您所部署服务的度量、可靠性以及响应时间，以便确保它们在承诺的范围之内。当您设计使用来自其他业务伙伴的服务的系统时，您就不得不考虑面向服务的管理来以协作方式管理伙伴之间的服务。

服务工作角色
同 Web 服务一样，面向对象的体系结构（SOA）中有两个关键角色：服务请求者和服务提供者。一个或多个提供者应用程序通过发送请求消息并处理响应消息来提供服务，请求者应用程序调用这些服务。
一些服务提供者同时也是服务请求者：它们聚集其他服务提供者的功能来构造复合的更高级别的服务。通过使用Java、C#或者象业务流程执行语言（BPEL）那样的特殊编排语言来完成这种组合。
一些像UDDI和WS-Trust的SOA技术提出了第三种角色，叫做服务代理（Service Broker）。 服务代理是服务提供者和服务请求者之间的中介——服务本地化，代理托管方案等等。
使用这三种角色建模的实体使用服务调用（Service Invocation，例如SOAP消息）来通信。

服务调用
W3C SOAP1.2规范在服务请求者和服务提供者之间定义使用XML格式的消息进行通信。将应用程序请求（封装在XML中）放入SOAP信封中（也是XML），并从请求者到提供者发送应用程序请求，提供者发回的响应也采用相同的形式。市场上的大部分产品支持早期的 SOAP1.1规范，但是在未来产品发布中将支持 SOAP1.2。由于已经有许多关于SOAP的内容，进一步内容请参阅相关的的出版物。
因为SOAP是平台无关和厂商无关的标准，因此在带有单独IT基础架构的合作伙伴之间的松耦合互操作中，SOAP是支持服务调用的最好方法。然而，SOA不需要使用SOAP。
例如，在SOAP之前，一些公司使用IBM WebSphere MQ来给其它的计算机发送XML文档，其他计算机依据这些文档执行应用程序操作。使用 HTTPS接口的eBey XML以相似的方式来传递用于拍卖的物品条目。虽然由于没有使用SOAP而不能调用Web服务，但是仍然可以在SOA中调用服务。当然，目前WebSphere MQ也对 SOAP消息提供了直接支持。
只要所有的实体是用Java语言编写，那么就可以仅仅使用J2EE中的可用功能来创建SOA。然而，这种方法不能为非Java应用程序的互操作性提供令人满意的解决方案。
在企业内部需要为IT系统控制代码的地方，可以考虑使用SOAP之外的服务调用方法，这些方法可能没有构建并解析XML内容。这就会有更好的性能，并且可以避免围绕现有功能编写SOAP封装代码。出于对简单性的需求，能够使用其他协议调用服务的单一调用API样式是一个很好的实践。

多重协议服务调用
JAX-RPC规范（也叫 JSR-101）定义了一个 Java API，使从 Java 程序中调用 Web 服务变得简单。JAX-RPC实现至少必须支持使用HTTP的 SOAP1.1。然而，为了服务调用它可能还支持其他的协议。 多重协议服务调用能够使用相同的API指定不同的协议，例如改变URL。
WebSphere Application Server当前版本中的 JAX-RPC实现是 JSR-101-compliant，但允许简单的通过将URL修改为对JMS服务器（比如 WebSphere MQ）寻址的形式来使用JMS上的SOAP调用。在不久的将来，这种多重协议样式将允许使用IIOP上的RMI 进行服务调用，以使EJB服务实现有效的互操作。
简单性的关键是不考虑协议而使用相同的API。让这成为可能的是在WSDL中描述协议的能力，这些协议不同于HTTP上的SOAP。

服务描述
Web服务描述语言（WSDL）规范定义了一个 XML词汇表，该词汇表依照请求和响应消息，在服务请求者和服务提供者之间定义了一种契约。你能够将 Web服务定义为软件，这个软件通过描述SOAP消息接口的WSDL文档来提供可重用的应用程序功能，并使用标准的传输协议来进行传递。
WSDL描述包含必要的细节以便服务请求者能够使用特定服务：
l 请求消息格式
l 响应消息格式
l 向何处发送消息
WSDL是基于XML的，因此WSDL文档是计算机可读的（Machine-Readable）。这样开发环境使用WSDL 将集成服务的流程自动处理到请求者应用程序。例如 WebSphere Studio产生一个 Java 的代理对象，它能够像本地对象一样实现服务，但是实际上代理对象仅仅处理请求的创建和响应消息的解析。不管服务是否用 Java，C#或者其他的语言实现，生成的Java代理对象都能够从 WSDL 描述中调用任何的 Web 服务。实际上，WSDL不能像编程语言那样描述实现细节。
WSDL使用它的扩展功能并通过与HTTP上的 SOAP不同的协议来支持服务定义。依据SOA，你能够将任何可以用WSDL描述接口的应用程序功能称为服务。当SOA不特别的需要WSDL时—你可以使用其他服务描述语言—目前大部分厂商和产品都支持 WSDL。

信息交换模式
在流行的请求-响应（Request-Response）交换模式中，服务请求者向服务提供者（或端点）发送请求消息，处理完请求之后，提供者将响应消息发送给请求者。服务互操作可以是会话式的，由若干对请求-响应构成。然而，为了性能、设计的简单性和从松耦合中获得好处，设计粗粒度接口是一个好办法，它能够将事务需要的交换数量最小化。
除了请求-响应模式之外，WSDL还定义了以下内容：
l 将单向（One-way）消息发送到端点—例如，不需要响应的请求：
l 从端点发送的单向消息，叫做通知：
l 要求-响应（Solicit-Response） 模型，端点通过它发送消息和接收响应：
目前SOA实现通常使用HTTP，导致了同步通信 —在处理之前请求者等待响应。同步交换用于预期完成时间相对较短（几秒或几分钟）的服务。
也可能有异步服务互操作，在异步服务互操作中服务请求者不等待响应，而是期望以后交付响应。这适合于长时间运行的事务。例如调用一个业务流程来请求指定的客机报价，流程包括许多合作伙伴或人的互操作，这要花几天或是几周来完成。使用异步交换能够避免失去连接（因为服务器维护等等）以及因此而失去响应的风险。
Web服务寻址（WS-Addressing）规范将Reply-to地址作为SOAP信封报头元素的扩展。服务请求者将请求排队放入WSDL文档中指定的端口，但是不需要等待。相反，在响应到达之前，它做其他的工作。当服务提供者准备发送响应时，使用SOAP中的Reply-to地址：请求消息的报头。
使用像WebSphere MQ这样的消息队列产品时，可以使用JMS来实现同步消息。请求者可以选择为请求排队但是不等待处理的完成。当执行其他工作时，要定时检查响应队列中的响应。
你可以应用同步消息的方法来创建其他的交换模式，比如接收多重通知请求（例如在股票报价变更的通知）。
服务发现
尽管服务调用和服务描述通常被认为是SOA的需求，但服务发现也是它的可选功能。UDDI（通用描述、发现和集成协议）为发布服务的可用性和发现所需服务定义了一个标准接口（基于SOAP消息）。UDDI实现将发布和发现服务的SOAP请求解释为用于基本数据存储的数据管理功能调用。
为了发布和发现其他Web服务，UDDI通过定义标准的SOAP消息来实现服务注册（Service Registry）。注册是一种服务代理，它是在UDDI上需要发现服务的请求者和发布服务的提供者之间的中介。一旦请求者决定使用特定的服务，开发者通常借助于开发工具（例如IBM WebSphere Studio 或者Microsoft Visual Studio .NET）并通过创建以发送请求并处理响应的方式访问服务的代码来绑定服务。
发现用于构建SOA应用程序的服务，其结果就象电子黄页一样。你可以使用工具（比如WebSphere中的UDDI Browser）在应用系统设计期间寻找合适的服务。SOA不需要使用UDDI，但由于UDDI是建立在 SOA上来完成自身工作的，所以UDDI是服务发现的一个好的解决方案。
正如在Steve Graham的文章“Six Species of UDDI”中提到的，你能够用多种不同的方法使用UDDI。本文特别指出了在IT组织内 UDDI 的使用，主要是为了管理内部服务以提高可重用性以及进一步促进端点无关性。例如，应用程序中可能会缓存所需服务的位置。如果服务重新部署到不同的服务器当中，服务请求者能够使用UDDI发现新的位置并将它缓存以备将来使用。当内部部署UDDI时，使用 UDDI服务请求者应用程序将自动适应于服务部署的变更（例如，为维护负载平衡而做的变更）。
随着UDDI的发展，它将广泛的用于发现由市场模型中其他组织所提供的公共可用的（Publicly-A协议vailable）业务服务。正如我们将在关于服务编排的文章中所讨论的，UDDI在运行时对服务的UDDI动态选择方面很有用的。

结束语
本文重点讲解的是，在面向服务的体系结构（SOA）中扩大软件资产价值的同时控制分布式应用程序中的复杂性所带来的好处。它也定义了服务的性质并分析了它们的特征、以及一些最佳实践。同时本文讨论了SOA的基本元素以及它们相互发现和互操作的方法。你通过开发服务目录（内部的或合作伙伴的）来创建基于SOA的IT体系结构，并编写代码使用这些服务来开发出新的应用程序。由于服务提供者能够通过请求其他服务来完成自己的工作，在设计上就可以使用服务的分层结构。虽然简单的请求-响应消息模型最为流行，但是你可以使用其他的消息模型灵活的设计系统。WSDL 文档告诉你如何集成服务，UDDI帮助你找到所需的服务。