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. Messaging Concepts In the given architecture, u can see the JMS and MSMQ messaging concepts are used. Here the brief notes on these concepts. JMS JMS is a set of interfaces and associated semantics that define how a JMS client accesses the facilities of an enterprise-messaging product. Enterprise messaging is recognized as an essential tool for building enterprise applications and Ecommerce systems, and JMS provides a common way for Java programs to create, send, receive, and read an enterprise messaging system's messages. You can learn more about JMS in the following URL: http://www.microsoft.com/windows2000/technologies/communications/msmq/default.asp Conclusion In this part of the Web services tutorial we learned how to write interoperable Web services. All examples were focused on the integration of MS .NET and Java. We demonstrated that Web services technology gives us the opportunity to pick the best technology for each particular piece of our system. Some of us may want to know how to create web services in Java and C#, and also more details on integration of JMS and MSMQ with web services. Those things we are not discussed here. If you have doubts on those areas, please feel free to contact me at