Web Services Interoperability

Document directory

• Saying hello
• Now what?
• What interoperability means

'); //]>

Web Services, at their core, are technologies designed to improve the interoperability between the specified diverse application development platforms that exist today. and while the reality of Web Services Interoperability is still less than flattering to the cause, great strides have been made over the last year to move things in the right direction. the key point to remember is that over time, interoperability will improve and the current wrinkles that exist in the process of creating, deploying, and consuming Web Services eventually will be ironed out.

 

In this article, I give a brief picture that highlights exactly what interoperability in Web Services means. to do so, I am going to pull an example out of O 'Reilly's recently published programming Web Services with soap, Which I coauthored. the example is the ubiquitous Hello world application evolved into a soap-based Web service. (I bet you were expecting me to say it was a stock quote service, Right? Not this time.) in the book, we implement Hello world in the Java, Perl, And. Net environments, and we demonstrate how to invoke each of them from the other two environments.

Saying hello

To get started, let's write the three Hello World Service implementations, starting with Perl.

Example 1: Hello World module in Perl (Hello. PM)

package Hello;sub sayHello {shift;my $self = "Hello " . shift;}

That was easy enough. now let's write the code that will expose the hello module as a web service. to do so, we will be using soap: Lite for the Perl package writtenProgramming Web Services with soapCoauthor Pavel kulchenko. Using soap: Lite, we will create a perl cgi script that can be deployed into just about any web server environment.

Example 2: Hello World CGI script (Hello. cgi)

use SOAP::Transport::HTTP;SOAP::Transport::HTTP::CGI-> dispatch_to('Hello')-> handle;

Related reading Programming Web Services with soap By James mongonell, Doug mongoidwell, Pavel w.ulchenko Table of contents Index Sample chapter Read online -- SafariSearch this book on safari:

CopyHello. PMFile to your Perl@ INCFolder andHello. cgiFile to your web servers 'cgi-bin root directory and, assuming soap: Lite has been properly installed, the Hello world web service has been deployed and is ready for action.

Now let's do the same thing in Java. Start by creating the hello World Java class.

Example 3: Hello world in Java (Hello. Java)

public class Hello {public String sayHello(String name) {return "Hello " + name;}}

Then, after compiling the class, you will deploy it as a Web service using Apache SOAP Version 2.2. apache currently has two soap implementations available, Version 2.2 and the 3.0 alpha 3, also known as axis. because axis is still highly unstable, I decided to stick with the older, stable version for this example.

The first step to deploying the hello World Java Web Service is to create the Apache SOAP deployment descriptor. the deployment descriptor is an XML file that tells Apache SOAP everything it needs to properly dispatch an incoming SOAP request to the Java class that is responsible for handling it, which in our case isHello.javaClass in Example 3. Our deployment descriptor is shown in Example 4.

Example 4: Hello World Apache SOAP deployment descriptor (Hello. xml)

<dd:service xmlns:dd="http://xml.apache.org/xml-soap/deployment"id="urn:Hello"><dd:provider type="java"scope="Application"methods="sayHello"><dd:java class="Hello" static="false" /></dd:provider><dd:faultListener>org.apache.soap.server.DOMFaultListener</dd:faultListener><dd:mappings /></dd:service>

InProgramming Web Services with soap, We go into significantly more detail about what each of the elements in the deployment descriptor mean. for now though, we're re going to skip over it to keep moving with the discussion about interoperability. make sure that Apache SOAP is properly installed in your Java Web server environment (I use Apache Tomcat 4 ), and ensure that your web server is running and that the compiled Hello class in Example 3 is located somewhere in your web serversClasspath. Then, you can deploy the Java Web service using the following command line, whereHostnameIs the name of your Web server,PortIs the TCP/IP Port your web server is listening on, andHello. xmlIs the path to the deployment descriptor in Example 4. Prior to executing this statement, make sure thatSoap. Jar,Mail. Jar, AndActivation. JarLibraries that ship with Apache SOAP are in your Java classpath.

java org.apache.soap.server.ServiceManagerClient /http://hostname:port/soap/servlet/rpcrouter deploy Hello.xml

The Service Manager Client shoshould return a positive response indicating that the service has been deployed.

Two down, one to go. the next step is to implement the hello World Service. net. to complete this step, you have to have.. NET Framework SDK installed. if you don't, or if you're re running a non-Windows operating system, please just follow along, you'll get the idea.

Example 5: Hello world in. Net (Hello. asmx)

<%@ WebService Language="C#" Class="Hello" %>using System.Web.Services;[WebService(Namespace="urn:Hello")]public class Hello {[ WebMethod ]public string sayHello(string name) {return "Hello " + name;}}

Once written, copyHello. asmxFile into your Microsoft Internet Information Server'sWwwrootDirectory and. NET will take care of the rest. The Hello world. NET web service has been deployed.

Now what?

Now for the interesting part. at this point we have three distinct web services implemented in three different programming versions that all do the exact same thing: They say "Hello. "the test now is to see whether or not three identical services written in three different programming ages can be invoked in such a way that the only difference between CILS is the location of the service. if so, then we 've accomplished our goal of interoperability.

Let's start with Perl calling the Java implementation.

Example 6: Say hello to Perl from Java (Helloclient. pl)

 

use SOAP::Lite;my $proxy = shift;my $name = shift;print "\n\nCalling the SOAP Server to say hello\n\n";print "The SOAP Server says: ";print SOAP::Lite-> uri('urn:Hello')-> proxy($proxy)-> sayHello($name)-> result . "\n\n";

To invoke this script, simply use the following command line, substituting in the appropriate values for your environment.

Perl HelloClient.pl http://hostname:port/soap/servlet/rpcrouter Your-Name

If all goes well, the output you shoshould see is:

Calling the SOAP Server to say helloThe SOAP Server says: Hello Your-Name

What do you think about the progress being made toward Web Services Interoperability?

Post your comments

Congratulations. you 've just demonstrated the fundamental advantage of using Web Services: interoperability. prior to the advent of soap, calling a simple Java class from within Perl was a proverbial pain in the neck. now let's see if it works for calling. net. in theory, we shocould be able to use the exact same Perl script in order to call. net Hello world web service since there is no difference in the types of parameters the Java and. net implementations CT. (both each CT a single string value that contains your name .) so, let's try it. invoke the same Perl Command Line, substituting the location ofHello. asmxFile for the Apache SOAP rpcrouter servlet.

Perl HelloClient.pl http://hostname/hello.asmx Your-Name

The result is not quite what you 'd expect CT. It doesn't work. What happened to interoperability? Well, as with all brand new technologies, Web services still have a bit more wrinkles that need to be worked out. in this case, differences in the way the soap: Lite for Perl and. net implement the soap version 1.1 protocol cause an incompatibility between the two. in order for a soap: Lite application to call. net service, You have to modify the client script a bit to account for the differences. we see the modified script in Example 7. I 've highlighted the changes that need to be made.

Example 7: ModifiedHelloclient. plFor. net

use SOAP::Lite;my $proxy = shift;my $name = shift;print "\n\nCalling the SOAP Server to say hello\n\n";print "The SOAP Server says: ";print SOAP::Lite-> uri('urn:Hello')-> on_action(sub{sprintf '%s/%s', @_ })-> proxy($proxy)-> sayHello(SOAP::Data->name(name => $name)->uri('urn:Hello'))-> result . "\n\n";

Basically, there are two problems that need to be fixed.

The first deals with the soap-defined soapaction HTTP header that must be defined for all soap messages sent over HTTP. by default, both soap: lite and. net automatically generate values for the soapaction header Based on the operation that is being invoked. unfortunately, soap: lite and. net don't automatically come up with the exact same value. because. net rejects soapaction headers that it does not recognize, We need to coerce soap: Lite to create a value consistent. net's view of the world. while it is less than obvious, that is whaton_action(sub{sprintf '%s%s', @_ })Line is doing in the example 7 script.

The second problem is that. net requires all parameters to be named and namespace-qualified. as a scripting language, parameters in Perl are neither named nor typed. to solve the problem, we have to make use of soap: lite's named parameter functionality, setting both the name and XML namespace URI to values that. net can easily recognize. we see that being done with the codeSOAP::Data->name(name => $name)->uri('urn:Hello')

Now run the script again, and you'll get the result you expected.

Calling the SOAP Server to say helloThe SOAP Server says: Hello Your-Name

But did making those changes to our Perl-client-script interfere with our already established Perl-to-Java interoperability? Fortunately, not in this case because the modifications were so minor that Apache SOAP is able to perform tively ignore them. (Apache SOAP ignores the soapaction header and is capable of deserializing the parameter with or without explicit naming .) if you're not sure, just run the Perl client against the Java Web Service and you'll see the expected result.

What interoperability means

The fundamental goal of interoperability in Web Services is to blur the lines between the various development environments used to implement services so that developers using those services don't have to think about which programming language or operating system the services are hosted on. while there is a lot of progress yet to be made, this simple demonstration shows that, at least on a basic level, the tools are available to enable us to meet that goal.

To see more examples of interoperability between Web Services, pick up a copyProgramming Web Services with soapAnd walk through the varous samples. To maid in the growing effort to improve interoperability between the soap and web services implementations, check out the soap builders group.