A Quick Intro to Web Services in SOAP
In the first part of this introductory series on Web Services we discussed
how to build web services using XML-RPC. As stated there XML-RPC is just
an "early version" of RPC using SOAP. Consequently, building up
on the principles that were introduced in the XML-RPC tutorial, we should
be able transfer our XML-RPC service to SOAP in a fairly straightforward manner.
For most implementations we will discuss the
server first (i.e. establish the service that the client wants to access)
and then follow up with the client. Implementing
the service is in most cases easier and it also forces you to define things
like the location and name space of the service, something that is necessary
for implementing a client. It is also the approach you have to take if you
are faced with the problem to build a web service. One thing to keep in mind
(maybe the most important thing when trying to find the service) when setting
up a service is that the name space of the service does not have to relate
to a physical file structure. For the perl and python examples we will use
http://localhost:9000 , the name space, the part of the full address
following the location, will be Date and the remote method itself
will be called dateInfo. If we were to use a web browser the full
address of the service (or method - I admit it's not really clear all the
time what I mean with service) would be http://localhost:9000/Date/dateInfo. However
there the server itself will be running at some arbitrary location, in my
case something like ...\SOAP\SOAPQuick\, and will have no resemblance
with the name space. The may seem confusing in particular if you have your
own web site where the URLs of the web pages typically match the folder structure.
However, if you are running your own web server and have looked a bit into
this, you realize that this structure is only there because it is defined
as such in the configuration of the web server.
As with XML-RPC our journey into the world of SOAP will start with perl
and python. From there we will move on to Java. One of the main emphasis of
this tutorial is the illustration of interoperability of the different SOAP
implementations. Any server or servlet we deploy should be able to communicate
with all SOAP implementations. After all, this is one of the main features
of SOAP based web services and if we didn't want that we could save us a lot
of time and just use e.g. some legacy RMI system.
The other advantage of discussing different SOAP tool kits next to each other
is that the comparison of the tool kits illustrates very nicely the common
concepts of SOAP based web services. We will be able to see which features
are particular for a given tool kit or language and which features are necessary
to setup a SOAP based client or server.
And finally - all the code in this tutorial and some utilities can be found