‘I always thought that REST should stand for “really easy services, today”‘
(link) [del.icio.us/distobj]

Via the Now Economy, a good summary of the past few days’ goings-on regarding the WS-* mess backlash, with lots o’ links.

Amen. Stick a fork in WS-*, because as Simon says, Web Services are receding

Wow, the shit’s really hitting the fan this time, isn’t it? Go go stop energy!

The latest entrant is a surprise (to me at least); Simon Fell, author of PocketSOAP.

Though Simon and I may not like the stack for different reasons, any way you look at it, WS-* seems to be on its last legs.

Onwards and upwards to true loosely coupled, document exchanged based distributed services! You know, the World Wide Web.

If you’ve heard me discuss Internet scale systems, you’ve certainly heard me talk about the necessity of interface constraints for those systems. What hit home with me today was that this term is probably unfamiliar to a lot of folks, so it could be of value to attempt to relate it to other things that they might be more familiar with.

What other names does “interface constraint” go by? “Component model” is one you might recognize. The value of component models like Java Beans derives entirely from the generality of the common interface they define. In the case of Beans, that interface isn’t complete (it’s more akin to a CRUD interface) but it remains useful.

Hmm, I wonder what a complete distributed component framework might look like? 8-)

Patrick asks for clarification of my previous statement about how, IMO, REST proponents generally like SOAP and dislike SOA. He writes;

I consider myself a REST convert, to the extent I think I understand it and its incarnation in HTTP. Though I don’t understand the position above. Is there even a concrete definition of SOA with which to make this statement?

I thought SOA was a fairly innocuous term, being so vaguely defined that an SOA could be built using REST and HTTP.

“innocuous”? I wouldn’t say that. I think it’s actively harmful as a name for an architectural style. As I see it, “SOA” means different things to different people. As such, it’s almost entirely useless since it does nothing to constrain how one might go about building distributed systems. That’s why I don’t like it. It’s for the same reason that I wouldn’t recommend the null architectural style as a guide from which to design an architecture; all REST and SOA based architectures are instances of the null style too! 8-)

I was flabbergasted to discover that I was the only subscriber to The Now Economy on Bloglines.

If you’re interested in a weblog that can discuss mesh networks in one post, and pasture management soon thereafter, and just generally cover the gambit of what decentralization and instant (modulo latency, of course 8-) gratification might mean to business in the coming years and decades, you should be subscribed.

Adam and Rohit are the brains behind KnowNow and mod-pubsub, and are both now at CommerceNet Labs.

Update; it seems Bloglines has a bad URI comparison algorithm, since I heard from somebody else that they see 9 subscribers, yet I still only see 3. This jives with two other things I’ve observed about the service; that it recommends feeds I’m already subscribed to, and that it doesn’t permit publication of URIs ending with “/” (which could very well explain all these problems, I think). Bah!

However, today’s web is not the end state of machine-to-machine communication.

Agreed. It’s not the end, it’s the beginning.

According to Michael Curry, Forrester has a report on REST vs. SOAP which concludes saying basically that SOAP is a better long-term bet. First of all, the debate isn’t REST vs SOAP, it’s REST vs. SOA. SOAP can be used in the context of many architectural styles, and the SOAP spec itself says basically nothing about which should be used; though it does have explicit support for RPC and REST (by virtue of some design decisions made regarding the HTTP binding, thanks to yours truly). Also, Forrester’s claim that REST proponents rag on SOAP is backwards; we like SOAP, mostly. We just don’t like SOA.

Also, apparently the principle argument against REST is that it lacks standards support. Seriously?! Ever heard of URIs and HTTP? You know, two of the most wildly successful standards in the history of distributed computing? How one can compare WS-* with 100s of millions of deployed and currently-interoperable servers and clients, and then conclude that the latter suffers from a lack of standards support, boggles my mind.

Michael also adds his own critique;

Randy makes some good points on the standards issue that I failed to bring up. He doesn’t bring up the fact that REST breaks the MVC paradigm, however.

Who knew that MVC was a benchmark by which large scale distributed systems are evaluated? Back to the drawing board for me! 8-)

Omri Gazitt has a Web/REST gestalt moment and doesn’t even realize it. In talking about how WS-MetadataExchange might integrate with WS-Transfer, he writes;

In order to “dereference” the MetadataReference EPR, you may issue a “Get” message (which is defined in WS-MetadataExchange), but logically this is exactly the same operation as the WS-Transfer Get operation. Now it all starts to hang together…

Erm, yah, it does, doesn’t it? Of course, the Web has been getting things to hang together in exactly that manner (modulo s/EPR/URI, s/Get/GET) since day one.

Progress, in a regressive kinda way. I don’t know whether to jump for joy, or cry. 8-/

Simon St.Laurent
(link) [del.icio.us/distobj]