Testing Web Services

Cross-Platform Consumers

Web Services are most useful when then can bridge the gap between platforms. Traditionally it has been somewhat difficult for applications running on Solaris or another UNIX platform to communicate with a Windows application without a large infrastructure such as CORBA in place. Sometimes even communicating with a database can be difficult in this situation.

Web Services provide hope for simple integration between platforms. With just a Web server and some software, applications can bridge the gap between platforms fairly easily. This section covers consumers that call not only .NET but also Java Web Services at the same time.

.NET GUI Consumer

.NET comes with several tools that help you consume Web Services. The main caveat rests with the fact that .NET requires WSDL to make a proxy that communicates with the service. Ensuring that your project has the ability to generate WSDL greatly increases the chances of compatibility with Web Services under .NET.


Remember that it is entirely possible that you can receive WSDL that is perfectly valid but still isn’t compatible with .NET. Therefore, it is important for you to test early and often for compatibility with .NET while creating a cross-platform Web Services project.

Create proxies for each of the Web Services shown in this chapter in Visual Studio.NET or with the WSDL tool. For further information on how to create proxies for .NET, refer to Chapter 6.

With the Java Web Services you’ll find that .NET will give the Java Web Services names that are hard to use. For example, the name will mimic a package name in Java that might look like this: samples.simplestock.SimpleStockService (which is how you would need to use the name in C#). You can rename these class names in the “Solution Explorer” window of Visual Studio.NET and, thus, make your coding in C# clearer. For the following example, the Web references for the Java services were renamed to SoapId and AxisId. Figure 9.9 shows the renamed Web Services in the “Solutions Explorer” window.

click to expand
Figure 9.9: “Solution Explorer” in Visual Studio.NET displaying the renamed Web References.

Now create a C# windows application in Visual Studio.NET. Drag and drop one text box and three buttons onto the form. Label the buttons according to which Web Service they call. The following code snippet highlights the code behind each button.

Because both examples use proxies to call the .NET and Java Web Services, the code to call each service is very similar. The first step is to define a String that can accept the return value of the method. The next step is to create an object of the class that utilizes the Web Service. Then the method is called with the new object and the result is put into the String defined earlier, and then displayed in the text box. This code is repeated for all three buttons with the only difference being the objects called.

    private void button1_Click(object sender, System.EventArgs e)     {        String returnValue;        NetId.Service1 idNum1 = new NetId.Service1();        returnValue = idNum1.ServiceId();        textBox1.Text = returnValue;     }     private void button2_Click(object sender, System.EventArgs e)     {        String returnValue;        SoapId.ApacheSoapIdService idNum2 =        new SoapId.ApacheSoapIdService();        returnValue = idNum2.ServiceId();        textBox1.Text = returnValue;     }     private void button3_Click(object sender, System.EventArgs e)     {        String returnValue;        AxisId.ApacheAxisIdService idNum3 =        new AxisId.ApacheAxisIdService();        returnValue = idNum3.ServiceId();        textBox1.Text = returnValue;     } 

Once you compile and execute your code, the running program looks like Figure 9.10.

click to expand
Figure 9.10: The CallXPlatform program calling a .NET Web Service.

Notice that the first button has already been clicked and the results of calling the .NET Web Service are shown in the text box.

Clicking on the second button calls the Apache SOAP Web Service. Figure 9.11 shows that the .NET client in this case was successfully able to contact the service.

click to expand
Figure 9.11: The CallXPlatform program calling an Apache SOAP Web Service.

The third button calls the Apache Axis service, and also displays the results. Figure 9.12 shows the CallXPlatform program calling the Apache Axis Web Service.

click to expand
Figure 9.12: The CallXPlatform program calling an Apache Axis Web Service.

Think about this example. With very little work you easily integrated a piece of software written in C# with services created in both .NET and Java. This gives you a great deal of flexibility because you can pick and choose which task you want each technology to accomplish. For example, Visual Studio.NET comes with a lot of tools that make creating Windows programs fast and easy—much easier, in fact, than using a Java Interactive Development Environment (IDE) such as Sun One Studio or a different Java IDE under Windows. By choosing the Microsoft technology, you are able to pick the tool that best fits the application. In another situation, it may make sense to use a Java client on a UNIX system because that’s really your only choice. Microsoft claims that eventually .NET will be available under Linux and possibly other flavors of UNIX, but for now it is easy to choose which technology is best for the platform with which you are working.

For example, the majority of people in the workplace have a PC on their desktop, but many large corporations have Solaris or some other UNIX platform running on large servers. By being able to utilize Web Services on either platform, you can either write an application for the PC, have Web pages that communicate with the Web Service that can be hosted on either platform, or have applications running on the large UNIX servers that also integrate with the Web Services.

Java Program

As you’ve seen in previous chapters, it is not necessary to create a proxy for a Java program to call any Web Service, but it does make coding the call much easier and succinct. Chapter 8 discusses how to create proxies for Java. Here it’s just a matter of pointing the WSDL2Java tool in Axis to the appropriate URL that contains the WSDL.

The following example creates a java proxy for for the .NET Web Service.

    java org.apache.axis.wsdl.WSDL2Java     http://localhost/XPlatform/MSNETID/Service1.asmx?wsdl

Then, to create the proxy for the Apache SOAP service, you need the URL of the WSDL file. In the following example, the WSDL file sits within the SOAP directory of Tomcat.

    java org.apache.axis.wsdl.WSDL2Java     http://localhost:8080/soap/GetId.wsdl

Next, to call the Axis WSDL, simply send the proxy tool the URL of WSDL. Remember that Axis is just like .NET in that by putting WSDL in the query string you’ll get the appropriate code.

    java org.apache.axis.wsdl.WSDL2Java     http://localhost:8080/axis/ApacheAxisId.jws?wsdl

When these proxies are created, they all have different package names based on the namespaces the proxy tool encounters. You’ll notice that the following Java client imports several packages that have names based on the namespaces found in the WSDL. Remember that to utilize these packages you’ll need to change into the appropriate directory and compile the .java files.

The following example defines the class GetAllTypes, which simply contains a main method that utilizes all the proxies created previously to call all the different Web Services. Then, code similar to the examples in Chapter 8 calls each of the example Web Services.

    import localhost.*;     import apache_soap_id.*;     import com.advocatemedia.www.*;     public class GetAllTypes {        public static void main(String [] args) throws        Exception {        //Set up Var for results         String result;        //Call MS .NET        //The package name comes from the namespace        //designated in the .NET Web Service        Service1Locator myService1 = new Service1Locator();        com.advocatemedia.www.Service1Soap myNET        =myService1.getService1Soap();        result = myNET.serviceId();        System.out.println(result);        result = null;        //Call Apache SOAP        ApacheSoapIdServiceLocator myService2 = new        ApacheSoapIdServiceLocator();        apache_soap_id.ApacheSoapId mySoap =        myService2.getRpcrouter();        result = mySoap.serviceId();        System.out.println(result);        result = null;        //Call Apache Axis        ApacheAxisIdServiceLocator myService3 = new        ApacheAxisIdServiceLocator();        localhost.ApacheAxisId myAxis =        myService3.getApacheAxisId();        result = myAxis.serviceId();        System.out.println(result);         } }

Figure 9.13 displays the output of the previous example from the DOS prompt.

click to expand
Figure 9.13: The output of GetAllTypes Java program that connects with all three of the Web Services.

With this example, Java calls all the different types of Web Services covered in this book including .NET. With Java being so cross-platform compatible, even a program executing under UNIX or another platform that supports Java could call a Web Service in .NET.

Cross-Platform Web Services Using C# and Java
Cross-Platform Web Services Using C# & JAVA (Charles River Media Internet & Web Design)
ISBN: 1584502622
EAN: 2147483647
Year: 2005
Pages: 128

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net