Interoperability Solutions
Fortunately, interoperability between Microsoft- and Java-based SOAP implementations is possible. In fact, with Java products like Axis (first beta release on March 15, 2002) it is becoming easier. The solution to using a Microsoft SOAP client with a Java-based SOAP server requires the creation of a WSDL file for the client. There are at least two solutions to using a Java-based SOAP client with a Microsoft SOAP server. The first approach is to have the client read a WSDL to identify how to structure the send message. The second, less attractive, approach is to hard code details, like the argument names and types. While this approach is tedious and less maintainable, it may be necessary in some cases, like when a Java-based SOAP implementation cannot parse a WSDL file.

Microsoft SOAP Client to Java Server
Using a Microsoft SOAP client with a Java-based SOAP server is straightforward as long as the SOAP server has a WSDL file. Consider the scenario where a user submits form data from a Web page to an ASP page. The ASP page then makes a SOAP request to an Axis Servlet (see Figure 2).

 

The code in the ASP page has two parts. The first part mainly sets which WSDL file is to be used, depending on whether this page should use a Microsoft or Java SOAP server. The second part creates a SoapClient and initializes it with a WSDL file. The call to ClientProperty enables "server safe" loading of the WSDL file. Once the SOAP client initializes the WSDL file, using mssoapinit, the client can then invoke any operation in the first port of the first service of the WSDL file. Recall that in WSDL terminology, a port is a group of operations, a service is a group of ports, and a WSDL file can specify more than one service. So while it is also possible to name a specific service and port in the mssoapinit call, a SoapClient object represents only one port (group of operations) of one service. The line inside the try-block calls the getCondition operation, passing in the value of the city obtained from the HTML form in the Web page.

Listing 1 is from the file weather_ms Client.asp (source code for this article is available at www.sys-con.com/webservices/sourcec.cfm). Notice that this ASP code works whether it sends a request to either a Microsoft or a Java SOAP server. The trick when using a servlet is to create a WSDL file that this client code can use. Fortunately, Axis can automatically generate a WSDL file from Java source code. Point your browser to the URL of the SOAP request handler, adding a WSDL to the URL. A request handler is simply a normal Java source file that is given a .jws, instead of the normal .java, extension. Axis also includes command-line utility to generate a WSDL from a Java source file. IBM, who along with Microsoft authored the WSDL specification, developed this utility, and it is available independent of Axis.

Unfortunately, the generated WSDL file does not always work without modification. It will work with ASP running under IIS 5.0, but you will probably have to modify it to work with ASP for PWS 4.0, as shown below. In the binding section of the WSDL, there is an element named operation in the http://schemas.xmlsoap.org/wsdl/soap/namespace. The value of this element's soapAction attribute goes in the HTTP header of the SOAP request. The generated WSDL sets the value of the soapAction to the empty string. The ASP SOAP client running under PWS expects soapAction to have a value; it can be nearly anything since the Java SOAP server does use it.

The minor edit to the WSDL file, javaServer\WeatherService.wsdl, generated by Axis, looks like this:

<wsdlsoap:operation soapAction="thisIsForPWS" />

Component Design
The component that provides the current weather condition, whether written in Java or Visual Basic, has the same design. It is a class named Weather with just one method, named getCondition.

Component Coding
The Java and Visual Basic code that implement this class have a similar structure, and both use the city name to randomly generate a weather condition.

Looking at the Java source code in Listing 2, notice that the class has two parts. The first defines a list of possible weather conditions and the second is the getCondition method. It initializes a Random object based on the hash code of the city named in the variable where. This code is from the file javaServer\Weather.jws. (Remember that in Axis, Java files have the .jws extension instead of .java. Inside, the Java file has the normal structure.)

Java SOAP Client to Microsoft Server
When a client uses a WSDL file, the JSP code looks much like ASP SOAP client code (discussed earlier). Additionally, the Java client could configure the SOAP service without a WSDL file. With both of these approaches a Web page sends user input to a JSP page, which in turn uses an ASP SOAP server to satisfy the request. The SOAP server uses a COM object written in Visual Basic to produce the return data. Microsoft's SOAP Toolkit includes a utility that generates the ASP SOAP Server page and the WSDL from a COM object (see Figure 3).

 

The JSP page, which uses a WSDL, has two sections. Skipping the page import statements, for now, the first section sets up the WSDL-related parameters, depending on whether it uses a Java or Microsoft SOAP server. The second section creates a SOAP service object based on a service named WSDL file. Remember that WSDL can specify more than one service. From the service object, the code next creates a call object that represents a single operation. Since a WSDL file groups operations into ports, the createCall method must specify which port the operation is in. The last call simply invokes the getCondition operation, passing the value for the city and getting the current in return. Listing 3 is from the file weather_javaClient.jsp.

Most of Listing 3, though written for Axis's SOAP implementation, applies to other Java-based SOAP implementations. Those familiar with Java can tell from the import statements of the first five lines that nothing in the code is unique to Axis. The classes in the import statements beginning with java or javax are standard or standard extension Java classes, and all future Java-based SOAP implementations should use them.

The logic for the Weather class in Visual Basic is the same as the Java code described in the previous section. It has an additional method to generate a hash code from the city.

Example Application
To start the sample applications, load index.html into a browser. It should look like Figure 4. Enter a city, configure the SOAP client and server, and click the "Investigate" button.

 

If you enter Arlington and choose the JSP client and the ASP Server, the resulting Web page should look like Figure 5. Repeat the process, using other names and other SOAP applications.

 

Application Setup
System Requirements
The example in this article requires several technologies. In addition to Microsoft's Internet Information Server (IIS) or Personal Web Server (PWS), and a browser such as Internet Explorer, the samples for this article use the following, freely available, products.

To install the Microsoft SOAP Toolkit, the Visual Basic Run-Time, and the Java 2 SDK, double-click on each of the downloaded files and accept the default installation. Here is a simple procedure for setting up Tomcat and Axis:

Once your system is set up, as described in the System Requirements Section, use the following steps to set up the application.

Conclusion
Interoperability between Microsoft- and Java-based implementations of SOAP continues to be difficult, but possible. Until the W3C produces a stable SOAP recommendation, it is not surprising that there are difficulties. The interoperability issues stem mostly from the use (or non-use) of the WSDL, as well as the differences in the SOAP messages. Microsoft SOAP uses WSDL, most Java-based SOAP does not need it and the W3C has decided not to include WSDL with the SOAP recommendation. For RPC-oriented messages over HTTP, Microsoft SOAP servers expect request messages to have operation information in the HTTP header and use specific names for operation arguments. Java-based SOAP servers do not use HTTP header information, and do not care what name is used for the operation arguments. Java-based SOAP clients and servers put data type information into the request and response messages; Microsoft clients and servers do not.

Solving these interoperability problems is possible. Creating a WSDL for Java-based SOAP implementations solves many of the problems. The samples in this article used a Java-based SOAP implementation from Apache, named Axis (in beta at the time of this writing), which does support WSDL. While the samples used Axis, they are representative of the kind of solution required for any Java-based SOAP implementation.

A Java-based SOAP implementation is quite flexible. It does not require WSDL, and a developer has a lot of control in structuring the client calls. The Microsoft-based implementation, while not as flexible because it requires the WSDL, is a solid implementation that effectively uses WSDL to simplify a developer's task in writing client-side code.