SOAP is NOT Dead!

This is not another REST vs. SOAP discussion. There are endless debates on this topic, that you hardly need yet another view.

This section just tells one thing: While REST has become the preferred choice to build web services, SOAP is not dead just yet.

To understand why SOAP is not dead yet, you need to recall that today, the use of web services can be broadly divided into three set of scenarios:

• Web services that manipulate data entities (or what are commonly called web resources in the web space); these services are known as Web APIs
• Web APIs that are built using the REST architectural style (where hypermedia takes central stage)
• And ‘traditional’ SOAP-based Web services that are used commonly in application or enterprise integrations

Practically there is no competition in the web domain: Web APIs and REST have become the dominant choices for building services that manipulate web resources.

However, in the domain of application and integrations such as middlewares, ESBs, and SOA; SOAP is very much still alive.

So Why is SOAP Still Alive?

Now the reason SOAP is still alive is not necessarily because it’s better than WebAPI/REST in this domain. This is debatable as WebAPI/REST advocates believe WebAPI/REST can be used for enterprise integrations even better than SOAP ever did. While SOAP advocates believe that SOAP and the WS-* standards capabilities still make them the better option for certain scenarios.

But the way i’ll approach this debate is from a single perspective: SOAP is still alive for the very simple reason that it is part of an existing infrastructure that enterprise spent loads of money on for more than a decade.

Such existing infrastructure will not simply vanish anytime soon. Even the most WebAPI/REST advocate enterprises will take time to do the transition. For these enterprises, the existing infrastructure has been heavily invested on, and has been running for a long time. To invest time, cost, and effort to redesign this infrastructure using WebAPI/REST is not a simple decision. After all, as the saying goes ‘if it ain’t broke don’t fix it’.

It’s likely that this transition will eventually happen, but my point is, it’s not happening today or tomorrow. For the meantime SOAP is still used and integration architects still need to deal with it.

Introduction to the WCF Service Model and Channel Layer

WCF Runtime Architecture

Many of the standards that will be discussed in the upcoming articles, are implemented in the WCF channel layer. In this section, I will provide a brief overview of WCF architectural model.

WCF is made up of two architectural layers: the Service Model layer and the Channel layer. The Service Model is the higher-level abstraction that you deal with most of the time. Most developers know it by the name of “proxy” at the client side; and less commonly by the name of “dispatcher” at the service side.

In its most simple form, when acting as the proxy, the Service Model converts “objects” ( or data contracts) into the proper WCF message format that the Channel layer understands – a process known commonly as “serialization”.

While when acting as the dispatcher the Service Model converts the WCF message back into the object format – a process commonly known as “deserialization”.

The Channel Layer

Anytime you deal with WCF bindings, all what you are actually doing is controlling the creation of the WCF channel stack! You are just doing it in the higher-level abstraction courtesy of the predefined WCF bindings.

Bindings produce a set of ordered BindingElement objects at runtime, depending on the type of binding you chose. These binding elements form the entire channel stack.

A BindingElement is a processing step. So a WCF binding stacks a set of BindingElements on top of each other where a WCF message passes through this stack, gets processed, and handed over to the next element.

The Channel Stack

There are three main types of binding elements: Protocol Binding Elements, Encoding Binding Elements and Transport Binding Elements.

• Protocol Binding Elements map to the WS standards that you’re going to see. Each of these elements process the message according to one of the WS standards.
  • For example, in the top is an optional TransactionFlowBindingElement class that allows flowing transactions. This is the element that implements the WS-AtomicTransaction.
  • Next is an optional ReliableSessionBindingElement class that provides a session and ordering mechanisms as defined in the WS-ReliableMessaging specification.
  • And next is an optional SecurityBindingElement class that provides security features such as authorization, authentication, protection, and confidentiality. This element implements WS-Security
• Encoding Binding Elements represent transformation between a message and an encoding ready for transmission on the wire. An encoding binding element is mandatory.
  • For example, you can use your own message encoder or one of the three message encoding bindings. Later, I will be mostly using the TextMessageEncodingBindingElement as I will be transferring SOAP over HTTP. However, I will be using the MtomMessageEncodingBindingElement which implements the MTOM standard.
• Transport Binding Elements represent the transmission of an encoding message on a transport protocol. A transport binding element is mandatory
  • I will be mostly using the wshttpbinding which uses the HttpTransportBindingElement