Useful article over on O’Reilly: Don’t Be Afraid to Drop the SOAP recounting experiences and problems with SOAP while working on Bricolage, a Perl CMS. Probably doesn’t need saying but going to anyway: if you want reality, talk to the Perl guy.
The conclusion I’ve formed about SOAP is it really isn’t suited to the Internet and arguably not even for Extranets but rather for integrating disparate systems inside corporations with generations of legacy technology. And even then, you should consider XML-RPC first. The strongest thing I think SOAP has going for it is just that everyone agrees so it’s possible to find implementations on all sorts of platforms. There’s probably a lesson to be learned here about “design by committee”.
Was also interested to see that the author of the article, Sam Tregar, is now working on Krang. By chance had lots of opportunity to pick the brains of Perrin Harkins who’s also part of the Krang team and was talking about it at OSCOM. Aside from being a really nice guy, Perrin has seen it all when it comes to IT and the Internet so buy him a beer at the next conference (believe he’s seen at NY PHP sometimes as well). He also took the closing act in the Toy War with a smile.
Related posts:
- Dreamweaver CS4: A Powerful Tool for an Imperfect World With the just-released Dreamweaver CS4, Adobe has conceded that web...
- Web Fonts Get Real with Typekit Web designers want access to a greater range of fonts...
- OpenID Needs to Start Getting Real It seems like the OpenID Foundation might be spending too...
- The Non-Virtual World of Freelancing: Face-to-Face Networking Face-to-face networking can be a scary thing if you're used...
- The Non-Virtual World of Freelancing: In-Person Meetings Reaching out to local businesses can be a good way...
I totally agree with “the Perl guy”, SOAP does have its drawbacks: I had to develop a frontend application (VB/windows) that would publish data to and pull data from a remote database (mysql/Linux) at the beginning of this year, and the things that annoyed me the most at that time were that SOAP didn’t handle attachments (and nusoap didn’t support MIME or DIME attachments at that time, I didn’t check if it does now) and it had no default support for authentication (I implemented a part of the Atom digest authentication, and while the PHP endpoint was easy, it was a pain to do things at the other end). Apart from these things, SOAP was really useful, because I had high level libraries on both platforms, and I didn’t need to look at the WSDL and XML dialogue at all, except when I was debugging the authentication/session handling thing, of course ;).
October 6th, 2004 at 11:12 am
Eh?
PEAR SOAP supports attachments and does HTTP basic authentication just fine (which, over http/s is okay). Also, I don’t think you’re going to argue XML-RPC as something in the enterprise — not when there is so much effort from the big companies (Microsoft, IBM, etc) on supporting SOAP and standardizing the flexibility.
If you look at WSDL and SOAP, you’ll realize that it’s starting to drive you to the model where you just do an interface definition and that a lot of your code is generated automatically. Also, there is a lot more flexibility in what you can do with SOAP. In complex applications, you’re going to need to define this flexibility in a standard way that you cannot do with XML-RPC.
Let me debunk this drop the soap article’s problems:
“SOAP is hard to debug”
– Eh? Not it’s not, not any more than looking at any other XML or even HTML for that matter. Besides, just go grab some good tools like Mindreef’s SOAPscope and you’ll see how really easy it is to just drop a WSDL in and functional test/debug.
“Live requests hindered debugging.”
– That is poor development/QA/testing environment, not a problem of a standard protocol.
“SOAP doesn’t handle large amounts of data well.”
– I believe this is just a poor architecture for the application. SOAP, like any other interpreted at run-time messaging protocol will have a slow down as you increase message sizes. Ever build a website that returned thousands of rows of data on one page — it can take a while. A better way is to put a pointer (in this case, HTTP URL) in some part of the SOAP message and go download it separately. Also, memory consumption of a piece of software is the software — not the standard. There are clever ways to do things and not clever ways.
“SOAP needed two requests to authenticate”
– How about using http authentication, that seems to be one request to me. Using https there should be no problems on password sniffing. This analogoy of two requests is similar to websites… sometimes you have to live with a login page preceding the content.
“Network problems affected operations between machines.”
– Well, duh. Please enlighten me how to keep requests going between two hosts if the network is down. There’s ways to setup redundant systems with redundant routers and alternate private LANs if it is really that mission critical.
“No perl solution for validating XML objects against an XML schema.”
– Again, implementation fault, not the protocol. Also, rpc-encoded services have all their schema defined in the WSDL in a very easy and straight forward way. Since most services are still using rpc/encoded — this makes validation pretty black and white. When everyone moves to doc/literal wrapped there’ll be more schema validation concerns.
He then goes on to say that SOAP is limited in its messaging and hurts debugging. All I can say is that SOAP just defines a standard way to define your API. A SOAP envelope and a SOAP body, that’s a couple tags — we’re not talking about a dozen extra lines of XML to describe something as simple as “myMethod”. And hey, if you ever need a header or something, it’s easily done in SOAP whereas it’ll be a ‘hack’ in XML-RPC.
My observation has been that SOAP is taking enterprise development by storm, but small business web developers are reluctant to use it based on first impression dismissals. A good analogy is when a Java developer first looks at PHP — they’re thinking about web containers and servlets so the shared nothing architecture isn’t obvious at first. I believe as services expand and change over time, the advantages of SOAP will become more clear. Also, toolkit refinements and continuous server improvements should offset performance concerns.
October 17th, 2004 at 1:40 am