The ill fated SOAPAction header has been killed. Laid to rest with very little fanfare and unfortunately with very little appreciation for what it might have represented. Of course it was doomed for many reasons from the start. It was poorly defined in the specification. It was optional. And it was outside of the SOAP message which was it's biggest sin in the eyes of the SOAP community. SOAP isn't about HTTP is the claim. SOAP should be kept completely independent of any transport properties, regardless of the implications. After all, your SOAP request may be forwarded across a myriad of transport mechanisms before it is finally processed and headers will get lost.
It's time for a dose of pragmatic reality. Yes, SOAP may be carried over transports other than HTTP. But I will assert that very few instances of messages will be carried over multiple transports during the life cycle of the message. Constraining potential optimizations to protect against this edge case is unnecessary. Designers should have the flexibility to decide between optimal transport usage or message portability. Arbitrarily taking away design choices in the name of architectural idealism is always a poor choice.
Why would you want to support SOAPAction or potentially other HTTP headers in a SOAP request? Well, routing is the first use that comes to mind. SOAP proponents will tell you everything you need to route a SOAP message lies in the envelope. Absolutely, but parsing XML payloads should not be done in routing tiers. Claims of high performance XML parsing still remains largely that, claims. Even if performance were acceptable, you'd have to parse the envelope twice, once to route it, and once to process it which is still more resources than you'd want to consume, if you can avoid it.
The biggest challenge I see with the current SOAP avoidance of HTTP headers is the way it has been reflected in toolkits for building SOAP clients. Most of the SOAP toolkits provide no mechanism at all for setting HTTP headers on the request. This hinders the possibility of designing SOAP/HTTP infrastructures that take advantage of the HTTP protocol to route or perform other functions efficiently in front of the service implementations.
SOAP's goal of being agnostic to transports is fine. But being agnostic does not mean it has to be impossible to leverage the underlying transport's efficiencies. It's time to recognize that message instance portability across transports while an intriguing goal, does not need to constrain the designer. If I need that capability, then I will insure my design does not leverage any transport features. If I don't however, I would prefer that I be allowed to leverage the transport. The current situation is a poor and unnecessary compromise in the specification and most implementations.
Technorati Tags: architecture, engineering, http, performance, programming, protocol, scalability, services, soa, software, to_read, toread, web
Comments