More and more we’re finding that WSDL lies at the heart of Web services interoperability. WSDL is the description language for Web services. Usually a WSDL document is automatically generated by Web services framework tools (e.g., Axis, WASP WSDLCompiler) from the code written in a particular programming language. Developers can use the WSDL document to generate client-side stubs or proxies, which provide convenient access to Web services. Thus the key to enabling seamless Web services interoperability is the ability of one Web services framework to consume the WSDL documents generated by other frameworks. The WSDL interoperability effort is just taking off. You can see further details at http://soap.systinet.net/interop/wsdl/index.html.

How to not get trapped

The following subchapters give you some basic tips on how to write interoperable Web services using today’s Web services frameworks. These tips may significantly ease your life as well as the lives of other developers who will use your Web services. Hopefully some of those tips will be outdated soon.

Keep your types simple – avoid advanced XML Schema constructs

The XML Schema standard is very complex and difficult to implement. Moreover, XML Schema processing is quite time consuming, so many frameworks sacrifice full XML Schema support for performance. Some advanced XML Schema constructs (e.g., choice) are quite hard to express in a programming language, and few Web services frameworks support them. So the key success factor in Web services interoperability is to use basic data types, such as primitive data types, arrays, and structures. As a best practice, decompose the complex types in your interfaces into simple and clean interfaces with basic data types. Also avoid using specific techniques (e.g. INOUT parameter passing) that aren’t widely supported.

Sample ArchitectureLet we see the architecture of my sample application which uses web services along with messaging concepts.

Here 3 web services are used. Two web services, Place Order and Get Order are developed and deployed in Java environment and another one, Send Message is in C# environment.

The Ordering System calls the Place Order web service to place an item to order. The Place Order web service stores that item and notifies the Java Expeditor Client through JMS. After the intimation message has come from JMS the Java Expeditor Client calls the Get Order web service to retrieve the ordered items and details. The same Place Order web service calls the another web service, Send Message to send the message to MSMQ, then the Notification message is sent to the C# Expeditor Client from MSMQ. After the intimation message has come from MSMQ, the C# Expeditor Client calls the Get Order web service to retrieve the ordered items and details. Here functionality of the Java Expeditor and C# Expeditor Client are same except that they are developed in different platform to illustrate the interoperability of web services. So here its proved that web service Get Order, which is developed and deployed in Java environment is accessed from the C# Expeditor client and the web service Send Message, which is developed and deployed in C# environment is accessed from Place Order web service of Java environment.