Web Things, by Mark Baker

Last week marked a turning point.

I enjoyed myself at XTech (as usual), where, as you’d expect, a lot of the talk was about Web 2.0, mashups, and yes, even “Web services”. Thankfully though, it’s not the usual “Web services”; what I noticed (confirmed by others), much to my surprise, was that the users seem to have reclaimed the term from the enterprisey architects, and, at least in Amsterdam, were using it to refer (almost) solely to RESTful (or “REST-like”, ala Web style) Web services!

I have to admit, when I hear it used this way, I was taken aback, and it took me more than a few double-takes before I caught on that I really could let my guard down; these were friendly folk.

I didn’t see that coming.

soa, rest, web, enterprisey, webservices.

ROTFL! Nicely done.
(link) [del.icio.us/distobj]

In response to Tim Bray’s piece calling bullshit on SOA, Loek Bakker responded with some comments that get right to the heart of the matter, IMO;

WS-* services and REST services are not competing, they are complementary. Web Style serves another purpose than SOA. Consumer-facing services have other QoS requirements than high-volume, cross-platform A2A transaction services.

That’s really interesting from my POV because it shows that after many years of a debate, that we – the Web folks – still haven’t successfully gotten our message across.

That message? That these services are competitive.

It’s as Sean says (channeling some unnamed prophet);

A complex system that works invariably can be traced back to a simple system that worked

Meaning, in this context, that if you want to build something suitable for “high-volume, cross-platform A2A transactions”, start with the Web and build up. Web services don’t do that; they strayed from that the moment they confused transfer with transport.

Tags: soap, soa, rest, web, webservices.

Rojo doesn’t export by URI either… which is why I just updated my blogroll with Bloglines’ script-importing tool; it’s not up-to-date, but it’s more up-to-date than what was there. 8-( Big +1 to Peter’s last paragraph, “So why use REST?”.
(link) [del.icio.us/distobj]

Mark asks, what’s the point of trying to get SOAP proponents to make better use of HTTP?

I hold out no hope for SOAP, but I do hold out hope that its promoters will eventually understand and embrace HTTP as an application protocol, and in doing so, the Web as a first class distributed computing infrastructure. And I figure the best way to facilitate that is to participate constructively (as best I can, given my not-quite-thick-enough-for-the-job skin 8-).

Most importantly perhaps, for me personally, these past six+ years of explaining this stuff has forced me to work out a lot of kinks in my own understanding of the Web (in combination with actually building the systems I was describing, of course).

Who was it that said that the best way to learn something is to explain it to somebody else?

Tags: soap, http, rest, web, webservices.

Not too shabby! No operations in the URIs, AFAICT.
(link) [del.icio.us/distobj]

What I wish, is that despite the well-meaning intentions of folks like Sanjiva and Clemens (and even Marc Hadley, from a couple of months ago), that they’d step back and look at what they’re proposing from a developer POV.

Developers want a library that assumes the same things they assume. Forcing them to be explicit about those assumptions is the quickest way to turn them off, IME.

Consider: java.net’s support for HTTP and URIs, for all its problems, is still able to turn a URI into data – the most magical of Webish incantations – in about three lines of code. If your solution can’t match (or beat!) that, I’d be heading back to the drawing board.

And +1 to what Stefan said.

Tags: soap, soa, rest, webservices.

Ok, that last one was a cheap potshot at Annrai’s latest, but the article offers some interesting wisdom, this bit in particular;

The Wiki metaphor (and its implementation) is the perfect vehicle for sharing and managing SOA artifacts across an organization. Then if anyone makes a change to a service that you are interested in, RSS should be able to inform you when that happens and you can make any necessary changes.

It sounds like he’s describing more of a management interface, but hey, it’s a start. It’s a short step from there to realizing that all services can spit out RSS notifications upon a change of state, not just ones monitoring other services.

Tags: soa, rest, webservices.

A new term, “Web style”. Sounds good, but do we need more terminology? I don’t think so. Perhaps this could replace “POX” or “Lo REST”? Who knows. But at least it’s better defined than those two.
(link) [del.icio.us/distobj]

A great post from Uche, which references another great post from Dare. Dare writes;

The funny thing about a lot of the people who claim to be ‘Enterprise Architects’ is that I’ve come to realize that they tend to seek complex solutions to relatively simple problems. How else do you explain the fact that web sites that serve millions of people a day and do billions of dollars in business a year like Amazon and Yahoo are using scripting languages like PHP and approaches based on REST to solve the problem of building distributed applications while you see these ‘enterprise architect’ telling us that you need complex WS-* technologies and expensive toolkits to build distributed applications for your business which has less issues to deal with than the Amazons and Yahoos of this world?

And Uche follows up;

I’ve recently had occasion to discuss my “enterprise” credentials with some mainstream-y CIO/CTO types. It always amazes me how many of that number gaze vacantly at simple architectural ideas, and find true comfort in endless, overlapping boxes with data arrows flying in all dizzying directions, so long as those boxes are labeled “Oracle”, “SAP” and such.

Indeedy-do. I could have sworn I wrote a blog post a while ago about this, but I can’t find it… but the gist was that complexity is actually desirable to many architects (enterprise or otherwise, but more prevalent in enterprise IME) because – at least as far as I can determine – it seems to validate the importance of the problem; the more important the task, the more complexity that’s “desirable”. Obviously this is the complete antithesis of principled design.

So forget open source, open standards, software-as-a-service … the wholesale simplification of inter and enter-prise architecture by putting it on the Web, is by far, the biggest disruptive force facing – and indeed, currently shaping – our industry today.

And Uche just followed up with a beaut (why can’t I come up with these?!);

My recent experiences, and Dare’s quote, bring me to mind of the old adage: “No one ever got fired for buying IBM”. Why is there no sign of a corresponding “No one ever got fired for designing like Google”?

Sweet Uche, very sweet. But have patience, it won’t be long before that’s mainstream thinking. As one of the Dare’s commentors said (in a very lesscode/Gandhi-esque style);

First they ignore you.
Then they laugh at you.
Then they just say 'Ok, well you can exist, but our problems are
*much* more complicated, as distributing a two-phase transaction
update between 15 business partners using 3 different security
tokens types is /never/ a bad idea...'.
Then you win.

Tags: soa, rest, softwarearchitecture, enterprisearchitecture, architecture, enterprise, web, webservices.