Web Services Interoperability

 

By Senthil Krishnamurthy from Aspire Systems India (Pvt.) Ltd.

 

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…

2. In the URL box type http://localhost:8888/axis/servlet/AxisServlet (or u can give the web service URL)

3. Now it will show the list of services that are available. From that select Get Order (wsdl) link.

4. Click Add Reference button.

 

We need to create a proxy client to access this web reference. For that we need the wsdl file of that particular web service.

 

Save WSDL file

The AxisServlet generates the wsdl file for the web service.  To get the wsdl for Get Order Web service,

Type this URL in browser: http://localhost:8888/axis/servlet/AxisServlet.

Click on wsdl link belongs to Get Order Web service.

It will display the wsdl xml content. Save this content with .wsdl extension.

 

Create Proxy Client

For the creation of proxy client we can utilize the wsdl tool of Microsoft Visual Studio.

Now, open the Command Prompt (preferably the Visual Studio.NET Command Prompt, which verifies the PATH environmental parameters are set correctly). Navigate to the directory containing the GetOrder.wsdl file. Type the following at the command prompt:

wsdl /o:GetOrderService.cs GetOrder.wsdl

Now the GetOrderService.cs file will be created. This is the proxy class for the referenced web service. So, add this file into the assembly of your C# project. By making instance to this proxy client we can call the Get Order Web service as the following code,

 

 

        GetOrderService GOService = new GetOrderService ();

        string strOrders;

        strOrders = GOService.getOrder ();

 

Accessing .Net Web Service from Java

For accessing the .Net web service we can use the org.apache.soap package and it sub package rpc.  We need to provide the Service URL, Target namespace and the Soap Action which is present in the wsdl file. By using the Call class we can invoke the Web service method as in the following code:

String URLString = "http://localhost/WebService1/Service1.asmx";

        String TargetNamespace = "http://localhost/WebService1/Service1";

        String SOAPAction = "http://Walkthrough/XmlWebServices/sendMessage";

URL url = new URL (URLString);

 //setup a the invocation

Call call = new Call();

        call.setTargetObjectURI (TargetNamespace);

        call.setMethodName ("sendMessage");

        call.setEncodingStyleURI (Constants.NS_URI_SOAP_ENC);

        Response resp = call.invoke (url, SOAPAction);

 

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.chrispeiris.com/articles/JavaMessageService.html

 

MSMQ

Microsoft Message Queuing (MSMQ) technology enables .net applications running at different times to communicate across heterogeneous networks and systems that may be temporarily offline. Applications send messages to queues and read messages from queues. You can get more details on MSMQ from 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 [email protected]