Studies --> WebService and Axis.

Q: What is a web service?

A: It's common to have 2 programs on one computer talk to each other. One's the server (waiting and listening for requests), and the other's the client (contacting the server when it needs something done that the server does). The client and the server may talk to each other in a variety of ways: sockets, pipes, text files...

The server and the client don't have to be on the same machine. You can have, say, Apache running on some web server machine, and Firefox running on your local machine. The client and the server talk to each other -- in the case of Firefox and Apache -- using HTTP on top of TCP.

Sometimes it's useful to have a server program do something more sophisticated than just shoot html back at you when you ask for it. Sometimes it's useful for a client to be able to pass data to a server, have the server do some complex processing on it, and then possibly return something else to the client (possibly communicating back and forth multiple times if necessary). We've already got programs to do this manually: You could use ftp to push a file to an ftp server, then ssh to the remote machine and run some other commands to work on the file you just ftp'd there. Then you could ftp the file back to your local machine. You could even script all of that to make it automated. Your script might even work for a different server than the one you originally wrote it for.

The point of web services is to replace that messy contraption and provide a generic, standardized, client and server paradigm for asking server programs on remote computers to do things for you. The way most folks use web services (because it's the simplest, and the default for the Axis toolkit -- discussed below) is by simply calling methods on objects residing on remote computers (see JAX-RPC wrt Axis, below).

The idea is, somewhere there's a registry of web service descriptions; structured descriptions telling exactly what services are provided by which web services (you might think of it as a list of objects and their public instance methods). When you want to make use of one of these services, you have a look at the web service description and then write a client that can talk to that service. There are, of course, tools out there that will turn the description into a bare-bones Java source code file (the skeleton of your client) for you to fill-in the implementation details.

The grand plan at some point was for big corps like Microsoft to provide a web service registry, and then you'd pay (on a per-use basis) for every web service you wanted to use (as opposed to having individual apps installed on your computer, that you may or may not have paid MS for). Companies like MS love the idea of pay-per-use. I don't have any idea if this grand plan has panned out for them, but web services seem pretty useful regardless.

Q: How do web services work?

A: First, a diagram, then, some explanation:

  +--------------------------------------+
 |         web service registry         |
 |         (aka service broker)         |
 |                (UDDI)                |
 +--------------------------------------+
        ^                        ^
        |                        |
    (2) |                    (1) |
        |  (the client           |  (the web service
      WSDL  finds the          WSDL  provider publishes
        |   service              |   the web service)
        |   they want)           |
        |                        |
        v                        |
  +-----------+            +-----------+
  | service   |<---SOAP--->|  service  |
  | requestor |            |  provider |
  +-----------+     (3)    +-----------+

The numbers in parentheses indicate the order in which things happen. Step 1 is optional if you don't want to tell the whole world about your web service. Step 2 is optional if you (the client, the "service requestor") already know what service you want, and from whom. Step 3 is sometimes called, "binding to the web service". The "binding" we'll use here (and what's most commonly used) is SOAP.

• WSDL -- Web Services description Language. Used to describe exactly (in XML) what a web service does.

• UDDI -- The "Universal Description, Discovery and Integration" protocol. A protocol for publishing web service descriptions. Somebody deploys a UDDI registry (it's just another web service), and then folks looking for some web service check with that registry to see what web services it knows about. Anybody can put up a web service registry.

• SOAP -- A transport protocol that sends XML messages using HTTP (which runs on top of TCP, usually on port 80).

WSDL is a description language: using XML, it describes exactly what your web service does. If you want a WSDL file for your web service, and you're using Apache Axis (mentioned below), you don't need to manually write the WSDL file -- you just have Axis create it for you from your Java code. More on that later.

When you create a web service -- one that you want other people to make use of -- you can use a WSDL description of it to register your web service with some web service registry. If you don't want anyone to be able to find out about your web service, then you don't have to register it -- it's optional.

SOAP is just the usual way that web services and their clients talk to each other -- they send XML text back and forth. You can watch it right on the wire (looking at the TCP packets with something like Ethereal) if you like.

Q: What is Apache Axis? What's its relationship to Apache SOAP?

A: As a client to a web service, encoding your requests to the web service, and decoding the responses you get back, to and from XML would be a pain (not to mention implementing the logic that deals with accepting requests and sending responses). The same goes if you're writing the web service yourself. Most folks use Apache Axis to do all that for them. You could write web service clients and servers without something like Axis, but it would be very tedious.

Axis was formerly known as "Apache SOAP". Currently, Axis is transitioning to version 2, but there's still a lot of Axis 1.2 users out there, and an Axis 2 stable release is not yet shipping.

Axis is an implementation of the SOAP protocol. It shields you from the details of dealing with SOAP and WSDL. You use Axis on the server side to write your web service (and deploy it as a Tomcat webapp), and you use Axis on the client side to make writing your client a snap. Axis (Axis2? XXX) is essentially Apache SOAP 3.0. It is a from-scratch rewrite, designed around a streaming model (using SAX internally rather than DOM). The intention is to create a more modular, more flexible, and higher-performing SOAP implementation (relative to Apache SOAP 2.0).

Using Axis, you can choose from 4 different "styles" of web service: RPC, "Document", "Wrapped", and "Message". The Axis default is RPC -- and that's what we'll be using here. You'll often see the acronym JAX-RPC: Java over XML to make Remote Procedure Calls. SOAP is XML, and (by default) Axis sends SOAP messages to do RPC.

When using Axis to write your client, you don't need to directly deal with SOAP/XML/JAX-RPC. All of that is handled for you by Axis -- all you need to do is make the method calls on the web service object as if it were some local object. Same goes for your web service itself: just write the class and its instance methods, and let Axis take care of the rest.

You install your web service just like any other Tomcat webapp. Your client that accesses the web service can just be a regular Java command-line program.