Extending XML Web Services

If you use these specifications or new ones that may come out in the future, you must apply the structures that are laid out in them. How do you do this? To understand how you can change your SOAP messages so that they start working with these specifications, examine how you can extend SOAP.

SOAP Basics

As stated in the previous two chapters, Simple Object Access Protocol is an XML-based technology. It is used as a common message format in the transmission of messages from a Web service to any end point that is able to consume and understand these SOAP messages. This functionality is an important pillar in the Web services model.

SOAP is not the only means of communication available for a Web service in this multiplatform world. In fact, Web services on non-.NET platforms use other means, including XML-RPC and ebXML, to structure the messages sent from the Web services that sit on those platforms.

Many vendors' platforms use SOAP as the common message format in the exchange of information packets from one point to another. SOAP is a lightweight XML format that is platform-neutral. If your platform or calling application can consume XML over HTTP, you can work with the SOAP packets that are sent and received across the wire. That's the miracle of SOAP.

You can build or consume Web services on the .NET platform without understanding the structure of SOAP or even knowing that it is used as the communication protocol. Still, it is a good idea to understand exactly what SOAP is. It helps to understanding the structure of the SOAP packets that are sent across the wire if you wish to extend them in order to enhance the performance of your Web services.

SOAP 1.1, the main SOAP version used today, was developed in March of 2000 and was accepted as a note by the W3C on May 8, 2000. The companies that worked on the development of SOAP include Microsoft, DevelopMentor, IBM, Lotus, and UserLand Software. SOAP is not a proprietary technology, run or controlled by Microsoft or IBM. It is, instead, an open standard. Therefore, you can use SOAP on almost any platform as long as the platform can work with XML.

The SOAP message was meant to be simple. The SOAP message is what is sent over the wire using HTTP, with or without the HTTP Extension Framework (HTTP-EF). SOAP messages are meant to be one-way. Nothing is built into these messages that warrants any response. SOAP does not contain any built-in functions or methods that cause specific events to be initiated. The SOAP message is XML, and XML is simply a way of marking up data.

Web services require a request and response action to take place. SOAP gets around this problem by sending the SOAP message within the HTTP request and response messages.

The typical SOAP message consists of a SOAP Envelope, Header, and Body section. The SOAP Envelope is a mandatory element that is the root element of the entire package. Within the SOAP Envelope element is an optional Header element and a mandatory Body element. Figure 21-2 shows the structure of a SOAP message.

Figure 21-2

Because this entire message is an XML document, it has a single root element (the SOAP Envelope element), just like any typical XML document.

SOAP Headers

The SOAP header element is an optional element used to provide information related to what is contained within the SOAP Body element. The convenient thing about the SOAP header is that you are not required to inform the end user beforehand about the information you place there. Basically, the SOAP header is used to transmit supporting information about the payload that is contained within the SOAP Body.

The SOAP specification doesn't make any rules about what the SOAP header must contain, and this lack of restriction makes the SOAP header a powerful tool. Basically the SOAP header is a container that is sent along with the SOAP body and therefore, you can place any type of information within it.

The SOAP header is where you usually place the WS-* specifications within the SOAP document. How exactly do the various vendors interject these specifications within the SOAP message? The next section takes a look at how Microsoft builds upon a SOAP message to include these advanced specifications.

SOAP Extensions

If you are using a Microsoft-based Web service, SOAP Extensions can intercept and work with a SOAP message before it is sent past certain points.

In .NET, there are specific points in the short life of a SOAP message that is being sent and received when you are able to jump in and interact with it. The following diagram (Figure 21-3) shows you where, in the process of sending a SOAP message, you can work with it.

Figure 21-3

Serialization is the process whereby an object is converted into a format that enables it to be readily transported. In this case, the format is XML. When you serialize an object within ASP.NET in the context of XML Web services, it is formatted into XML and then sent via a SOAP packet. In the SOAP packet, the XML payload can be deserialized. The process of deserialization, as you would expect, is the conversion of an XML payload back into the object that was originally sent.

ASP.NET provides these means of interacting with the SOAP message process before or after serialization and deserialization so that you can inspect or modify the SOAP message. The capability to inspect the SOAP message throughout its journey gives you quite a bit of power. On either the client or server, you can manipulate SOAP messages to perform specific actions based upon items found in the SOAP payload. These points of interaction include BeforeSerialize, AfterSerialize, BeforeDeserialize, and AfterDeserialize.