Chris's Rants

Saturday, March 26, 2005

ROTFL "Dorky argument for REST vs SOAP"


Post a Comment

<< Home

Friday, March 25, 2005

Blame it on Rio

Tim writes about discovering the Rio Framework. Talk about an SOA... Rio is very cool.


Post a Comment

<< Home

Thursday, March 24, 2005

Lock this, Batman

Stefan links to a post by Sean which references a post by Gordon Luk:
"...that people trying to work around this problem with complex WS algorithms are certainly expending a lot of time and effort chasing an impractical goal."
. I agree 100% with Stefan:
I don’t think anyone ever really believed that this would be feasible on the Internet. I don’t think the folks who came up with the relevant WS-* specs ever did.
Exactly, that's why we have WS-RM and WS-BA.


Post a Comment

<< Home

Monday, March 21, 2005

Hypocracy to the max

This pretty much sums it up for me w/r/t the Terri Schiavo case that has permeated the airwaves this past weekend to the point of nauseum.

The thing that irks me the most though is that the Rethuglicans felt that this was such a burning issue that they had all the congress-critters drop whatever it was they were doing during the Easter recess (why does the GOP hate Palm Sunday!?) and rush back to DC (including the preznit who was busy clearing brush at his "ranch" in Texas) so that they could pass what is widely perceived as unconstitutional legislation that effects just one individual (if a person with nothing more than fluid for a brain can be considered an individual) with the sole purpose of energizing the evangelical rightwingnut base. Oh, but Tom "the bugman" Delay made it crystal clear that it was "disgusting" to even suggest that the Republicans were pursuing this issue purely for politcal gain, despite the fact that a set of leaked Republican talking points made it clear that that was exactly what this was all about.

Yet, despite the three ring circus and the non-stop all-Terri-all-the-time coverage the latest polls seem to show that the Republicans are completely out of the mainstream on this one.


Post a Comment

<< Home

Sunday, March 20, 2005

I want my GudgeTV!

From the Spoutlet -- TedP has an idea:
I have one more idea for you if you move forward with your own reality TV show. You should never introduce Gudge to the audience or mention his name in any way. I assume that Gudge will be in each and every scene in each and every episode. Your audience will quickly begin to wonder who this little English chap is. You could effectively boost rating by shrouding Gudge in mystery and building a magnetic sense of intrigue around him much like Hunter Thompson did with his lawyer in books such as Fear and Loathing in Las Vegas. For sweeps week, have Gudge do an encore wearing his old rabbit suit while presenting Mr. Bunny's Guide to Service Oriented Architecture.
Gudge as mere sidekick ala George Costanza, Kramer, Teller, or McMahon? I don't think so.

I want my GudgeTV!

Now look at them yo-yo's that's the way you do it
You edit specs at the W3C
That ain't workin' that's the way you do it
Money for nothin' and miles for free
Now that ain't workin' that's the way you do it
Lemme tell ya them guys ain't dumb
Maybe get a typo in your last call
Maybe get errata in your Rec

We gotta install SOAP and WSDL
Custom SOA installations
We gotta validate these schema
We gotta fix these interop woes

See the little faggot with the jeans and the tee-shirt
Yeah buddy he's got no hair
That little faggot got his own rice rocket
That little faggot he's a millionaire

We gotta install SOAP and WSDL
Custom SOA installations
We gotta validate these schema
We gotta fix these interop woes

I shoulda learned to work in a committee
I shoulda learned to play them games
Look at that guy, he's up there standing on the stage
Man we could have some fun
And he's up there, what's that? More powerpoint?
Bangin' on the keyboard like a chimpanzee
That ain't workin' that's the way you do it
Get your money for nothin' get your miles for free

We gotta install SOAP and WSDL
Custom SOA installations
We gotta validate these schema
We gotta fix these interop woes

Now that ain't workin' that's the way you do it
You edit specs at the W3C
That ain't workin' that's the way you do it
Money for nothin' and your miles for free
Money for nothin' and miles for free


Post a Comment

<< Home

Friday, March 18, 2005


Via Geoff


Post a Comment

<< Home

Monday, March 14, 2005

Re: Business Value of SOA

Eric Newcomer writes:
What threatens this promise has nothing to do with technology, but rather with intellectual property. The success of an SOA based on Web services depends upon freely available standards, unencumbered by patent claims and licensing fees.
I couldn't agree more. However, I am somewhat puzzled as to what motivates this post. I just did a stroll through the WS-* specs that have been authored by IBM and its partners. With the exception of WS-Federation, I believe that all have been published under RF terms. It is certainly the case for all of the specs that have been published in the past 6 months or so including WS-Addressing, WS-Policy, WS-Reliable Messaging, WS-Coordination, WS-Atomic Transactions, WS-Business Activity, WS-Trust, and WS-Secure Conversation.


Post a Comment

<< Home

Friday, March 11, 2005

Live and let live

Stu says stuff:
Like CORBA and COM, I think SOAP and WS-* will have their successes. As will XML HTTP. Perhaps the latter will be more prevalent -- I would even HOPE so. But it's silly to turn this into some sort of religious war about SOAP. There are numerous SOAP successes today that are invisible to the blogosphere, because their inside corporations. Millions, if not billions of dollars of transactions run through SOAP at this very moment. I've helped to build some of these systems. And everything I see , talking with CIOs and enterprise architects, suggests that more will come. Live and let live....


Post a Comment

<< Home

Thursday, March 10, 2005

Who Reads What

Someone passed me the contents of Who Reads What in an email. I thought the following were pretty good:
6. The Boston Globe is read by people whose parents used to run the country and did a far superior job of it, thank you very much.


9. The Miami Herald is read by people who are running another country but need the baseball scores.
Follow the link for the punch-line.


Post a Comment

<< Home

Tuesday, March 08, 2005

Bzzzt; thank you for playing our game...

We have some wonderful parting gifts for you.

In his quixotic attempt to prove that of two disparate things one is better than the other, Carlos writes (emphasis mine):
Push based messaging is more tightly coupled because it is the responsibility of the producer to know how to push messages to its consumers. This puts the onus on a single producer supporting the requirements of all its consumers, a highly impractical proposition. The standard solution is to standardize the push infrastructure (see SMTP) placing stringent requirements on all consumers to comply with that infrastructure. Consumers are required to be constantly available and continually upgradeable to function properly in a push network. Sean McGrath has a paper that highlights the pros and cons in more significant detail.
SMTP is a protocol specification, just like HTTP, the closest thing we have to a manifestation of REST. It is not an "infrastructure", which implies implementation.

Later on in the missive he writes (emphasis mine):
An example of asychronous publish and subscribe implemented in RESTful fashion is the ad-hoc RSS network. Let's compare RSS a polled1 pull asynchronous model versus SMTP a pushed asynchronous model. The common explanation why email spam is difficult to fix because the SMTP has no mechanism to authenticate the source of the email message. However, the problem lies deeper than that, because SMTP is a push network, for it to function correctly, all the nodes of the network need to be upgraded in unison. Furthermore, message propagation are initiated by the source and not by the consumer it becomes more difficult to avoid spoofing.


1. Because HTTP does not have a built-in asynchronous delivery mechanism (see Rohit's Dissertation), polling is used.
The funny thing about this statement is that I don't seem to recall the day back in 2001 when all the world's deployed SMTP infrastructure had to be simultaneously upgraded in a "big bang" uber-coordinated systems management nightmare because the RFC that defined the SMTP protocol was obsoleted by its successor.

This argument has nothing at all to do with either SOAP v REST, or push v pull, and everything to do with how to effectively design a protocol that embraces support for forwards- and backwards- compatibility of future revisions and/or extensions; something that is certainly important in any protocol design, but not relevant to the "argument" that REST is better than SOAP, which again is just silly.

He continues (emphasis mine):
The push and pull methods both fail if the consumer isn't informed of a change in the producer. The difference however is this, which party holds the responsibility for ensuring compatibility? In general the initiating party holds responsibility. That is the initiating party makes the decision as to what is the most compatible access path. Also, in general there are more client implementations than server implementations, therefore it is less demanding a task for a client implementation to upgrade than a server. From a global perspective the amount of effort is identical, however at the local level (where it really counts) the effort differs significantly. Therefore a pull based implementation has a greater chance of ensuring compatibility.
Not quite. Again, this has nothing to do with push v pull but in the design of the protocol and its binding to a transport layer. Just because HTTP is a client-initiated request-response protocol does not mean that the session over which a "pull" will be performed need necessarily be initiated by the client nor that a push be initiated by the source. One could design an application protocol over BEEP which would allow either party to initiate the session, regardless of which will be doing the pulling or pushing.

I have no idea what is meant by the statement: "That is the initiating party makes the decision as to what is the most compatible access path". As to the statement that there are more clients than servers, I would only point out that there is more to IT than "clients" and "servers". C/S is so early '90s:-) There's also peer-to-peer interaction to be considered amongst other styles of interaction.

As to the conclusion drawn, that a pull-based approach has a greater chance of ensuring compatibility, I don't see a proof. I see a non sequitur.

He wraps up with this (again, emphasis mine):
In otherwords, the URI is not just an REST idiosyncrasy that can be ignored as the SOAP proponents have done.
<scratches head/> Huh? WTF are this and this? Once again, so-called "SOAP proponents" are unfairly characterized as being somehow anti-REST which is simply just not the case.

To assert that REST is better than SOAP because you can do things asynchronously with REST is an absurd argument. Nothing precludes doing things asynchronously with SOAP, or using SOAP in a RESTful manner.


  • I am just confused why people like Sean McGrath keep egging him on. Does that mean Carlos is making a lot of valid arguments (Disclaimer: Although I am reasonably familiar with SOAP/WS, I know next to nothing about REST).

    By Anonymous Anonymous, at March 08, 2005 10:51 PM  

  • Carlos is making some valid points, but they're largely dwarfed by invalid analogies and just-plain-wrong claims (the SMTP global-upgrade one being the most glaring one, ouch!). Quite unfortunate... especially as it forces me in the very unnatural position of agreeing with Chris. Stop the insanity! 8-O

    By Blogger Mark, at March 08, 2005 11:10 PM  

  • Mark
    Appreciate the clarification. Atleast you are being objective. Instead of looking like having to agree with Chris (which may look politically incorrect ;-)) may I suggest atleast rebutting Carlos' invalid analogies in your blog? If possible, that is.

    By Anonymous Anonymous, at March 09, 2005 8:53 AM  

  • Sorry Dilip, but I simply don't have the time to respond in detail. Chris covered most of my concerns though. My only complaint with Chris' post is where he points to the Response MEP and WebMethod feature as evidence of enlightenment on behalf of the XMLP WG wrt URIs, where the truth is that those were (essentially) forced on the WG by the TAG.

    By Blogger Mark, at March 09, 2005 9:28 AM  

  • First, there are many definitions of push and pull, I chose to define it in my article on the basis of who initiates the message. You may of course define more complex protocols where some negotiation may take place.

    As far as its support for interoperability, maybe you should re-read the article.

    MEPs and WebMethods introduced all after the fact like some kind of hack? My case has been that SOAP has been broken since the beginning and all that's being done is placing hacks all over the place as you finally figure it out.

    Ever wonder wonder why its not simple anymore? Well that's because you have all this extra baggage that should be thrown out rather than maintain backward compatibility.

    Finally, speaking about disdain for REST, yes that's an appropriate word. Sure you guys listened, but it was with contempt. Just as you continue to write in a contemptuous manner.

    We all know that its all broke, so stop with the farce and reboot.


    By Anonymous Anonymous, at March 09, 2005 9:41 AM  

Post a Comment

<< Home

Sunday, March 06, 2005

We get comments...

Carlos, in comments to my previous post writes (emphasis mine):
I think we're going to see the argument "SOAP is orthogonal to REST" repeated again and again. In the beginning the SOAP adherents were full of disdain against REST, now they want to play in the same playground!

According to Chris Ferris definition SOAP is "defines a message structure (the SOAP envelope infoset), a set of rules for processing SOAP messages, and an extensibility framework." If this is the new definition, then I would like to hear a simple explanation on how all this baggage helps improve interoperability. Now if SOAP doesn't say anything about interoperability (i.e. it is orthogonal to REST) then a clear consistent and coherent explanation of WS-* would help.
To the first highlighted point; painting all of the so called SOAP adherents with the broad brush of "disdain" for REST is both unfair and unjustified.

Henrick Frystyk Nielsen (a contributing author of the HTTP specifications), Noah Mendelsohn, and Don Box, some of the original authors of the SOAP specification, each (I believe) have a deep respect for Roy's thesis as well as a deep understanding of the Web. Other members of the XMLP WG whom (I believe) have always held REST in high regard, and have consistently maintained that SOAP and REST are complementary include Dave Orchard, Stuart Williams, Marc Hadley, Glen Daniels, and myself to name but a few. Certainly, I would put Sam Ruby in the category of those who have consistently maintained this position.

To the second point; that definition of SOAP is not a new definition by any stretch of the imagination. RTFS. If the fact that I cite SOAP1.2 as opposed to SOAP1.1 is a problem, then consider that most implementations of SOAP (generic) have been greatly influenced by the SOAP1.2 W3C Rec and by the WS-I Basic Profile which itself was heavily influenced by the work of the W3C XMLP WG. If you are still not convinced, then here's the intro to SOAP1.1 (emphasis mine):
SOAP provides a simple and lightweight mechanism for exchanging structured and typed information between peers in a decentralized, distributed environment using XML. SOAP does not itself define any application semantics such as a programming model or implementation specific semantics; rather it defines a simple mechanism for expressing application semantics by providing a modular packaging model and encoding mechanisms for encoding data within modules. This allows SOAP to be used in a large variety of systems ranging from messaging systems to RPC.
Where SOAP adds value from an interoperability perspective is in its extensibility (soap:mustUnderstand) and processing models. It provides a framework that enables gradual evolution of widely deployed services to add features, such as the ability to digitally sign a message, wherein the new feature(s) can be either safely ignored by the SOAP receiver (mU='false') to which the feature is targetted (soap:actor|role), or be designated as mandatory (mU='true').

If you don't believe you need this, then by all means, don't use SOAP. No one is twisting anyone's arm.


Post a Comment

<< Home

Saturday, March 05, 2005

1+1 = 0

Carlos, in his series: Why REST is Better, demonstrates a fundamental lack of understanding of SOAP and REST. Sorry to have to put it so bluntly.

Reading it reminded me of my 9th grade honors algebra teacher's (what is it with all this nostalgia for the 9th grade?) failed attempt at intimidating the class at the start of the school year. He told us that he would prove, using advanced algebra, that 1+1=0 and proceeded to fill the blackboard (remember those?) with all this complex mumbo-jumbo, only to reveal the answer to be... 2. Oops! I never laughed so hard!

In his part 2 of the series he begins:
So let's go over a quick summary of features of REST that we derived in the previous article. These are:

1. Named, optional, default arguments.
2. Coarse grained document passing (i.e. minimize method invocations).
3. Uniform interfaces.
Let's examine these claims with respect to both REST and SOAP.

I have no idea where he came up with #1. I've read Roy's thesis many times. I don't recall ever seeing the word 'argument'. In fact, I just did a search of Roy's thesis and the word 'argument' is, in fact, never used. The term 'named' is used a couple of times, but only in reference to resources: "Any information that can be named can be a resource...", not to arguments.

As for #2, one can just as easily (ab)use HTTP (the closest thing we have to a manifestation of REST) to exchange small messages, with many method invocations, as one can use it to exchange whole documents, er... resource representations, with a very few (one even) method invocations. This claim is not a fundamental feature of REST.

I won't dispute that #3 is a fundamental feature of REST.

Let's now examine these as relates to SOAP.

In the first entry in the series, Carlos wrote:
So let's begin the explanation of why REST is better than SOAP in its support of interoperability. Let's start with a simple method invocation (java syntax):
object.method( arg1, arg2, arg3 );
A collection of these methods is the typical starting point of a SOAP implementation. The first interoperability problem that we encounter here is the order of the arguments. A better solution would be to introduce names, optional, default arguments. In the absence of this construct the way to do this is to objectify all the arguments (see Half-Bean Pattern). So now we have this:
document.arg1 = a;
document.arg3 = c;
document.arg2 = null;
object.method( document );
The advantage is that there is no explicit dependencies in the order of the arguments. Second you have the opportunity to introduce optional arguments. Finally, there is no need to have multiple method signatures for different calling variations. This allows one to design the API to make the most common operations easy to do.
Would someone please point out for me where is it that SOAP constrains one from designing an interface such as this? Sure, the SOAP RPC Representation defines a way of modeling a remote procedure call such that the procedure/method/operation name is the top-level child of the soap:Body, and that the procedure/method/operation's arguments are children of the procedure/method/operation name. However, that is merely a stylized use of SOAP, and an optional one at that. We (the XMLP WG) put this section in Part 2 - Adjuncts for a very good reason. SOAP is not inherently RPC-centric.
SOAP Version 1.2 (SOAP) is a lightweight protocol intended for exchanging structured information in a decentralized, distributed environment. It uses XML technologies to define an extensible messaging framework providing a message construct that can be exchanged over a variety of underlying protocols. The framework has been designed to be independent of any particular programming model and other implementation specific semantics.
One can use SOAP in exactly the manner in which Carlos is suggesting; to pass a single argument that itself has structure in which the elements are named, may be ordered or unordered, and which can have default values.

Next up, #2 -- coarse-grained message exchange. I've already made it clear that this has nothing to do with REST, nor does it have anything to do with SOAP. It has everything to do with how you use them. You can choose poorly, or wisely, Grasshopper.

Finally, #3 -- uniform interface. Someone please show me where in SOAP it says that you cannot have a uniform interface? I'll wait...

Of course, it isn't fundamental to SOAP that there be a uniform interface, but then again, SOAP doesn't define any verbs. It only defines a message structure (the SOAP envelope infoset), a set of rules for processing SOAP messages, and an extensibility framework. The likes of WS-Transfer and MEST define a uniform interface. Furthermore, as Stefan points out in comments to Carlos' post, there's no reason whatsoever why SOAP cannot be used in a completely RESTfull manner. It is, afterall, just another media type which can be exchanged using HTTP. In fact, David and I were discussing this very topic over dinner last night.

A little Clapton was never more apropos:
It's in the way that you use it,
It comes and it goes.
It's in the way that you use it,
Boy don't you know.

And if you lie you will lose it,
Feelings will show.
So don't you ever abuse it,
Don't let it go.

Nobody's right till somebody's wrong.
I can't wait for the third installment in the series. Carlos promises to cover asynchronicity, whatever that means.

Frankly, I grow weary of this incessant argument that REST is better than SOAP, nyaah, nyaah, nyah, nyaaah, nyaaah. The point is moot, as in:
... people also began to look at the hypothetical side of moot as its essential meaning, and they started to use the word to mean "of no significance or relevance." Thus, a moot point, however debatable, is one that has no practical value.
REST is an architectural style. SOAP is a message format with a well defined processing and extensibility model. Comparing the two is like comparing HTTP with HTML.

I would much prefer that the discussion be focused on how we can leverage the two synergistically. I find that far more interesting and compelling.


  • I think we're going to see the argument "SOAP is orthogonal to REST" repeated again and again. In the beginning the SOAP adherents were full of disdain against REST, now they want to play in the same playground!

    According to Chris Ferris definition SOAP is "defines a message structure (the SOAP envelope infoset), a set of rules for processing SOAP messages, and an extensibility framework." If this is the new definition, then I would like to hear a simple explanation on how all this baggage helps improve interoperability. Now if SOAP doesn't say anything about interoperability (i.e. it is orthogonal to REST) then a clear consistent and coherent explanation of WS-* would help.


    By Anonymous Anonymous, at March 06, 2005 7:31 AM  

  • Before you try to engage in a discussion with Carlos Perez on a topic in which you think he is not entirely correct, I suggest you read his series on "101 Reasons why Java is better than .NET", and the ensuing debate with Ted Neward.


    By Anonymous Anonymous, at March 06, 2005 1:49 PM  

  • In the beginning the SOAP adherents were full of disdain against RESTThat's simply not true. Look at the W3C XML protocol working group public mailing list, and the www-tag public mailing list, from about this time of year in 2002. There was lots of very respectful listening to people like Paul Prescod and Roy Fielding. This resulted in numerous changes being made to SOAP 2.0. Or look at the W3C Web Services Architecture Note from about a year ago (Chris originally chaired that working group, and I took over later). It doesn't exactly say that REST and SOAP are orthogonal, but treats them as complementary rather than antagonistic.

    Any disdain you may detect comes from annoyance at hearing the same old arguments for three years now, with the Web Services side listening and incorporating some of the good ideas that Fielding and others have expressed, whereas prominent REST advocates are raising the same old issues and once again trying to obstruct a WS spec in W3C, showing no signs of having listened to what the other side has to say.

    Anyway, the "baggage" isn't intended to replace or improve interoperability of plain old XML over HTTP for automated Web applications (e.g. the Yahoo API). The interoperability gains come when one has to deal with multiple transports, encryption, authentication, security, transactions, binding to programming objects, etc. You can happily roll your own POXy / RESTful versions of all this (as eBay has done, for example), but then all your clients have to understand your homegrown schemes. As requirements get more complex, at some point it does become better/faster/cheaper/simpler to leverage the WS stuff than expect people to adopt the REST paradigm (try explaining "hypermedia as the engine of application state" to an ordinary Java developer!)

    By Anonymous Mike Champion, at March 06, 2005 4:27 PM  

  • I don't see the business case for integrating applications over multiple transports, multiple encryption etc.

    Then again, that may be a problem with me; for example, I also don't understand why a sane development team would want to use multiple programming languages to develop services in the scope of the same project.

    I feel the REST way to be more compatible with the object oriented paradigm, too. PUT/GET/POST/DELETE/OPTIONS maps nicely to construct/access/modify/destroy/rtti IMO.

    By Anonymous Ferhat Savci, at March 15, 2005 12:57 PM  

  • Ferhat Savci said...

    "I don't see the business case for integrating applications over multiple transports, multiple encryption etc."

    Let's say the IT system for the Fire service needs to talk to the IT system for the Ambulance service (and the IT systems for a whole bunch of other services that are significant in a crisis). They all use different networks, hardware, security etc.

    By Anonymous Anonymous, at April 07, 2005 8:18 AM  

Post a Comment

<< Home

Thursday, March 03, 2005


Kevin Drum:
This, I think, is a key characteristic of bullshit: not just that the bullshitter knows he's bullshitting, but that the bullshittee also knows it. He may know it for sure, or he may just suspect it deep in his heart, but part of the essence of bullshit is that both sides implictly recognize that the statement in question is, in fact, bullshit. In this way it acts like a compact between spewer and receiver, a shared secret that brings them closer together. Thus the piquancy of bullshit, as well as its popularity.
The post references an essay entitled "On Bullshit" by a Princeton philosophy professor which became a "classic". Reading this reminded me of a prank I pulled in the 9th grade on my American History teacher, Mr. Buttrick.

Mr. "Butt", as we referred to him behind his back, had developed his system over the years to the point that he was basically running on auto-pilot as a high school History teacher. He would assign his students a writing assignment every week; a 2-3 page essay on whatever happened to be the topic du jour (or more correctly; de la semaine). The assignment counted as a quiz grade.

The student lore that had developed over the years was that Mr. "Butt" didn't really read the papers, but instead assigned a grade commensuate with the student's average and class participation. This was based on anecdotal evidence that over the years, students had handed in half-hearted attempts yet still received a decent grade. Another aspect of his "system" was that he had one of his students grade the nightly homework assignments, rather than grade them himself.

Being the wise-ass that I was at age 15, I decided to put the hypothesis to the test; to prove that he never actually read the essays. I handed in a 2 1/2 page essay (I can't recall the topic now) in which the first and third page was just your basic bullshit high school essay. However, to prove the hypothesis that Mr. "Butt" never actually read the weekly essays, I filled the second page out with the word "bullshit" repeated to fill the page.

Needless to say, I got a B for my efforts and became a folk hero amongst my peers. (B for bullshit!:-)

I'd have to say that based on my own little experiment of the hypothesis; I agree with Kevin's conclusion; that the bullshitter knows he's bullshitting and doesn't care, and that the bullshittee either knows or suspects he's being bullshitted and doesn't care.

Wednesday, March 02, 2005

Method and Apparatus for Hacking into SCO's Web Site

Groklaw (emphasis mine):
SCO's defense is to allege IBM deliberately bypassed "security measures" -- in this case, we find out, a password prompt that didn't actually require a password or hinder free access in any way, due to SCO's incompetence -- and so they allege IBM "hacked" into their site. If that is illegal, could someone please rewrite that law so it isn't stupid any more?
Read the whole post, it's hysterical!

Just a fleeting glimpse

Stefan links to a quicktime video of David Gilmour performing one of my all-time favorite songs. Gilmour's ability to make his guitar nearly cry brings goose-bumps. Damn, I wish I could play as well.


Post a Comment

<< Home