1 2 3 4 5 6 7 下一页

　　引言

　　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 脚本并将它们映射到本地数据类型是不可能的。

(责任编辑：admin)