Web Services Interoperability

Interoperability is one of the main promises of Web services. Web services are designed to be independent of the underlying operating system and programming language. In this article we will address some basic web services interoperability issues that are useful for developers. We will focus on the two most popular platforms - Java and Microsoft C#. Introduction 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 Architecture Let 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. Accessing Java Web Service from C# To invoke the Get Order web service in C# Expeditor Client application, we are going to Add Web Reference to the Get Order web service. The steps to be followed to do this are, 1. In Project menu, click Add Web Reference