Chris's Rants

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