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

引言

Web 服务希望并且承诺将分散的应用程序以一种无缝的方式进行集成。但企业应用程序是在不同的平台上采用不同的技术构建的，因此，跨业务的集成并不是一件轻而易举的事。最近出现的基于 Web 服务的业务流程执行语言（BPEL）为定义 Web 服务的行为提供了一个高层描述语言。它提供一个标准和可移植的语言来将多个 Web 服务融合到一个商业流程中。由于 BPEL 受到一些主要厂商的欢迎，一些用来自动设计商业流程的集成开发工具，如 IBM® WebSphere® Studio Application Developer Integration Edition (Application Developer) 已经进入市场。这些工具减少了 Web 服务集成时需要的大量编码工作，并允许您通过拖拽 WSDL 文件到工具中的方式构建商业流程。我们期望这些工具能够自动产生调用 Web 服务的客户端的存根。因此，集成的成功目前很大程度上一来于底层复杂的工具支撑。这就更加要求开发成员采用最佳实践来确保共享 Web 服务的内在互操作性。

正如我在本文以及随后的文章中所讲的，以下几个问题需要特别关注：

利用厂商工具根据实现代码得到 WSDL 中的 Web 服务语言非常方便。但是这种方式忽略了消息脚本的设计，但这一点正是异构的环境（如 J2EE 技术对.NET）中 Web 服务互操作的关键。

流行的 RPC/encoded 方式以其简单、灵活且熟悉的特点对开发人员是个有吸引力地选择。然而，在厂商之间对抽象 SOAP 编码数据模型的同步实现带来的困难成为 Web 服务互操作的一个困难性的挑战。

弱类型的集合对象、包含空元素的数组和特定的本地数据类型都给互操作性带来一定的问题，特别是：

对于厂商提供的工具来讲，准确地解释代表弱类型集合对象的 XML 脚本并将它们映射到本地数据类型是不可能的。

带有空元素的数组的 XML 表示在 .NET 和 Websphere 之间是不同的。

由于本地数据类型和 XSD 数据类型并不具有一一对应关系，在转换过程中，信息或精度将会丢失。

由于使用相对 URI 引用，Java 技术和 .NET之间不同命名转换将会导致命名空间冲突。

从 WSDL 开始

所有 Web 服务的互操作问题都可以归结到 WSDL 文件上。WSDL 是 Web 服务的接口定义语言（IDL）和服务器与客户间的协议。服务语法，即 WSDL 文件中的消息类型、数据类型和交互方式，是构建松耦合的系统的关键。尽管 WSDL 并不要求使用特定的类型系统， XML 脚本数据类型（XSD）在 Web 服务领域内广受欢迎。

XSD 提供了大量的内置的基本类型并允许服务提供者进一步定义定制的复杂类型。XSD 的类型系统比任何编程语言的类型系统都更加复杂和强大，并且更重要的是，它是独立于编程语言的，因此，它成为 WSDL 定义 Web 服务语法的逻辑起点。

理论上讲，就像 COM 和 CORBA 的 IDL，您应该首先创建并编辑 WSDL --在您基于 WSDL中的服务语法来构建 Web 服务和特定实现语言的客户程序之前，定义接口、消息和数据类型。

然而，事实上，即使经验丰富的都不会那么做。他们最初开始实现特定于语言的接口，如 Java 接口，然后依赖厂商的工具从它们的实现代码中获取 WSDL 服务语法；再把这些 WSDL 服务语法交给 Web 服务客户程序以便根据 WSDL 找出如何来调用 Web 服务。最后，在他们经常不需要知道 WSDL 之前， 他们就能够创建并运行复杂的 Web 服务。他们可能在异构的环境中运行他们的客户和服务器程序，即或者 J2EE 平台，或者 .NET 平台，或者二者都有。

目前厂商的集成开发工具下面的方向发展，即所有的东西，包括 WSDL都可以自动生成，不需要写任何代码（或者，至少许多厂商都声称并希望如此）。这一趋势很有吸引力，因为它开发效率很高，且相对于人工编码它很少出错（当然在工具功能合适且可靠的

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