Last week, we started taking an “under the covers” look at how Simple Object Access Protocol (SOAP) works. In this article, we’ll look in more detail at how SOAP is implemented, examine the XML standards used to deliver SOAP, and walk through a simple example of an end-to-end SOAP conversation.
Catch up on Tim Landgrave’s SOAP opera
This is the third in a four-part series on SOAP. If you missed an earlier installment, here’s your chance to get up to date.
- “What makes SOAP ideal for developing distributed applications?”: In the first part of this series, Landgrave compares SOAP-based systems to systems developed using current architecture.
- “Under the covers with SOAP”: This second installment looks at the history of the SOAP protocol and gives an overview of its salient features.
XML is the core of SOAP
It’s important to understand that the designers of SOAP implemented the protocol using a collection of Extensible Markup Language (XML) standards. In fact, SOAP layers its own model on top of core XML protocols. These XML standards include:
- XML Schemas, used to define the classes that are consumed by calling processes (recently adopted by the World Wide Web Consortium as the XML Schema Definition, or XSD. It replaces and supersets former schema standards like XML Data Reduced, or XDR.)
- XML Namespaces, to define the elements and attributes of the SOAP layers.
- XML Documents and Entities, used to create the core messages passed between SOAP-compliant systems.
SOAP protocol layers
The SOAP protocol layers fall into three categories:
- SOAP Envelope
- SOAP Encoding
- SOAP Remote Procedure Call (RPC) or SOAP Messaging layer
The SOAP Envelope is a predefined, standard container for XML messages. The agreed-upon definition for the contents of the Envelope is defined using XML schemas and can be found at http://schemas.xmlsoap.org/soap/envelope. The envelope contains three key elements. The first is the SOAP:Header, which has directions for how to handle the instructions contained in the SOAP:Body. The SOAP:Body itself contains the XML Payload with the information the payload author wants to deliver. The payload designer can include instructions for how to handle communication errors in the SOAP:Fault section of the SOAP Envelope.
The SOAP Encoding layer provides a uniform type and encoding system for data contained in the SOAP Envelope. The Encoding layer provides a uniform way for systems with different processor types and byte orders to interpret the values passed between systems using the SOAP Envelope. The Encoding layer also defines a rich type system that includes simple types (like integer, long, byte, and other values), compound values (including structures or combined types), as well as arrays (including not only fixed arrays but also sparsely populated or partial arrays). By defining common methods for encoding data passed between dissimilar systems, individual implementations of SOAP can optimize the size of the packages without concern for whether the receiving system will be able to consume the resulting package.
Once the package (either an RPC request or the resulting response) has been defined (by the Envelope) and marshaled (by the Encoding layer), it has to be moved between systems using an agreed-upon set of rules. The RPC Protocol layer defined by SOAP has four key characteristics:
- The interface and service to be called are defined by a Universal Resource Indicator (URI).
- The method to be invoked is defined as a structure, with the calling parameters defined as structure elements.
- The response should return parameters in the same order as the request received.
- The process that initiated a SOAP request defines the behavior in the event that the SOAP RPC request fails.
Finding and calling RPC services based on SOAP
Being able to define the request for services using SOAP and the response package to be returned is only half the battle. Programs that wish to consume Web services based on SOAP must also locate them, identify their interfaces, and call them.
IBM, Microsoft, and Arriba have worked together to define a standard named Universal Description, Discovery, and Integration (UDDI). UDDI is like a “yellow pages” for Web services that advertises sites that can consume SOAP request messages and return SOAP responses. Once the required service has been selected using these “yellow pages,” a calling program can query the service for its available interfaces (much like the iDispatch interface for COM returns available interfaces for COM objects).
This dynamic discovery of Web services (called “DISCO”) allows Web-service designers to update their services at any time by simply supporting older interfaces while adding new ones. The DISCO file obtained using UDDI contains a link to the actual description of the methods. These method descriptions (similar to the TypeLib used to define methods in a COM object) are defined using the Web Service Description Language (WSDL). WSDL describes the schema for data types, the call signatures for each of the methods, and the services that map to those methods.
A simple example
Let’s suppose you have a series of COM objects you’ve developed that you want anyone to be able to access across the Internet using SOAP. First, you place the COM objects on a server behind your firewall, but accessible from a Web server in your environment (through port 80). Next, you create a WSDL file that describes the methods and a DISCO file that defines the interfaces for the COM objects. Then, you need to create wrappers (using a combination of ASP files, XML parsers, and COM objects) for the COM objects that will accept a SOAP request and return a properly formatted SOAP response. Finally, register the DISCO file with a UDDI server so potential clients can find the services.
Once this process is completed, any client (without regard for operating system or language) that can query UDDI, return a DISCO file and the interfaces containing the WSDL file, and then compose a standard SOAP request package, can consume the Web service that wraps the desired COM objects.
Sounds simple, right? Unfortunately, cobbling this system together with existing tools is similar to writing complex Web pages using only a text editor. Even though all of the underlying configuration files are simple XML documents, the work to get all of these files “hooked together” to allow even the most basic request can be daunting. In the final installment of this series on SOAP, we’ll look at the upcoming toolsets from major SOAP proponents like Sun, Microsoft, and IBM that will make development of distributed systems using SOAP as simple as developing “Hello World” applications using visual programming designers.
In a lather? Don’t just sit there…