I’m a little late to this party, but SOAP rocks. I’ve dabbled in PHP and database-driven websites before, and running a blog kind of assumes you know more than a rudimentary XML-RPC.
But SOAP means that my PHP code can interface with a database on another machine via an ASP script with no worries about bits flipping or handling connections or sockets or anything technical. Implementing one of these “come-one-come-all” web application servers has the feel of a security nightmare but using them from the outside is really cool. Maybe there’s something to this Web 2.0 thing after all.
I’ve heard of this, I’m new to programming (recently hired on campus as one nonetheless based on my newbie activities). But I don’t get it. Is this like my Bank of America portfolio? They have a feature that once I provide merely login and password information for all my non-Bank of America accounts, this portfolio is able to “collect” such information as my current balance for each and subsequently present it all through one web page. Is that SOAP?
Good to hear you’re getting this tho –.
XML-RPC is hardly “rudimentary”. SOAP is basically an example of second-system effect on XML-RPC. (Oh, and most blogs use XML-RPC, not SOAP.)
XML-RPC is small and elegant, SOAP is bulky and elephantine. SOAP is XML-RPC designed by committee. (Literally.)
Security isn’t something that should be handled by the underlying protocol, as far as I’m concerned. XML-RPC and SOAP shouldn’t be required to handle security; the applications themselves should.
David:
That interface may or may not be implemented through SOAP. SOAP is an underlying communication mechanism.
I enjoy working with XML-RPC, things like gnome-blog use it quite well. It’s easy to call remote methods. I know a smattering of XML-RPC because I’ve toyed with blog software before. I’m using SOAP to talk to MyNGP, which is campaign software, and it seems (at least on the surface) more flexible and featured than XML-RPC.
As far as security goes, you’re basically routing what could traditionally be controlled partially on the network level all through a stateless protocol on one port. It just seems like one less barrier in the way of a potential intruder.
Speaking of XML, I’m totally impressed that the software industry took 25 years to reinvent Lisp s-expressions (except with additional, mostly unneeded complexity).
Casimir: “Featured” isn’t necessarily a positive… I tend to subscribe to the Unix philisophy of “Do one thing and do it well”. XML-RPC does. SOAP throws in too many unrelated objectives.
CS Weenie: Well, SGML has been around for a long time; HTML is officially described as a subset of SGML. XML is a replacement for SGML, removing some of the useless cruft (and admittedly adding some new, improved useless cruft). S-expressions are similar, but not really the same. (As fond as I am of Lisp, it’s not really designed to ensure proper transfer of structured data. XML is, as was SGML.)
I would argue that sexp’s are sufficient to provide 90% of what XML claims to do. You have an equivalent hierarchical structure, attributes/properties, values, etc. only with a simpler syntax. The essential concepts are identical, actually.
Transfer of structured data has a lot more to do with shared conventions for interpretation than anything else; sexp’s, and XML nuggets, are just methods of meaningfully encapsulating data. The fact that Lisp systems happen to read sexp’s as code is a nice bonus too.
Okay. After working with SOAP for more than a few days, the honeymoon period is over and you guys are right in a way. SOAP is more flexible, but that means working with someone’s API can be a headache. Complex data types are neat, but can be a bit of a pain. On the other hand, sometimes a user wants namespaces or complex named data-types or wants to pass an object as a parameter to a function and XML-RPC makes you write far more code because it’s simple.
As to the structured data+metadata discussion, well, “The great thing about standards is there are so many of them.” And aren’t SOAP and XML-RPC both about reading structured data+metadata as code?
As far as I’m concerned, SOAP is to XML-RPC what C++ is to C. It’s bigger, it’s bulkier, it’s harder to use properly, and there are very few things that can be done in the more complicated version that can’t be done in the simpler one.
SOAP may have its advantages, as C++ does, but those advantages generally only outweigh the additional complexity in specific limited circumstances. For 99% of what the technology is actually being used for, XML-RPC is more than sufficient and is much easier to implement and verify.