Many people believe that "Web services" – application functionalities made available to other applications over the Web – are this year's hottest innovation, and possibly XML's killer app. In a recent newsletter on Web services, I said:

"A Web service infrastructure requires standard ways to format the messages to the services, to send and receive service requests and results, to represent detailed technical descriptions of how to use each service, and to search for services available on the Web."

I'll devote the next few newsletters to explaining what Web service technologies address each of these requirements. XML itself fulfills the first requirement – a way to format messages to services. Requests to an XML service can be passed from a system requesting a service to a system providing a service formatted as XML. Consider the XML-formatted data the "payload" of an XML message. For example, a pillow manufacturer might send the following purchase order to its business partner, discountfeathers.com:

<.Order>
<.Customer> <.CustomerID>443<./CustomerID> <.Name>Discountpillows.com<./Name> <./Customer> <.Item> <.ProductID>12<./ProductID> <.Description>Fluffy white feathers<./Description> <.Quantity>1000 kg<./Quantity> <./Item> <./Order>

The Web service at discountfeathers.com would receive the XML and use the data to find the customer and place an order.

The purchase order contains the data needed to place an order, but no consistent way to route this message to an appropriate service handler. We need a standard method of packaging these messages in a software "envelope" that can be annotated to indicate what service to invoke on the contents, to express what the payload contains (so every payload doesn't need to be completely parsed), or to provide context information like session ids.

The Simple Object Access Protocol (SOAP) addresses this need for a lightweight software "envelope". SOAP is a standard for XML messaging formats that performs platform-independent, extensible, standards-based service requests across a network. SOAP doesn't specify a transport mechanism, so SOAP messages can be delivered over widely available HTTP. Therefore, it's ideal for communicating requests through firewalls. Our XML purchase order, wrapped in a SOAP envelope, might look something like this (the example is simplified to be read more easily):

<.SOAP-ENV:Envelope>
<.SOAP-ENV:Header> <.Transaction>123<./Transaction> <./SOAP-ENV:Header> <.SOAP-ENV:Body> <.Order> <.!-- and so on... --> <./Order> <./SOAP-ENV:Body> <./SOAP-ENV:Envelope>

The SOAP envelope contains an optional Header that can indicate information about the message or its contents. In this case, it indicates a transaction id. The header can indicate which service (called an "Actor" by SOAP) should process the message in particular.

The Body of the message contains the information passed to the Web service. The server object responsible for processing orders would receive the body of the message, create the order, and return an appropriate status code or result, usually formatted as a SOAP message.

SOAP, of course, involves much more than I can explain here, but this small example provides the basic ideas. See the resource list below for more on SOAP.

Next Week: How are Web services described on a network?