subbu.org

Will the goal to keep web services protocol agnostic cause web services to
implode? May be so, given that protocol abstraction is making web services
design and deployment more complex than necessary.

A number of people have already blogged about this issue, see, e.g. David Orchard’s

Underlying Protocol is a completely leaky abstraction, or Stefan Tilkov’s
Mapping WS-Addressing to HTTP. Both the posts are quite old, but the facts remain - that most SOAP based web services are designed for protocol independence, with no practical justifiable reasons.  Web services APIs (e.g. those in the JEE umbrella like JAX-WS) are still designed with this abstraction in mind. As a result, implementations of these APIs as well as applications using these APIs rarely take advantage of the protocol. Consider this recent SOAy article titled SOA framework with Apache Geronimo and POJOs which states that designing for location and protocol independence is somehow a good thing. This idea seems quite popular still.

At the message design level, the downside of protocol abstraction is message complexity. A lot of details end up being specified in the message payload (e.g. as SOAP headers) when the same data could more efficiently be carried at the protocol level (e.g. as URIs or headers in HTTP). Examples include WS-Addressing, and some aspects of WS-Security token profiles. Protocol abstraction does not come cheap. It forces some extra processing cycles to create/process messages.

An example closer to my experience is transporting resources over a web service (in WSRP 2.0). Resources are usually arbitrary documents or media that are consumed by user agents. By this very nature, it makes a lot of sense to be able to transport HTTP headers for caching, ranges etc. These headers make it efficient to serve resources to user agents. But since WSRP is a web services protocol, the temptation is to abstract these headers into the message itself. Then the question arises - what would you call them - httpHeaders, or transportHeaders or something more abstract (and vague)? It seems silly to have to abstract out these headers into something vague (to keep it independent of HTTP) - just so that this data
can be carried over diverse protocols like HTTP and SMTP, or even a protocol involving pigeons? Ultimately such attempts at keeping web services protocol agnostic will underutilize the power and flexibility available at the protocol level. This is sad.

Another side effect of this protocol abstraction is the existence of a number of SOAy products for routing, monitoring, SLAs etc. These products may be offering some value, but, IMO, are solving problems at the wrong level, i.e. message level instead of the transport level (e.g. HTTP). Take routing for example. HTTP proxies have been doing routing requests/responses for a number of years, quite efficiently so. I can’t say the same thing about SOAP proxies that look at the XML, run some rules, and then route each message to an end point - basically adding a number of processing cycles to already complex web services.

Good for PowerPoint, not for deployment.