I was wondering how long that would take. 8-)
And here I was thinking 2004 was supposed to be it. Or was that 2003? It’s hard to keep track, except that I’ve noticed that it always seems to be next year… at least until folks just get tired of waiting.
Yet another good thing about the Web; it already had its “year”, ten years ago.
I don’t think people are embracing REST services because of architectural purity (the rest of the Web isn’t pure REST, so I don’t know why this would be). Rather, they embrace it because it’s easier in a lot of cases. There is no reason that SOAP couldn’t be the same, except that toolkits hide raw XML and you have to know how to get it.
To the first point, yes, certainly, they embrace it because it’s simpler and easier. Absolutely. As we’ve seen, they often screw up, but even then it’s very often preferable to SOA.
To the second point, there actually is a critical reason (in addition to the “hide the XML” problem) why SOA/WS cannot be as simple as REST; that the architectural constraints which induce the bulk of the simplicity in REST (uniform interface, self-description), are eschewed by SOA/WS. Isn’t it ironic that their raison d’etre – service specific interfaces – is the reason they will fail to see widespread deployment? I think so. 8-)
A gem from Mark, discussing the sad state of affairs with Web services architecture. Of course, he manages to do it without sounding like he’s criticising. How’s he do that? Gotta get me some pointers. 8-)
If Web services is a bag of specifications that only constrain you by accident (“it must be XML,” “it’s message-based,” “the basic unit of interaction is the ‘operation’”) then Web services has no architecture, at least in this sense of software architecture*; it’s just flinging messages around.
Pretty much, yep. Didn’t I point that out already? 8-)
But as a meta point, isn’t it nice how clear things become when using the language of software architecture to examine, well, software architecture? Why has it taken so long to get to this point? And why was it being defended so fanatically before anybody even bothered to study the architectural suitability of this new fangled architecture, especially when an existing loosely coupled, document oriented architecture was already available? There’ll be lots of time to answer those questions in the coming years, but it’s extremely disappointing to me that we weren’t able to ask them in time to avoid learning a lesson the hard way.
But hold the phones! Along the way, we learn this;
Read operations using a generic protocol (ie GET) hits the 90/10 point
Woohoo! Preach it, brother!
But you knew it wasn’t going to end there…8-) He goes on to defend the need for service-specific write interfaces with an example.
Without getting into the details of that example since they’re reasonably complex, I certainly agree that one can, without too much trouble, find cases where uniform semantics are more trouble than they’re worth. But so what? Did anybody ever doubt this was the case? I’ve repeatedly stated (and long before too, though I can’t dig up any refs right now) that it was, including mentioning that I’ve had to use non-uniform semantics on occasion.
I think the question David really needs to answer is this; do we need specific write interface semantics like “orderBook”, “hirePerson”, “reserveFlight”, etc..? I don’t think we do; I think POST suffices for all three.
Also, I wonder if Dave would like to augment his architectural description of the SOA style to include an interface constraint, even if it’s just for reads?
After much time and anguish, “application/soap+xml” is finally a done deal; RFC 3902
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.