The fundamental problem with SOAP

by Uche Ogbuji

Related link:

Rem acu tetugit Paul Prescod. IOW, He nailed the point, as he so often does. I think the idea of merging header and body into a single document is the single biggest flaw in SOAP. Yes, SOAP section 5 (the RPC datatyping section) was probably the largest overall mistake in SOAP's evoution (as even heavyweight SOAP boosters have started admitting now), but it is far less fundamenal than SOAP's monolithic design. I think the proper "fix" is to have XML in the HTTP payload as the message only, and the SOAPish headers to be moved as HTTP extension headers using XML external parsed entities in the values.


2003-03-15 22:29:12
go with that thought
Gee, I thought I was alone. When I first read the SOAP spec, I questioned its value. It was so thin, I wouldn't even call it a wrapper. I mean how did it help? Your metadata wasn't much smarter, and the content definition was left up in the air. What a waste of bandwidth. Then again, the commercial world (read: WS-I) does have its ulterior motives.

I think the open source should offer an alternative to SOAP that is more sensible. At least an approach that uses the specification as the key/door to data compatibility rather than a paper boat for expressing the whole enchilada.

2003-03-17 08:46:12
Re: Article and go with that thought
Disclaimer: I know next to nothing about SOAP and similar technologies.

With that in mind, replying to anonymous, is XML-RPC not the alternative to SOAP? From everything I've heard it is much easier to handle. On the other hand, that's all of two positive statements in favor. I've heard lots of grumbling about SOAP, though.

In reply to Uche, and correct my ignorance if I am in error, but part of the point of SOAP is that it doesn't run just over HTTP, even though SOAP over HTTP happens to be the most common implementation. Sending a single XML document could be (is it? I don't know) necessary to implementing SOAP over some other protocol. The other thing I noticed is that, if you send the SOAP header as a separate chunk that requires a response, then you effectively kill any possibility of building a non-blocking, asynchronous SOAP gizmo -- or at least make it much harder.

Not that I'm trying to defend SOAP's design, because I really don't know enough about it, but it looks to me like there are some aspects of the design that cater towards the "fringe" uses that wind up making it less optimal for what has become the common usage.

The people that use SOAP (hopefully) use it because it is a better fit for their technical needs. Other folks use CORBA, XML-RPC, or other non-standardized technologies such as Twisted's Perspective Broker -- anonymous, you may want to look into the latter.

Again, I apologize in advance for writing outside my area of knowledge, and invite corrections.

2003-03-18 11:57:20
Re: Article and go with that thought
You do know enough about these issues to have posted a thoughtful comment. Thanks.

True, SOAP supports more protocols than HTTP. However, it does not do so by magic. Ther are bindings for each protocol. And if one can write a SOAP binding for MIME, then one can just as easily write a Simple XML Payload Protocol (my ugly coinage) binding for MIME. In fact, any protocol that SOAP suppports could be supported with a simple protocol using pretty much the same mechanisms as SOAP, except with the elimination of the SOAP:Envelope, and the separation of the SOAP:Header elements into direct extensions of the host protocol.

I realy see no concrete reason why this can't b as flexible as SOAP, and from the XML processing POV, there re numerous reasons why it would be more flexible.


2003-09-02 00:18:18

While some of us were doing SOAP, Henrik and Paul Leach were trying to get HTTP-EF accepted (, which is more or less the SOAP header/extensibility model done is pure HTTP.