| 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 1 of 1.
| Showing messages 1 through 1 of 1. |
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.