Slashdot Mirror

XML-RPC was the first succesful open standard for an XML-based RPC and SOAP was based on XML-RPC. There are a number of reasons they are interesting technologies. Perhaps the biggest right now is that SOAP is one of open standard technologies at the core of Web Services and Microsoft's .NET.

Love it or hate it, there is a good chance that there will be a lot of .NET software out there Real Soon Now [tm] and it will be using SOAP as its fundamental RPC protocol. If you are a developer, then now is a good time to learn this technology.

One of the disadvantages of XML-RPC and SOAP in commercial software development is that they are very human-readable: they pass XML documents between systems. Many times this is a good thing, of course, especially when you are debugging your system. But if you are passing confidential information (say your customer's bank records) then you will need to work at obfuscating (and de-obfuscating) the XML that is actually sent.

There are also some overhead concerns with (particularly) SOAP, but careful design and use can overcome these.

Lets clear the smoke.

If "two" (forget more for a second) "alien-things" happened to agree to use a messaging protocol, such as SOAP, well, right there we would have a minor (but cosmic , considering that "alien-things" are involved) miracle , since apparently they communicated their agreement without a common communication means. (No. Telepathy doesn't count.)

Smoke: XML messaging (SOAP) works miracles!

Fact: "[A]lien-things" first need a common mechanism for reaching consensus regarding communication of information..

So lets say they belong to the Inter-Galactic Alliance of Geeky "Alien-Things" [I-GAGA-T(TM)], governed by the I-GAGA-T's strict policies regarding communication means deployment. [Kinda like the saying "lets all use HTTP"]. Then, our two brave "alien-things", charter members of I-GAGA-T (affectionately known to each other as GAGAs), decide to communicate using SOAP, at which point they have fulfilled "the ONLY requirement when doing client/server" according to their recently hired communication consultant, an Earthling named garoush . [Believe me folks, I am not making this up. A true story from the GAGA archives.]

But have they?

No. One of the GAGAs decides to send a message using SOAP to its newly acquired friend! So the trusty (and somewhat rusty) SOAP client is fired up and the message is sent. And guess what? Promptly comes the standard error reply: "Message received, NOT understood. Ca va?"

Put simply, using SOAP, two or more 'alien-things' can communicate to each other as long as they agree on the SOAP protocol - which is the ONLY requirement when doing client/server using SOAP.

So, put simply, the above is a false statement.

[And this point in the story, we find an agitated and nervous garoush, furiously sending SOAPy messages to Earth: "<help>Me!!</help>" -- Lets hope that back on Earth, garoush's friends have first agreed on the Rescue-Message-Format! (But maybe they didn't, hey garoush? "Just use SOAP" he used to say back on Earth. Well ... Just use SOAP then :) )]

SOAP, and XML-RPC, both provide a means for one GAGA to send messages to another GAGA, even if the two GAGA have discovered each other for the very first time. And this messaging protocol , based on the well-understood [there!] request-reply paradigm, and utilizing a standard XML-based message container , delivers SOAP-compliant XML messages from the sender to the receiver.

So as garoush learned/will-learn [funny thing, this space-time continuum] from his consulting gig to the GAGAs, <help>Me!</help> is not defined. For the content of the message, which delivers information from garoush back to Earth, to be understood by the recipient's), he and his hoped-for-rescuers would have first needed to agree on the format of encoding information in your SOAPy messages.

Sure CORBA, DCOM, COM+, Java, etc. allow you to enable two different components to talk to each other, but those technologies do it in such a way that you must have a 'piece' of the server (called the client) to be delivered and used by the client developer. Thus, to talk with a 'server' you must meet the needs of the 'server' when using CORBA, DCOM, COM+, Java, etc. With SOAP, this is all eliminated. As long as the server publishes its API via the SOAP protocol, I can write my client to talk with the server using what ever I want. This frees me from having to 'embed' in my client a piece of the server -- thus there is no longer any 'hard-coupling' between two 'things'.

[We'll skip the fact that SOAP, CORBA, [D]COM[+], and "Java" are a rather orthogonal set of technologies ...]

What is apparently not understood by garoush is that CORBA, DCOM, COM+, Java RMI, do much much more than just simply pass messages from one GAGA to another. [I recommend this great book written specifically for GAGAs for more information on what real (i.e. working) Inter-GAGA Communication Protocols require to function. (Check out the GAGAs on the cover!)] .

Lets just take Java's RMI as an example. What's this with RMI you say? Why didn't they call it Java RPC? I'm glad you asked. See the 'M' in RMI? That's a method, which is a procedure bound to an object. The P in RPC refers to a procedure, which is not necessarily bound to anything. To invoke a method of an object, you first need to get a handle on the object, a remote reference. Any object you say? No. Objects which have been registered with a Registry/Directory Service ( UDDI anyone?) Then you pass the method invocation message to the remote object and a bit of infrastructure on the receiving end maps your method invocation message to an actual method call on the specific object you are invoking. This sub-process of mapping your messages to actual method calls on a specific object uses a messaging protocol which is analogous to what SOAP specifies.

So:

Smoke: SOAP (& XML-RPC) are distributed object technologies! [This goes beyond Smoke and verges on GAGA humor..]

Fact: SOAP is a Simple Xml-based Messaging Protocol (SXMP)

Fact: By the time you have implemented a true Simple Object Access Protocol using a SXMP, you will have something that will look awfully close to RMI. (With the exception that RMI doesn't shuffle needlessly verbose ASCII bits through its system-level plumbing, but your SOAP does.)

In short, by the time you have provided the functionality of an RMI mechanism, such as Java RMI, using SOAP (or any RPC mechanism), you will have accomplished, by the prerequisite functionality of the task at hand, a fairly complex bit of software engineering. Congratulations! (CORBA? Oh boy ...)

In short, using SOAP, we now enable a true 'smart' data-exchange-protocol between two systems such that development is now at the level of "data-exchange" rather than API, SDK, language, etc.

No. More likely, you will realize that having standardized on the data-exchange, you have in effect delegated the complexity of building a distributed object system to the client as opposed to the infrastructure.

Now that is smart. [Good going there Bill!]

[Meanwhile, back on Earth, garoush's friends and would-be rescuers [will] happen upon a long forgotten SOAP Server log file. There, buried among other debug and error messages is the messaging logging the error message the SOAP server sent back to garoush back on planet X. "Ouch" says one of garoush's friends. "I hope he is OK". Now, isn't it just great that XML messages are human readable? (Its too back Servers aren't human -- damn shameful waste of all that human readable information!)]

Smoke: SOAP/XML is a great leap forward!

Fact: Bubble Economies produce Bubble Technologies .

My biggest issue is that for XML-RPC to support things that are the biggest issues of distributed computing (e.g. keeping track of state) would add so much bloat to the XML parsing, string building, etc process for making a remote call as to make it unfeasible.

I think XML-RPC is to be used for basic stuff like finding out what MP3 someone is listening to or getting a relevant subset of some site's content that you can parse easily for inclusion on your own site. It's probably not (as you say) good for clusters and so on... But I don't think it's proponents want it to be used for that either...

Read more about it at XML-RPC.com!

--8<--

I haven't had a lot of time to study the UDDI spec, but I have been pondering the topic of Open Services for quite some time and my feeling is they will. I like the term Open Services, as Tim O'Reilly calls them, over Web services because this concept is applicable beyond HTML and just the Web.

I think the biggest hurdle at the moment for this concept, is the perception that Microsoft invented this concept (therefore there must be something sinister and evil behind it!) and its tied to just their technology which is just plain off.

The idea of open services where around before SOAP. I haven't done an in-depth genealogy of the concept, but I can tell you Dave Winer at Userland has been evangelizing it for a couple of year now. There is also Allaire's WDDX and in a looser sense RSS and ICE.

Microsoft did initiate the SOAP spec, but have put they have opened it up and submitted to the W3C. They incorporated IBM's feedback which garnered IBM whole-hearted support. IBM released their Java implementation on AlphaWorks and then donated the code to Apache. Even Sun conceded it was a good idea and gave as much of an endorsement as they could stomach for something Microsoft had initiated.

I would even argue that IBM is excelling beyond Microsoft. Well... at least in the developer community. They've yet to release anything commercially or articulated a product strategy that utilizes it. (Typical them.) Microsoft does seem to be betting quite a bit on SOAP/Open Services and going from there.

What I love about this concept (and why I think it will succeed) is that its fairly easy and straight forward to work with. It also is a more concrete way to get all of these different platforms that are deployed to talk to each other. It will just makes developing easier, better and smarter.

The way I read it, UDDI is just a progression in making solutions built on this concept more robust.

For all of those interested in this topic, here are some good background links on the topic that aren't so Microsoft-rah-rah.

• The Network Really Is The Computer
• XML: A Disruptive Technology
• AGENCY.CO M's Flexitecture Methodology
• Meerkat: An Open Wire Service
• XMethods: Web Service Listing
• SOAP::Lite (A lightweight SOAP server written in Perl)
• xml-rpc.com
• soap.weblogs.com
• Apache SOAP

If you ask Jon Udell, the web services are already here. The latest buzzword advances with XML, SOAP, XML-RPC, and friends are all just further refinement and evolution of the interface. Also, Udell's book, Practical Internet Groupware, talks extensively about adapting existing sites into web services. For example, a site like MetaCrawler demonstrates this in how it uses search engines' HTML "interface" to scoop up search results. Or, take the scripts that query news sites without the benefit of RDF or RSS, parsing HTML to scoop up and aggregate news headlines. These are all primitive web services.

And this is not to mention app servers such as Zope and Frontier, which are already built to offer web services natively. It just seems irresistable to use all of these simple building blocks to create neato keen distributed systems...

I'd definatly have a look at XML-RPC (http://www.xml-rpc.com/)

While implementations are not available in every language (of note, Java, Perl, and Python have implementations), it's simple enough to write your own easily.

I've writtern a few programs using it with Python and Delphi, with great results.

In essence, it's doing a procedure call, with the parameters and return values in an XML format, over HTTP. If you're famliar with both, it's dead simple to do, if not, it's a great excuse to learn :)

I take issue with the following quote regarding XML and XML-RPC:
It's a bad sign that Microsoft knows more about this than the leaders of the Linux community. They've already incorporated it into a new protocol that they are calling SOAP.

Ok, I'm far from being a "leader" in the Linux community (or any other), but I've been monitoring the XML-RPC and SOAP discussions for a while now. Many of the underlying grammars were clearly written by people who like COM. The data types conveniently mirror COM VT_xxx types. They CAN, however, be implemented in other languages and platforms. (IIRC, Zope implements XML-RPC.)

Personally, I have misgivings about SOAP being used for real cross-platform distributed computing in the future. It just seems to make too many assumptions about data types. XML-RPC seems geared towards replacing CGI -- it specifies port 80 for all communication (which seems a little narrow-minded to me). These may still become de facto standards because they are "good enough" for most cases.

I predict that for the next few years we will see several new XML grammars introduced. In time, we will eventually settle on a few that work best for most people. Maybe SOAP will be one of these, maybe not. Maybe it will be a derivative of SOAP. Maybe it will be something completely different.

Right now, XML-RPC/SODL/XMOP/SOAP have momentum and the backing of Microsoft and a few authors who want to be first on the shelf with "Designing Distributed Applications with SOAP for Dummies" I'm not aware of any alternatives to SOAP right now. Maybe there is no need for one.

If you've gotten this far in my long-winded post, you may want take a look at a few sites relating to XML and distributed computing:

http://discuss.develop.com -- SOAP discussion board.
http://www.xml-rpc.com -- XML-RPC specs and discussion.

My own shameless plugs:
http://www.maiermedia.com/lab/xml/opml.t xt -- My OPML proposal for object persistence in XML. It's crude, but I think it has less platform affinity than SODL.
http://www.maiermedia.com/lab/xml/ opmlsample.txt -- A sample of objects serialized in OPML.

At this point, I've shelved OPML because I don't see any point in competing with the SOAP crowd. If you do take the time to look at it and would like to send suggestions or feedback, my email address is donkpunch@maiermedia.com. I would love to get some input from people who aren't already convinced that SOAP is the best solution. Maybe I gave up on the idea too soon.

Thanks.