Web Things, by Mark Baker

It’s good to see Bill Gurley has restarted his “Above The Crowd” newsletter. His latest is “Software in a box”, where he talks about a topic that I’m quite familiar with; we shipped the first version of our software at Idokorro in a Cobalt Qube for some of the reasons he mentioned; ease of installation, manageability, etc..

One important reason that he didn’t list though, is integration. Typically, integration with third party software is done via proprietary APIs. If you put your software into its own (black) box, then the only interfaces you have for integration purposes are commodity application protocols.

Jorgen points to a presentation he’s giving at an OMG Workshop comparing Service Oriented, Resource Oriented, and Object Oriented architectural styles. This is somewhat similar to my REST Compared presentation, though mine was done at a lower level.

I’ll jot down some comments here as I read it.

Slide 10, “In other words, architecture styles are design patterns for the structure and interconnection within and between software systems.”. Sort of. Architectural styles are pattern *languages*, not just patterns.

Slide 12, “Two main types of distributed software systems”. This distinction seems quite arbitrary to me, and a superficial distinction at best.

Slide 13, Request/Response systems. Here, an association is asserted between request/response and RPC. I consider those entirely orthogonal issues. I know RPC systems which aren’t request/response (e.g. Orbix+Isis), and I know of request/response system which aren’t RPC (HTTP). Perhaps it’s just a terminology issue, not sure.

Slide 16, Object Oriented 1. “Communications are implicitly stateful”; I don’t think that’s the case. Some are, like EJB/CORBA, but some aren’t, like MTS/COM (or whatever it’s called now; Biztalk?)

Slide 19, Resource Oriented 1. I wouldn’t include SQL here, since it’s not resource centric. If you wanted to create a “data oriented” super category, then you might include it and resource-oriented, and file-oriented (FTP), etc.. in there. It also says that resources have state and identity, as if to suggest that they don’t have behaviour like objects. That’s not the case, they do have behaviour.

Slide 21, Resource Oriented 3. POST isn’t for “partial updates”, it’s for triggering the “behaviour” part of identity/state/behaviour.

Slide 22, Resource Oriented 4. “Resource Oriented” is not an architectural style. REST is the only resource oriented architectural style I know about, though any REST extension would also be so. I suspect that any resource oriented architectural style will be either REST, or a REST extension like the Semantic Web, or ALIN. See also slide 24.

Slide 23, Service Oriented 1. “Communications are implicitly stateless (all requests are sent to the same service endpoint)”. That reason doesn’t have anything to do with stateful/statelessness, AFAIK. If it was meant that the message is sent to the same in-memory object, then that would be implicitly *stateful*, as knowing what “the same” is requires a memory between invocations on the server, and that memory is state. From the discussions I’ve had with Web services proponents, they say that service oriented architectures are state neutral; they can be stateful or stateless.

Slide 28, Web Services vs. REST 1. “There is no real conflict between the general idea of Web services and the REST approach”; excuse me?! 8-O There is a fundamental and inescapable conflict between the two. They cannot peacefully co-exist. That Web service definition you quoted is completely incompatible with the REST architectural style. End of story.

Slide 29, Web Services vs.REST 2. “The total set of Web services specifications provide a superset of the REST approach”. Absolutely true. Yet by doing this – creating a superset – most of REST’s important architectural constraints are obliterated. A superset (in this sense of the word) of REST is not REST. Architectural styles combine via constraint intersection, not union.

Slide 32, “Choosing Between Architectural Styles”. Resource oriented styles don’t revolve around cacheability. That’s a small part of the advantages of the style. There is nothing that is read-only/mostly/idempotent specific about its style. It’s simply optimized for coarse grained data transfer, like document based service oriented styles, only more loosely coupled via late binding. Anyhow, even if you disagree, you should at the very least try to defend that position; there’s nothing in there that does that.

Slide 33, “Combining Architectural Styles”. See slide 29 comment above. You cannot combine styles in this way, and hope to preserve the constraints that are giving you your desired properties … which brings me to a general point about this presentation; despite the very a propos snippets up front from the likes of Fowler, Shaw, Kazman, etc.., very little of that experience appeared to be reused in the rest of the presentation. For example, I would have expected the presentation to talk about the architectural properties of each of the styles presented, and extract from that the domain of applicability.

Slide 34, “How to avoid the Choice of Style”. Yikes. As Neil Peart wrote, “If you choose not to decide, you still have made a choice”. This is a recipe for failure. Even SCOUT2 assumes an architectural style, though a mostly constraint-less one (which is a bug, not a feature).

In general, I had high hopes for this, but with all due respect to Jorgen, it needs a lot more work. Not only does it misrepresent the value of the approaches represented without backing up its claims, but it evaluates them in a context very different from the one accurately(!) described in the first few pages by the gurus of the field of software architecture.

Here’s a telling statement for you, from a BEA press release;

Recognizing that every integration project requires development, and every development project requires integration

This is absolutely wrong; every integration project does not require development.

This afternoon I subscribed to (i.e. integrated into my existing aggregate feed) a few more weblogs, and did it without any new coding. This is because I already use some software which can snarf RSS feeds for me; I just had to identify the feeds for it.

Of course, if you assume, as BEA does, that each new service has a different interface than other services, then obviously new development is going to be required, just as if each RSS feed had its own interface. But that need not be the case, as I’ve demonstrated.

I know, I’m not being entirely fair; even if some new Web resource used the HTTP interface, but used a data format the client wasn’t familiar with, then more coding would need to be done. Which is why I’m so keen on RDF.

Jorgen Thelin references Bill de h&#211ra’s blog on session state.

Unsurprisingly, it appears there’s some serious misconceptions about state going on here. As Ken Arnold said, “State is Hell”, which jives with my experiences.

Bill writes;

One issue with the REST hypertext model is its view on managing state. REST constrains that state reside on the client, However the real web works precisely backwards to this: all interesting state is kept on the server, as sessions.

That second sentence is incorrect. Even cookie based Web apps still keep most application state on the client. If they didn’t, you wouldn’t be downloading web pages. The only architectural style I know of that keeps all state server-side is the Remote Session style, ala VNC.

And when exprienced enterprise practitioners like Martin Fowler say that state belongs on the server, it makes you wonder whether REST has anything to offer here.

I’d have to see a reference. I’d be very surprised if Martin said this in the way you’re implying he meant.

Then Jorgen writes;

[…] my hunch is that REST can’t provide a clean solution to the general category of “conversation” style applications (involving server-controlled request state transitions) which is the more usual meaning of the concept of “session state”.

I’m a fuzzy on what Jorgen means by “server-controlled request state transitions”, but I know that REST can handle what’s commonly called “session state” quite well. Moreover, even HTTP can handle it, without any extensions or use of cookies. All that’s needed is a client side implementation which manages state better. For example, rather than implementing “shopping carts” as a server-side container resource for shopping items, implement it as a generic client-side container, where the shopping/checking behaviour is a result of POSTing a representation of that client-side container to a checkout processor on the server. This generic client-side container would be useful for holding any application state, and therefore anything you’d want to do as a session.

There’s all kinds of pros and cons to this of course, as there is with any solution developed within the bounds of any architectural style, but REST can do it without batting an eyelash.

Edwin Khodabakchian reports on an Adam Bosworth presention entitled The Next Inflection Point.

Adam’s an extremely bright guy, and I’m fully expecting him to have a “REST epiphany” ahead of most others due to both the depth and bredth of his experiences. But while this is an extremely interesting presentation, there are some claims that just don’t synch up with the current approach taken with Web services. In particular, there’s this quote which Edwin pointed out;

We will look back in wonder and ask how we ever survived in the current anarchy where information did not flow as seamlessly and as metered and managed a manner between programs as electricity flows between devices today.

Whether or not you agree that Web services are the next big thing, I would expect that most people would see the problems in this statement; data flow with Web services is anything but seamless.

“Seamless data flow” derives from a data flow architectural style in which components expose a common (no, not necessarily uniform 8-) interface. The example I’ve used before is pipe-and-filter, ala Unix, with stdout/stdin. Non-common (i.e. component-specific) interfaces are notoriously difficult to compose, and therefore anything but seamless, because new glue code has to be written for each set of components that need to be composed (the old integration-complexity argument, O(N^2) or O(NlogN) for Web services vs. O(N) for the Web).

So I’m all for seamless data flow, but Web services simply don’t have it.

Simon responds to my comment about ERH’s message;

Does that alienate people? Yes! It should. I’d love to get the Web Services folks to rethink their foundations. Failing that, making clear that there are serious points of friction seems like the best course of action – and being civil has little to contribute to that. Forking is not a risk here – it’s an opportunity.

We’re in complete agreement about that. Where we may differ, is about the timing; I think the time for alienation has passed. I’ve personally been doing it for over three years now, and have alienated my fair share of bright and well respected people (which has come back to haunt me during my search for work, sigh .. but such is the price of grokking this stuff). I believe the time is right – or at least fast approaching – to take advantage of the increasing frustration being felt by some Web services developers who have realized that there may be something to this other way of doing things that they’ve heard about.

But, I could be wrong, which would be fine by me; it’s a lot less work to alienate. 8-)

Clemens Vasters writes;

I am sorry to say that, but if today you still believe and insist that XML is just another data format, the train may already have left the station for you.

Well, then I guess my train is long gone. Ouch. Sorry Clemens, but XML is just a data format. Now, good data formats like XML are nothing to sneeze at, and I’m glad we have it, just like I’m glad we have/had ASCII. But for heaven’s sake, it’s just syntax, a context free grammar.

He also stated;

One of the core messages of my talk is that the XML InfoSet is the focus of integration.

IMO, this is like saying C structs are the focus of integration. Ok, so you and I agree on what one is, and perhaps even how its represented. Now what? How do we integrate? We can’t, at least with just that shared knowledge. If we also shared a model for how to identify, exchange, and manipulate them, then that could form a focus for integration. Which is, of course, akin to what REST tries to do around a more general abstraction called a resource.

ERH writes (grr, no permalinks);

It’s interesting that the Web Services community has managed to alienate three different communities for three different reasons that all derive from not understanding or accepting the basic principles of the technologies they’re building on. They’re either geniuses or idiots. My money’s on idiots, but time will tell.

He’s certainly right in the first part, that these groups have been alienated; “XML” because of the subsetting and arguably the suitability for the task, “Security” because of tunneling, and “Web/HTTP” because it has nothing to do with how the Web works and generated its value in the first place.

But the “idiots” comment is totally out of line. People have suggested in the past that I’ve suggested they are idiots during my evangelizing of a REST based approach to Web services, which really hurts, though it’s certainly understandable; nobody likes to be told that they don’t understand something. But that’s all that’s going on here; they don’t currently understand. It’s absolutely not a statement about anybody’s capacity, or lack thereof, to learn.

I also wouldn’t call anybody an idiot who was proceeding based on their best current understanding of how distributed systems are built, when that understanding is built from years of hard-learned experience. Unfortunately, practically every Web services proponent I know, gathered their experience in a LAN environment, which is a very different place than the Internet, requiring very different solutions. I’d just call them people who need to broaden their horizons.

So please folks, try to keep it civil. Comments such as this one only serve to alienate, which is the last thing we need.

Scott Lawrence joins the ranks of HTTP gurus looking for work. If you need somebody who understands HTTP (not sure if he groks REST though), you couldn’t do much better than Scott.

I just sent this message (with this followup) to the Web Services Description WG to try and get first class support for application protocols (rather than requiring that they be treated as transport protocols) into WSDL. Let’s see how that goes.