Copyright  2001-2007 Nicholas Quaine.
Home   Basics   ServerSide   ClientSide   Demos   FAQ   Resources
Basics
1. What is SOAP?
2. Web Services
3. SOAP messages
4. System Elements
Specifications
SOAP 1.1
WSDL 1.1
UDDI 2.0
XML 1.0

Prev   1    2    3    4    Next
SOAP Basics
4. System Elements

In this section we will look at what are the main system elements in a typical SOAP-based system, what they do and how they interact.

Let's look at the Client-Side first. As we have seen, all our dialogues with the server running the web service are done via SOAP. Remember, SOAP does not specify a transport but HTTP is common. This example presumes the use of HTTP (but you could just as easily use SMTP). As such, our messages to the server will be SOAP-XML requests wrapped in HTTP requests. Likewise the responses from the server will be HTTP responses that enclose SOAP-XML responses. Now, we as client-side developers do not want to have to worry about all the details of SOAP serialization and HTTP encoding, so we employ a SOAP package to do this for us. This is typically a library that we link into our own client code. We would then invoke services simply by invoking the appropriate method in the SOAP package (typically specifying the service URL, service name and all required parameters). The first job of the SOAP package is to serialize this service invocation into a SOAP request. It then needs to encode that message in a HTTP request and send it to the specified URL.

What the server does with this request is detailed further down on this page. But for the moment let's take it for granted that the server sends us back a HTTP-encoded message containing the SOAP response. We rely on the same SOAP package to do the reverse of what was done at the request stage, ie. we rely on it to decode the HTTP message and extract the SOAP message, then deserialize the SOAP message and obtain the return value of the method call. The return value found is then passed as the return value to the original method invocation by the client code.

Here is a graphical depiction of the process: basics-4 diagram-1
What's going on in this diagram : Client code makes a service call by invoking the appropriate method in the SOAP package (1). The SOAP package's SOAP serializer converts this invocation into a SOAP request and sends that to the HTTP encoder (2). The HTTP encoder wraps the SOAP message in a HTTP request and sends it to the SOAP server (3). The response is received from the SOAP server by the HTTP encoder/decoder module(4) which decodes it and extracts the SOAP response which it hands to the SOAP deserializer(5). The SOAP deserializer deserializes the message and passes the result to the client code (6) as the return value to the orginal invocation (1).

You'll notice then that most of the work is done by the SOAP package. There are many SOAP packages available free of charge for many platforms. Thus you can write your client code in any language and on any platform for which you can find a SOAP package. Possibilities include:

  • Visual Basic and the Microsoft SOAP Toolkit
  • Java (Stand-alone or Servlet/JSPs etc) and Apache SOAP for Java
  • Perl (Stand-alone or CGI-Perl scripts etc) and SOAP::Lite for Perl
There are many more - please refer to Client-Side SOAP for a fuller listing.

It is important to remember that your choice of language, platform and SOAP package on the client-side to consume web services is entirely independent of what language, platform and SOAP package is used on the server side to provide the web services. In this way the same SOAP-based web service (deployed for example on UNIX, written in Java, and exploiting Apache SOAP for Java) can be consumed by any type of client written for any platform, in any language, exploiting any SOAP package applicable to that language/platform combination. This is one of the great advantages of SOAP technology.

OK. Let's now look at what is happening on the Server-Side. This is slightly more complex as we need to have a listener process. We also need an implementation of the service itself. But aside from that we rely on a SOAP package in a similar way as on the client-side.

The listener process is often implemented using a servlet running as a webapp on an appserver (as is the case when we use Apache SOAP on the server side). The appserver will be set up to pass all requests for a certain URL (the URL for the SOAP service) to a particular servlet (let's call it the SOAP servlet). The job of the SOAP servlet is to extract the XML-SOAP message from the HTTP request, deserialize it (thereby separating out the method name and the supplied parameters), and invoke the service method accordingly. The result of the method is then serialized, HTTP-encoded and sent back to the requester.

Here is a graphical depiction of the process: basics-4 diagram-2
What's going on in this diagram : Appserver process receives a HTTP request from the SOAP Client at the SOAP service's URL (1) and passes it accordingly to the SOAP servlet (2). The SOAP servlet uses the package-supplied HTTP and SOAP decoding functionality to extract the details of the services call (3 and 4), ie. the method name and method parameters. Once armed with these the SOAP servlet can invoke the method (5 and 6), encode the response (7 and 8) and supply the HTTP response to the HTTP Request handler (9) which in turn replies to the SOAP Client (10). Note that the Servlet Thread box simply indicates what is running in the Servlet's VM.

Again, most of the work is done by the SOAP package. In the case of Apache SOAP for Java, this package contains not only the HTTP and SOAP encoding functionality (which, as has been seen, can also be used client side) but also the SOAP Servlet itself. And, as we'll see in the section on Server-Side SOAP it plugs quite nicely into the Tomcat Application Server. The only thing you will need to write is the service method logic.

Well, that's it for the SOAP Basics. You are now ready to make your own installation. To get started, go to the section on Server-Side SOAP.

[ Nicholas Quaine ]

Go to Server-Side SOAP

Copyright 2001-2007 Nicholas Quaine. All rights reserved.