| Weblog: | The fundamental problem with SOAP | |
| Subject: | go with that thought | |
| Date: | 2003-03-15 22:29:12 | |
| From: | anonymous2 | |
|
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.
|
||
Showing messages 1 through 2 of 2.
-
Re: Article and go with that thought
2003-03-17 08:46:12 tpherndon [Reply | View]
-
Re: Article and go with that thought
2003-03-18 11:57:20 Uche Ogbuji [Reply | View]
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.
--Uche
| Showing messages 1 through 2 of 2. |
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.