Chapter 9: Java and .NET Web Service Integration

Three Test Web Services

This section shows three different Web Services that identify the Web Service implementation called. This shows that consumers of various types are able to consume Web Services from Apache and Microsoft. Once the three Web Services are created, examples later in the chapter, written in both C# and Java, call all the different types of services.

.NET Web Service

The following Web Service was created in Visual Studio.NET and simply returns the text “This is Microsoft DOT Net.” Even though this Web Service is written in C#, you’ll find that the Java consumers shown later in the chapter are still able to call it with relative ease.

The URL of this Web Service on the author’s machine is http://localhost/XPlatform/MSNETID/Service1.asmx?op=ServiceId

Just like the other .NET Web Service examples shown in Chapter 6, Visual Studio.NET generates much of the code. Notice that the WebService and WebMethod tags are added for further clarification to the consumer. The only other modification needed is to add the method that returns the identifying text.

    using System;     using System.Collections;     using System.ComponentModel;     using System.Data;     using System.Diagnostics;     using System.Web;     using System.Web.Services;     namespace MSNETID     {    [WebService(Description="Web Service that informs a consumer that                this is .NET",                Namespace="http://www.advocatemedia.com/")]      public class Service1 : System.Web.Services.WebService      {           public Service1()           {                //CODEGEN: This call is required by the ASP.NET Web                   //Services Designer                InitializeComponent();           }           #region Component Designer generated code           //Required by the Web Services Designer           private IContainer components = null;           private void InitializeComponent()           {           }           /// <summary>           /// Clean up any resources being used.           /// </summary>           protected override void Dispose( bool disposing )           {                if(disposing && components != null)                {                     components.Dispose();                }                base.Dispose(disposing);           }           #endregion           [WebMethod             (Description="This method just returns that this is MS             .NET")]           public string ServiceId()           {                return "This is Microsoft DOT NET";           }          }     }

Figure 9.3 displays the output of this Web Service in Internet Explorer.

Figure 9.3: The MSNETID Web Service output to Internet Explorer.

The following XML, which is obtained by testing the Web Service in a browser, demonstrates that this Web Service is a Microsoft technology.

    <?xml version="1.0" encoding="utf-8" ?>       <string xmlns="http://www.advocatemedia.com/">            This is Microsoft DOT NET        </string>

Now that you have a Microsoft Web Service, you need Apache SOAP and Axis Web Services in order to demonstrate cross-platform compatibility.

Apache SOAP Web Service

Even though Apache SOAP is obsolete with the advent of Axis, it is still important to study how to consume a SOAP Web Service in case you come across a legacy installation.

This example is similar to the one found in Chapter 7, but instead of a simple stock quote the text “This is Apache SOAP” returns to the client. The service uses the standard import statements and is part of the package samples.javaid. The file needs to be named ApacheSoapId because this is the name of the class defined in the file. The only method defined is ServiceId, and this returns text to identify that this is a SOAP service.

    package samples.javaid;     import java.net.URL;     import java.io.*;     import org.w3c.dom.*;     import org.xml.sax.*;     import javax.xml.parsers.*;     import org.apache.soap.util.xml.*;     public class ApacheSoapId {        public String ServiceId () throws Exception {           return "This is Apache SOAP";        }     }

The following deployment descriptor is used to make the Web Service available to consumers.

<isd:service xmlns:isd="http://xml.apache.org/xml-soap/deployment"      >   <isd:provider type="java"                 scope="Application"                 methods="ServiceId">              <isd:java />   </isd:provider>   <isd:faultListener>org.apache.soap.server.DOMFaultListener </isd:faultListener> </isd:service>

Then, to deploy the service, execute the following command with the environment set up for Apache SOAP. Remember the environment must have all the proper SOAP libraries in CLASSPATH to execute the following command.

java org.apache.soap.server.ServiceManagerClient     http://localhost:8080/soap/servlet/rpcrouter deploy     DeploymentDescriptor.xml

Both .NET and Axis have tools that allow you to create proxies to call other Web Services. Creating a proxy saves you time because it generates a lot of standard code that you would need to write otherwise. Proxies are generated on what appears in a WSDL file. To call this SOAP service easily from both .NET and Axis, you need to create the appropriate WSDL file.

To generate WSDL for an Apache SOAP service, you need to use the Java2WSDL tool found in the Apache Axis distribution. Even though you may be committed to using Apache SOAP for legacy reasons, you need to use the Java2WSDL tool in Axis to generate WSDL for your Web Services.

Creating the WSDL is a little tricky. First you need to compile the Web Service code with an environment set up for Apache SOAP. Once it’s compiled, you need to open another DOS prompt with an environment set up for Axis because you’ll need the classes from that package to create the WSDL. From that DOS window, execute the following command.

    java org.apache.axis.wsdl.Java2WSDL -o GetId.wsdl     -l"http://localhost:8080/soap/servlet/rpcrouter"     -n"urn:apache-soap-id" ApacheSoapId

The -o switch specifies the output file, which in this case is GetId.wsdl. The -l specifies the location of the Web Service, which is the URL included. The -n identifies which Web Services to call. The final option to specify is the name of the class.

Note

If this command fails for you, open the Web Service in your editor and comment out the package statement. Then recompile it within the environment set up for Apache SOAP. The package statement appears to confuse the Java2WSDL tool when it is trying to generate the namespace statements.

Figure 9.4 shows the output of the Java2WSDL tool in Internet Explorer.

Figure 9.4: The WSDL created by the Java2WSDL tool for the Apache SOAP example Web Service.

The WSDL created by the tool is standard and both .NET and Axis proxy generators will be able to use the information in the file to create the appropriate proxies.

Apache Axis Web Service

After looking at the Apache SOAP and Microsoft .NET examples, you’ll probably realize that it is easy to create a Web Service with Axis. Consider the following code.

   public class ApacheAxisId {      public String ServiceId() throws Exception {        return("This is Apache Axis");      }    }

It’s amazing that this little snippet of code creates a Web Service. You simply need to drop the code in Axis’ webapps directory and then point your browser to the following URL to compile the code into the appropriate class file: http://localhost:8080/axis/ApacheAxisId.jws

By adding “wsdl” to the query string, the Web Service displays the WSDL needed to create a proxy. This Web Service provides the WSDL shown in Figure 9.5.

Figure 9.5: The WSDL output of the Axis example Web Service.

Note

The proxy generator in .NET doesn’t always pick up port numbers in URLs. If this happens, you’ll receive an HTTP error number 405 indicating that you do not have permission to access the Web Service. To work around this problem, copy the WSDL file to your local system and use this local file to generate the proxy. This somehow fixes the problem.