This article was first published by IBM developerWorks at http://www.ibm.com/developerWorks, and has been reproduced here with permission.
Weaving together Web services to create cross-organizational business processes requires all partners to program to the same standard model and to avoid exposing proprietary implementations. After many years of promoting the interoperability among vendors through joint efforts on standardizing protocols, significant progress has been made. However, the ultimate goal of making Web services interact seamlessly is still a frequent concern and a hot discussion topic. Explore the source of some common interoperability challenges facing Web services integration across platforms and join the author in analyzing a number of interoperability problems resulting from interaction styles, basic data types and structures, and namespace issues between .NET and J2EE technology. Wangming Ye offers best practices that you can use to avoid problems and improve the chances of successful integration. The first part of the series stresses the importance of WSDL design and analyzes the strength and pitfalls of the traditional RPC/encoded style in Web services interoperability.Introduction
Web services technology offers the promise and hope of integrating disparate applications in a seamless fashion. But enterprise applications are built around different technologies and platforms, and integration across businesses is never a trivial task. The relatively recent emergence of Business Process Execution Language (BPEL) for Web services provides a higher-level description language to specify the behavior of Web services. It provides a standard and portable language for orchestrating Web services into business processes. As BPEL was embraced by major vendors, IDE tools designed to automate business process design, such as the IBM® WebSphere® Studio Application Developer Integration Edition (Application Developer), entered the marketplace. The tools eliminate a large amount of required coding in the Web services integration, and allow you to construct business processes by dragging and dropping the WSDL files into the tools. It is expected that the tools automatically generate the client stubs for the participating Web services. As a result, the success of the integration is now largely dependent upon the underlying sophisticated tooling support. This puts an even greater demand on developers to adopt best practices that ensure the inherent interoperability of participating Web services.
As I illustrate in this article and the following articles, several issues require attention:
- Using vendor tools to derive the Web services semantics in WSDL from implementation code is convenient, but this approach ignores the design of the message schemas which is central to Web services interoperability in heterogeneous environments (J2EE technology versus .NET, for example).
- The ease, flexibility, and familiarity of the popular RPC/encoded style makes it an attractive choice for developers; however, the difficulty in synchronizing the implementations of the abstract SOAP encoding data model among vendors presents a difficult challenge for Web services interoperability.
- Weakly-typed collection objects, arrays containing null elements, and certain native data types all pose special problems for interoperability. Specifically:
- It is impossible for vendor tools to accurately interpret XML Schemas representing weakly-typed collection objects and map them to the correct native data types.
- The XML representations of an array with null elements differ between .NET and WebSphere.
- Because native data types and XSD data types do not share a one-to-one mapping, information or precision can be lost during the translation.
- Different naming conventions in .NET and Java technology can result in namespace conflicts, as can the use of relative URI references.
Comments