引言

Web 服务越来越多地用于企业应用程序集成（Enterprise Application Integration，EAI），在 EAI 中，服务使用者和服务提供者使用企业服务总线（Enterprise Service Bus，ESB）进行通信。企业应用程序的集成由来已久了，通常是通过创建应用程序适配器完成的，应用程序适配器会将消息转换为内部专用格式和协议。

从表面上看，使用 Web 服务对应用程序进行集成似乎是和以前的集成方案一样（或者，至少十分相似）的概念。但与过去相比，Web 服务能使标准化程度更高，且能提供更好的工具，平台与编程语言间的互操作性也更好。

描述系统的相关服务接口仍然是一个挑战。开发人员通常使用两种方法之一应对这项挑战。一方面，Web 服务描述语言（Web Services Description Language，WSDL）定义可以利用消息的 XML 架构描述，允许准确描述交换的消息。另一方面，很多服务均使用通用接口构建：一个字符串传入，另一个字符串传出，或者交换纯二进制对象。对消息的正确解释的工作留给了使用者和提供者。尽管在出现更改时，认为这种方法更为灵活（因为消息的具体细节在服务实现中处理），但同时也更容易出错，而且要求进行更多的手动编程工作。

在本文中，我将比较这两种方式，并会就每种方式的应用场合进行举例说明。

松散类型 Web 服务

首先，让我们定义本文范围内的松散类型这一术语。松散类型意味着服务的接口定义（使用 WSDL）不包含强定义服务所使用的任何消息格式的架构。也就是说，应用程序可以不完全单独遵从来自服务接口定义的消息实例。

松散类型描述的一个例子就是将消息的实际内容编码为单个字符串的 Web 服务。此服务接口描述一个 xsd:string 类型的输入参数和一个输出参数。其 WSDL 部分可能与下面的清单 1 类似。

清单 1. WSDL

type="xsd:string"/>

请注意，由于这是“包装的文档/文本”Web 服务，因此包装元素称为“execute”。（此处并显示所有 WSDL，但剩余部分肯定包含文档/文本绑定。）单个输入和输出参数定义以粗体突出显示。

对于此定义，您并不能准确地知道请求和响应消息的内容的格式。它可能为字符分隔的字符串、固定长度的字符串，或者，甚至可以是 XML。无论何种情况，服务使用者和服务提供者需要就双方都能理解的共同格式达成一致，而且双方都需要开发代码以正确地构建和解释该格式。由于消息内容的具体定义并没有包括在 WSDL 定义中，因此这里没有可提供帮助的工具。

有利的一面是，如果消息结构发生更改，您无须更改新 WSDL 定义。只要确保所有的参与方均知道这一更改，并且能处理更改后的格式就行了。不过，此方法的缺点通常比优点更为突出，特别在将 XML 作为内容发送时更是如此。

1 2 3 4 5 下一页>>