The ebb and flow of personalized information whatever falls out of my brain on a given day.  
    Updated: 5/5/02; 11:12:44 PM.

 

Click here to send an email to the editor of this weblog.
Email

Click to see the XML version of this web page.

General Interest

Macintouch
MacOS X Hints
Scripting News
Doc Searls
Hack the Planet
bOing bOing
Jonathon Delacour
Mac Net Journal
mac.scripting.com
SATN.org
2020 Hindsight
Flangy News
My Apple Menu
Dan Bricklin
Inspirational Technology
Yourish
Kris Amico
Sam Ruby
USS Clueless
Josh Lucas
Mark Paschal

Geekware

Apache XML
XML Protocols
XML 1.0 Spec
WSDL
xmlrpc.com
soapware.org
opml.org

Radio

Radio Userland
Cheat Sheet
Andy's Radio Resources
Frontier Scripting Tutorial
Matt's Book
DocServer
Radio Stories
RSS 0.92
RSS 0.91

 
 

Friday, April 19, 2002

Why I'd pick SOAP over XML-RPC The raging debate of the week has been interesting to catch up on after being ill for a couple of days. The Google API has spawned an interesting thread between many parties over the API itself, SOAP versus XML-RPC and quite a bit of fringe discussion.

My simplistic take on things.

Google already had an API that they made available to partners, but it was probably more complex than it needed to be. They decided to implement a new API over SOAP. By making the API freely available with limits that impact its use in a commercial setting, they have gotten a lot of load testing and SOAP interop testing that would have been difficult for them to do on their own. A win-win proposition, which let's people use free tools to get acquainted, and enter a contractual situation if they need more from the Google service.

Edd Dumbill was correct to point out that other, more traditional screen scraping techniques exist, and are being used all over the place for things like this. But that's besides the point. Exposing functionality via SOAP (or even XML-RPC) separates the data and functionality from the presentation (or display), eliminating all the nasty work to figure out ever shifting screen formats. For companies providing services, it also allows them to set up a way to monetize the service if this should be a goal (this can been seen as good or bad, mostly depending on which side of the service you are on).

Another positive reason for exposing functionality via SOAP is the growing support for DTD's and WSDL (and potentially UDDI, that potential has certainly not been realized yet). I really dislike WSDL, but it's becoming a strong component of SOAP services (with automatic generation of interfaces now happening for many languages, including AppleScript). Feed the WSDL file to a generator and all the interface code is automatically generated.

This contrasts to the situation in XML-RPC land, where most of the connections are wired up by hand and DTD's (if they exist) may be out of sync with current implementations without repercussion.

I see this as being similar to the fight in the AppleEvent (AE) world in the early 90's. UserLand created the idea of Frontier glue files which could be shipped with your application to allow Frontier users to call all of your applications AE functionality. Eventually, Apple created the AppleEvent terminology extension, a convoluted resource description of AE functionality (much like WSDL in many respects). It took a while to pester people to add the ability to Frontier to read the 'aete' resource and generated stubs automatically. Hand wired interfaces versus automatically generated interfaces. There are things about XML-RPC I prefer (avoidance of the namespace issues), but I am going to have to use SOAP for anything I want to massively deploy.


11:51:31 PM    


© Copyright 2002 Dave Ely.



Click here to visit the Radio UserLand website.

 


April 2002
Sun Mon Tue Wed Thu Fri Sat
  1 2 3 4 5 6
7 8 9 10 11 12 13
14 15 16 17 18 19 20
21 22 23 24 25 26 27
28 29 30        
Mar   May