当对跨越异构的环境产生互操作性要求时，问题变得比较明显。现在，您从实现语言来创建 Web 服务交互的关键构件，然后利用平台独立的工具将它们映射到 WSDL 中语言独立的元素。当客户平台上的工具根据 工具生成的 WSDL 来产生服务代理时，将进行另外一个映射。这一流程基于下面的事实，WSDL 是 Web 服务的接口定义语言。语言独立的 WSDL 应该成为客户和服务器的共同基础。以这种方式使用开发工具将双倍增加映射过程中信息丢失的可能。

这并不意味着您应该放弃这些工具，所有的厂商应该停止生产并在市场上销售这些工具。在当前的企业应用程序开发领域自动化已经成为一个重要的因素。工具本身很强大，关键在您怎么利用它们的力量？您可以利用这些工具产生一个框架 WSDL 来作为起点或者模板。脚本、消息部件和数据绑定必须仔细设计来遵循 WS-I 一致性要求。就像您出于数据库效率的考虑而不希望由工具产生数据库脚本一样，您不应该忽视手工设计高效 Web 服务消息和数据类型。有时，即使元素的名字也要仔细设计来遵循潜在的异构平台间的命名转换。对于 Web 服务互操作性来讲， WSDL 是唯一比较重要的构件。程序员必须学会基于原始 XML 消息进行编程，至少学会读取 XSD、 WSDL 和 SOAP 消息。

提高J2EE技术和.NET之间的互操作性，第1部分(2)

仍旧采用 RPC/encoded？

WS-I基本规范提出采用文本 XML 实现互操作。它禁止对 soap:Envelope 或派生的 soap:Body 元素使用 soap:encodingStyle 属性。因此， RPC/literal 和 Document/literal 是 WS-I 标准唯一支持的 2 种格式。但是有许多 Web 服务工具不支持 RPC/literal ，因此，它将 Document/literal 作为唯一的实际互操作性标准。

然而，采用 RPC/encoded 方式来处理在 XML 脚本或 WSDL 出现之前就已经存在很久；另外，一些编码规则仍旧不能够采用 XSD 来表述。尽管 SOAP 编码被认为 Web 服务互操作性问题的主要根源，以及 ASP.NET WebMethod 基础设施缺省采用 Document/literal，直到现在，大部分 J2EE Web 服务缺省采用 RPC/encoded 方式。

RPC/encoded 方式受欢迎主要因为对于习惯了远程过程调用惯例的程序员来说是较为简单的编程模型。RPC 绑定方式采用方法名称和参数来产生代表方法调用堆栈的结构，因此，它使 Web 服务看起来像一个带有封装对象的单一的逻辑组件，所有操作都在 SOAP RPC 堆栈中处理。这一点与 Document/literal 方式相反，在那种方式下，程序员不得不处理所有的事务，包括基于 XML 的 SOAP 消息的序列化和逆序列化。

另外，SOAP 编码规则定义了标准，方便了从编程类型到 XML 的映射。编码规则非常灵活并支持图形数据和多态的表示。因此，它毫无疑问比 Document/literal 更适合，后者依赖于自然树结构来表示数据对象。

为了对 RPC/encoded 能做什么、不能做什么有个清晰的概念，让我们看一个示例。Serializable Person 类定义了一个它自己的友元，如 清单 1所示。

清单 1. 自引用的 Person 类public class Person implements java.io.Serializable { 　　 private Person friend; 　　 private String name; 　　 public Person getFriend() { 　　　　 return this.friend; 　　 } 　　 public void setFriend(Person friend) { 　　　　 this.friend = friend; 　　 } <!-- Other setter and getter methods --> }

如果您初始化 2 个 Person：A 和 B，并使 Person A 成为 Person B 的友元，使 Person B 成为 Person A 的友元，那么您创建了一个循环的对象图：

清单 2. makeFriend 方法public Person makeFriend(Person A,

凌众科技专业提供服务器租用、服务器托管、企业邮局、虚拟主机等服务，公司网站：http://www.lingzhong.cn 为了给广大客户了解更多的技术信息，本技术文章收集来源于网络,凌众科技尊重文章作者的版权，如果有涉及你的版权有必要删除你的文章，请和我们联系。以上信息与文章正文是不可分割的一部分,如果您要转载本文章,请保留以上信息，谢谢!