SOAP, .NET, and COM - An Introduction: Part I

SOAP is a protocol specification to invoke methods on servers, services, components and objects. The available procedure of using XML and HTTP as a method invocation mechanism is implied by SOAP. A small number of HTTP headers that facilitate firewall/proxy filtering are authorized by the SOAP specification. The SOAP specification also mandates an XML vocabulary that is used to represent method parameters, return values, and exceptions.

To exchange structured and typed information between peers in a decentralized, distributed environment using XML, SOAP presents an uncomplicated mechanism. SOAP defines a simple mechanism for expressing application semantics by providing a modular packaging model and encoding mechanisms for encoding data within modules instead of defining any application semantics such as a programming model or implementation specific semantics. This allows SOAP to be used in a large variety of systems ranging from messaging systems to RPC.

An Overview to SOAP

SOAP, (the Simple Object Access Protocol), is XML syntax to exchange messages. Moreover, since it is XML, it is independent from both language and platform. In addition, SOAP is a fundamental part of .NET, Microsoft's new development platform, and to understand what SOAP is and how it works it will be important for developers to move towards .NET.

In SOAP, there are four parts:

• The SOAP envelope construct: Defines an overall framework to express what is in a message, who should deal with it, and whether it is optional or mandatory.
• The SOAP encoding rules: Defines a serialization mechanism that can be used to exchange instances of application-defined datatypes.
• The SOAP RPC representation: Defines a convention that can be used to represent remote procedure calls and responses.
• The SOAP binding: Defines a convention to exchange SOAP envelopes between peers using an underlying protocol for transport.

Simply, SOAP is a well-documented wire protocol. Microsoft is getting behind SOAP and in future, probably will offer some type of implementation. However, other vendors can also do the same. For instance, the Perl implementation of SOAP is not tied to COM or Windows in any way, and if a modern version of Perl is available, can be used on any platform where. SOAP does not attach anyone to a particular platform. It provides a practical way to communicate over the Internet that is easy to implement on any platform.

Functionally, SOAP is very similar to IIOP which the underlying protocol used by most CORBA products. DCOM has additional protocol functionality such as garbage collection, causality that is not present in IIOP or SOAP. However, DCOM's extended functionality generally only needed in server-server communications and is not required in client-server communications. An advantage of both IIOP and DCOM side, SOAP packets be likely to be larger on the wire and can be somewhat more resource intensive to parse/generate.

A set of conventions for exchanging XML messages defined by the specification, such as rules for encoding data structures, an extensibility mechanism, a binding to the HTTP protocol, and conventions for RPC style invocations. For all SOAP messages that are exchanged between a web service and its client, SOAP defines the outer element. Namespace indicates to an XSLT processor that the XML is in fact a transform, just as the stylesheet element in the XSLT.

Moreover, the Envelope element in the SOAP namespace indicates to a SOAP processor that the XML is in fact a SOAP message. After that the processor can seek the individual pieces of the message, such as a mandatory Body element that has the actual request and an elective Header element that has extension elements. Below, a framework SOAP message is demonstrated.

<soap:Envelope xmlns:soap='http://www.w3.org/2001/10/soap-envelope'>
<soap:Header>
<-- Headers go here -->
</soap:Header>
<soap:Body>
<-- Request goes here -->
</soap:Body>
</soap:Envelope>

An extensibility mechanism is provided in the Header element in SOAP. This element can have any number of namespace qualified child elements. To the base SOAP protocol, each of these elements is some form of extension. Possibly one element holds data associated with conversation or session management between a client and a server. Another element might contain authentication information or even information pertaining to an ongoing transaction and another may contain locale information. Whatever their content or semantics each header element modifies the SOAP protocol in some way, also they providing extra context for the processing of the body of the message. It will be important to the client that the server honors them for some extensions; authentication is a good example to this.

SOAP Basics

At first, SOAP was based on HTTP, in Version 1.0 of the specification. Later on this changed, to allow for a wider variety of transport protocols (such as SMTP), or messaging protocols in the latest revision of the specification, Version 1.1 and Version 1.2. Two major design goals are outlined in the original SOAP specification: 1) Provide a standard object invocation protocol built on Internet standards, using HTTP as the transport and XML for data encoding, and 2) Create an extensible protocol and payload format that can evolve. Simplicity and extensibility are very important goals for SOAP. SOAP completely avoids several additional aspects of distributed object architectures.

• Distributed garbage collection-orphaned objects
• Pipelined messages or multiple call requests.
• Remote object activation
• Bi-Directional HTTP communications-callbacks
• Objects-by-reference
• Security

The individual SOAP implementation's architect designs the areas which the specification has not addressed, into a specific implementation. To solve some challenging real world issues that encumber existing distributed protocols and architectures is SOAP's objective. While existing protocols do address the items mentioned, and SOAP does not, SOAP addresses areas in which existing protocols fall short, such as scalability and the capability to share disparate yet interoperable using SOAP architectures.

SOAP Fundamentals

Actually, SOAP is based upon its technical worth; it is mainly the mixture of textual information shared via the Internet. SOAP processing is very much aligned with the Internet if you use HTTP as your SOAP transport protocol. SOAP specifies a stateless programming model with this processing. That means, object clients request services from a remote entity, which responds with the pertinent information. Currently, HTTP is a persistent technology and if a business interacts with the Internet in any meaningful fashion, it has to handle HTTP data. At the very least, HTTP processing is well understood and widely put into action. Some aspects of using SOAP, as with any tool, can be seen as advantages. In following list you may find some of the advantages of using SOAP.

• SOAP is built upon technologies, rather than vendor-specific technologies, and facilitates true distributed interoperability. At least not at this time, the SOAP market is not conquered by single vendor.
• The SOAP specification can ultimately consolidate the various HTTP tunneling protocols (IIOP and RMI to name two) into a single specification. This makes implementations easier and potentially more interoperable. SOAP typically uses HTTP but at least with the 1.2 version of the specification, it does not require its use.
• SOAP will likely work out of the box in a wide range of user locations that enable HTTP port 80 POST access.
• Loosely Coupled distributed applications are encouraged by SOAP.
• Unless significant serialization changes are made to the SOAP specification, changes to the SOAP infrastructures will likely not affect applications using the protocol.

When you choose remoting architecture, possibly there are many design facets that you need to consider about them. The following list includes some of them.

1. Scalability
2. Performance
3. Activation
4. State Management
5. Garbage Collection
6. Security

The wire protocols are not necessarily responsible for any or every design facet of the entire remoting architecture. For instance, not all of them implement security. However, for some or all these design facets, each protocol provides some level of support. Some protocols transmit security information as an integral part of their data packets, whereas others rely upon external systems to assure a secure connection. Beginning with scalability, each of these design issues is discussed to try to apply the same definition to all the wire protocols. SOAP simply is a wire protocol, unlike the other distributed object architectures. To compare SOAP with these other architectures; you need to apply the SOAP protocol as part of a distributed architecture of its own. On the other hand, even as a wire protocol, SOAP offers many advantages.



Figure 3.1 - SOAP Architecture

SOAP Messages

Since now we have covered SOAP at a high level, let us examine the most important detail of SOAP: the structure of a message. For messages, SOAP primarily uses XML syntax. A SOAP message contains a payload, the application-specific information. Here is an example of a SOAP message as an actual XML document:

<soap:Envelope xmlns:soap=http://schemas.xmlsoap.org/soap/envelope/
soap:encodingStyle="http://schemas.xmlsoap.org/soap/
encoding/">
<soap:Header>
<h:from xmlns:h="http://www.ets-
oftware.com/Header">[email protected]</h:from>
</soap:Header>
<soap:Body>
<w:GetMainIdentity xmlns:w="http://www.ets-software.com/Authors/">
<w:nickname>XSLT-Author</w:nickname>
</w:GetMainIdentity>
</soap:Body>
</soap:Envelope>

Figure 3.2 - SOAP Messages Architecture

Let us take a quick look at the XML of the message before we go into the contents of the SOAP message. As you may know, SOAP messages heavily rely on XML Namespaces. All of the elements in this document are prefixed with a namespace, and there is a good reason why the SOAP specification uses namespaces so extensively. All the elements of the message must be scoped in some fashion to avoid conflicts in the names of elements in order for a SOAP message to carry any arbitrary XML payload.

The namespace prefix soap is used on most of the elements in the above message. In the fallowing example, the prefix is associated with the namespace URI http://schemas.xmlsoap.org/soap/envelope/. It identifies the elements that are part of a standard SOAP message. The choice of soap is not relevant like all namespace prefixes. As in the fallowing, the namespace prefix could have been something else entirely:

<trial:Envelope xmlns:trial =http://schemas.xmlsoap.org/soap/envelope/
trial:encodingStyle="http://schemas.xmlsoap.org/
soap/encoding/">
<trial:Header>
<h:from xmlns:h="http://www.ets-
software.com/Header">[email protected]</h:from>
</trial:Header>
<trial:Body>
<w:GetMainIdentity xmlns:w="http://www.ets-software.com/Authors/">
<w:nickname>XSLT-Author</w:nickname>
</w:GetMainIdentity>
</trial:Body>
</trial:Envelope>

If the namespace is the default namespace for the document, the namespace prefix could also be eliminated. As shown below, the default namespace is assigned using just the xmlns attribute:

<Envelope xmlns=http://schemas.xmlsoap.org/soap/envelope/
encodingStyle="http://schemas.xmlsoap.org/soap/encoding/">
<Header>
<h:from xmlns:h="http://www.ets-
software.com/Header">[email protected]</h:from>
</Header>
<Body>
<w:GetMainIdentity xmlns:w="http://www.ets-software.com/Authors/">
<w:nickname>XSLT-Author</w:nickname>
</w:GetMainIdentity>
</Body>
</Envelope>

All three of these messages are acceptable and equivalent. It is better to use the soap namespace prefix for elements for better readability. All of the elements in the message that are associated with the soap namespace are standard elements of a SOAP message, as are the attributes. Any other elements are related to either message extensions or the message payload.

A traditional versioning model is not defined in SOAP based on major and minor version numbers. A SOAP message MUST have an Envelope element associated with the "http://schemas.xmlsoap.org/soap/envelope/" namespace. The application MUST treat a message as a version error and discard it if this is received by a SOAP application in which the SOAP Envelope element is associated with a different namespace. However, if the message is received through a request/response protocol such as HTTP, the application MUST respond with a SOAP VersionMismatch faultcode message using the SOAP "http://schemas.xmlsoap.org/soap/envelope/" namespace.

<soap:Envelope xmlns:soap=http://schemas.xmlsoap.org/soap/envelope/
soap:encodingStyle="http://schemas.xmlsoap.org/soap/
encoding/">
<soap:Header>
<h:from xmlns:h="http://www.ets-
software.com/Header">[email protected]</h:from>
</soap:Header>
<soap:Body>
<w:GetMainIdentity xmlns:w="http://www.ets-software.com/Authors/">
<w:nickname>XSLT-Author</w:nickname>
</w:GetMainIdentity>
</soap:Body>
</soap:Envelope>