More widely used each day, developers are turning to the SOAP standard for XML messaging. SOAP (Simple Object Access Protocol) was originally proposed by Microsoft but has been subsequently adopted by IBM and many other companies, including, more recently, Sun Microsystems.
Read the whole "XML Messaging" series:
- Part 1: Write a simple XML message broker for custom XML messages
- Part 2: XML messaging the SOAP way
- Part 3: JAXM and ebXML set the new standard for XML messaging
SOAP is an XML messaging/RPC (Remote Procedure Call) standard to enable the exchange of a variety of information. As one benefit, it provides a framework for XML messaging without excessive complexity. The SOAP specification is fairly concise compared with many other messaging standards, with much of the text dedicated to encoding. Because of its widespread industry support, simple design, and the use of SOAP in other XML standards, SOAP appears to be the XML messaging standard to watch.
In this article, the second of three, I'll begin by describing SOAP's fundamentals and capabilities. Next, I'll introduce the standards that use SOAP in some fashion, including UDDI (Universal Description, Discovery, and Integration), Web services, and BizTalk. I'll then briefly discuss the future of SOAP, wrapping up by developing the same simple messaging application covered in Part 1.
SOAP comprises three major components: a messaging framework, an encoding standard, and an RPC mechanism. When using SOAP, you can choose to use just the messaging framework, the messaging framework with the encoding standard, or all three together. Let's look at each in more detail.
SOAP's messaging framework
SOAP's messaging framework says that SOAP messages will be composed of an outer envelope that can contain a header and a body. The following is a skeleton example of a SOAP message with no information in it. Make note of the outer most element called the SOAP envelope, as everything in a SOAP message falls inside it. The other two important tags are the SOAP header and the SOAP body. The header portion of the message carries meta data about the message, while the body contains the message's payload:
<SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/" SOAP-ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"/> <SOAP-ENV:Header> </SOAP-ENV:Header> <SOAP-ENV:Body> </SOAP-ENV:Body> </SOAP-ENV:Envelope>
In SOAP, you'll notice the heavy use of XML namespaces. For instance, the
SOAP-ENV namespace in the example above denotes elements related to the SOAP envelope, header, and body. A SOAP document, consequently, can prove slightly more difficult to read than other XML documents, necessary for the flexibility SOAP requires to be extensible.
Header elements in a SOAP document can be labeled as
mustUnderstand, meaning that the server that processes the SOAP message must understand that type of header element or it must reject the message.
Messages are rejected by generating SOAP faults. Faults happen when an error occurs when processing a message. Errors can have many causes, but the most likely culprits include an unrecognizable header field, a message that cannot be authenticated, or errors that occur when invoking a method to process the message.
Encoding/serialization standard for objects
In one feature differentiating it from other XML messaging standards, the SOAP specification's encoding/serialization portion speaks to how objects are encoded or serialized when sent over SOAP. Having an encoding standard for SOAP messages means that objects can be encoded in SOAP messages in a standard way, and then decoded by the message recipient. For instance, an integer array would be encoded in SOAP as:
<SOAP-ENC:Array SOAP-ENC:arrayType="xsd:int"> <SOAP-ENC:int>8</SOAP-ENC:int> <SOAP-ENC:int>5</SOAP-ENC:int> <SOAP-ENC:int>9</SOAP-ENC:int> </SOAP-ENC:Array>
The SOAP library found on the client and the server performs the encoding/decoding. SOAP's encoding/serialization features are mainly used in conjunction with the RPC mechanism, which you'll see next.
SOAP's RPC mechanism
SOAP's RPC portion speaks to the ability to use the SOAP protocol to invoke procedures on the receiving end of a SOAP message. The RPC mechanism builds on the encoding portion by allowing encoded objects to pass as arguments to a remote procedure.
When using the RPC mechanism, it's relatively easy to set up a call and invoke a remote procedure. You only need to know the name of the procedure you wish to call and the arguments to that method.
Once you invoke a method using SOAP, the SOAP library you use encodes or serializes the arguments using SOAP's encoding standard. The SOAP library you use will also send the RPC over the transport you specify.
This is somewhat CORBA-like, in that it lets you use different languages to encode data, such as an array, and then decode it in another language. This idea of encoding arbitrary objects automatically into an XML message makes producing XML messages much easier than explicitly creating the message by setting each element's value.
In Part 1, I stated that messaging is really not an RPC mechanism and that one benefit of messaging is the loose coupling it enables by not being bound to particular methods and arguments. SOAP's RPC mechanism seems to muddy the water a bit in that it is an RPC mechanism that does create a more tightly coupled relationship than messaging promises.
Issues with using RPCs
The SOAP RPC mechanism may create tighter coupling than desired for two reasons. First, you know the name of the method you will invoke, as well as its parameters. Consequently, if you change the invoked methods' method signature, you will also have to change the classes (or SOAP clients in this case) that call it. Note: UDDI addresses some of this by providing a way to dynamically look up the method name for a particular Web service.
Second, the interface between the client and server and the parameters passed must be known ahead of time by both parties. If one of a method's arguments should change, the change affects both client and server. For instance, if we change one of the parameters to a SOAP call named
Person, a JavaBean, so that it has an additional field, both the client and server may need to be changed as a consequence. SOAP doesn't really address the description of methods and parameters very well, but, as you read in the section ahead, you'll see that the WSDL (Web Services Description Language) compensates.
As a final note on RPC, just because SOAP includes an RPC mechanism does not mean that you must use it. If you prefer to use SOAP only in a message-oriented way, you can still do so. Indeed, nothing forces you to use SOAP's RPC mechanism.
RPC versus message-oriented
Given all of the negatives stemming from the RPC mechanism's tight coupling, you should avoid it, right? Well, it turns out the RPC mechanism proves useful in some cases. One of the reasons for this is simple: it's easier. That is, it takes less work to develop communication between two systems if you use the RPC-oriented approach.
Indeed, a message-oriented approach requires that you define a message format, then compose a message using the format before sending and extracting that data from the message after receiving. The RPC-oriented approach does all this semi-automatically because the method you are calling determines the RPC format and SOAP's encoding/serialization standards for objects determine how the parameters will be encoded into XML.
Because of the tradeoffs between these two approaches, the following guidelines normally apply:
- Consider using SOAP's RPC mechanism for communication within the enterprise, assuming that producing a more tightly coupled system is not an issue (if it is then go with the message-oriented approach).
- Consider employing SOAP's message-oriented approach for communication between two different business entities. Ideally this is done using an existing industry-standard message schema.
SOAP pros and cons
So what are the advantages to employing SOAP for XML messaging? And what are the drawbacks? One advantage: SOAP appears to be the most widely accepted XML messaging standard; almost all major companies support it.
Next, SOAP allows both message-oriented or RPC-oriented communications, a feature differentiating SOAP from other messaging standards. It even throws in a standard mechanism for XML object encoding/serialization, useful when trying to use SOAP as an RPC mechanism.
As for disadvantages, SOAP requires other supporting standards to provide full functionality. For instance, because SOAP does not include any header elements, you'll need a standard layered on top of SOAP, BizTalk for example, to perform message routing. This means both parties must understand SOAP and BizTalk (in this case).
Moreover, interoperability has not been perfected. Not all SOAP implementations work perfectly together, and it may be some time before they do. Indeed, many of the incompatibilities are encountered when using the encoding and RPC mechanism.
So SOAP isn't perfect yet even though it has existed for almost two years. It's still changing rapidly and it will be a few more years before it is widely deployed. In the meantime, we'll need to live with a few wrinkles. But not to worry. One of the nice things about SOAP is that you can rectify some of its short falls by layering other standards on top of it, as you'll see in the sections ahead.
UDDI is a standard for dynamic lookup, binding, and publishing of SOAP services. It allows you to query different UDDI registries to look up businesses, information by business category, and service information.
So what does combining UDDI with SOAP buy you over SOAP alone? One of the areas where XML messaging has been lacking is in the area of directory services. In Java, directory services through JNDI play a crucial role in publishing and looking up various types of services (such as EJBs, JMS queues, and so on). One of UDDI's goals is to provide for SOAP a service similar to what JNDI provides for Java, all in a B2B scenario.
Many companies in the last six months have announced products and services known as Web services. Web services mean different things to different people. In the context of this article, Web services are based on SOAP and use a WSDL file to define them. WSDL files are being adopted on both the client and server portion of SOAP communication to better describe the type of communication that will occur between the two parties.
For instance, a WSDL file may describe that a particular message is sent as input to a SOAP server and a particular message is sent in response to that input. A WSDL file also describes at which URL and port a particular Web service exists.
BizTalk 2.0 is Microsoft's extension or layer to SOAP that defines the message fields necessary for B2B message-oriented communication. Some of the extensions that BizTalk adds include to and from logical destinations, tracking ids, and so on. Most BizTalk additions appear in the document's header section. The code below illustrates a BizTalk message that we'll use in the example programs that follow. This example is the same invoice document from Part 1 but put into the format for a SOAP/BizTalk document: