Web Things, by Mark Baker

A flurry of “It’s not REST vs. SOAP” comments in response to Bob McMillan’s latest REST article.

I helped Bob with that story, and I know I’m always careful to frame the argument as “REST vs. Web services” rather than “REST vs. SOAP”, so I apologize for not communicating that point to Bob well enough. Heck, I spent all that time on the XML Protocol WG for a reason, you know; to make sure SOAP became the best darned PEP replacement it could be.

But I suppose there’s an inevitability to this confusion, since the word “SOAP” brings along with it an implied use, which is contrary to REST. Unfortunate, but whad’ya gonna do?

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.

Like many other discussions (though perhaps much faster than most 8-), Simon gets to the heart of the matter;

[…] but at that level so is SOAP, its always HTTP POSTs[…]

While trying not to sound too much like a broken record, there is just one “level” here, the application layer; HTTP methods are application methods. POST is as much an application method as doSearch(). When you use HTTP/REST, you as a developer aren’t normally defining any methods, you’re just filling in the arguments to the methods that HTTP provides. That’s what “interface” in the uniform interface constraint is referring to; the API.

Simon Fell says that he has trouble understanding some of my arguments, in particular this one where I attempt to outline the value of pipe-and-filter style composition over a choreographed solution. Let me elaborate here then.

It’s long been recognized that composition of components is simpler and more tractable when those components share an interface, if only because you can reuse glue code. For example, the code written to late-bind the Unix commands “ls” and “more” into “ls | more”, is split between the stdout-using code of “ls”, the stdin-using code of “more”, and the binding code in the shell that processes “|”. All of that code is reusable in more contexts than piping “ls” into “more”.

My examples were meant to show the strong similarities between Unix style composition, and REST style composition. REST, by itself, supports two styles that I’m familiar with, which I described there; composition-by-URI, and intermediary routing. The latter is more powerful and flexible, but the former easier to use, though at the cost of not being standardized (not that it should …).

From what I can tell, the Web services answer for composition lies with choreography (and some in that thread appear to agree with that). I believe this approach will ultimately fail, and that routing (ala WS-Routing, PEP, Idokorro, KnowNow) will prevail.

James Strachan asks that if the method doesn’t go in the SOAP envelope, could it go in the URI or an HTTP header? My answer would be “No”, that in order to gain the benefits of REST, the only method you need should be the one in the HTTP request line, such as GET/PUT/POST. That’s not to say more methods can’t be defined, only that they should all have uniform semantics, and that when using HTTP, they should be HTTP methods.

Does that explain why HTTP is an application protocol, and not a transport protocol?

More tail-chasing going on over at the W3C with the chartering of the Web Services Choreography WG. I’m really disappointed that Tim didn’t take this opportunity to speak his mind about the mistakes being made with Web services, especially considering that this working group exists to replace the hypermedia application model, which is pretty darned fundamental to Web architecture.

I guess he knows what he’s doing though. Perhaps he feels he can contain Web services, and prevent them from preventing him from leading the Web to its full potential. I did think that the initial move to accept them into the W3C was an excellent one, as there, they may actually be fixed enough to earn the right to call themselves Web services. Unfortunately, nobody seems to be officially assigned to the task to doing just that, though Hugo and David try to keep things in check, what most people know to be Web services (i.e. putting the method name in the SOAP envelope) is a fundamentally broken style for the Internet, which is a big issue for them to tackle, especially given the mostly neutral positions they’re expected to hold as team contacts (not officially, but in practice it’s hard for them to hold strong opinions). That’s why I’ve been doing it.

Congratulations to the XML Protocol WG. The end is near! 8-)

• SOAP 1.2, Part 0: Primer
• SOAP 1.2, Part 1: Messaging Framework
• SOAP 1.2, Part 2: Adjuncts

Sam thinks good thoughts about how to use RESTful SOAP as a Blogger API. Nice. But there’s an important issue with SOAP and PUT. Unlike POST, PUT means “store”, and as such its processing model doesn’t provide a hook into which an additional processing model (i.e. SOAP) can be introduced. An intermediary or message processor seeing a PUT request with a SOAP body, would be correct to treat the body as opaque data, and wouldn’t be required to follow the SOAP processing model.

This is why I’ve talked about the need for a new HTTP method I’m currently calling “SET”, whose semantics will be “process and store”, and will therefore allow for an additional processing model to be inserted.

Jorgen Thelin points to a John McDowall blog about Architecture by Intent in which John talks about how Linux kernel upgrades requiring hardware upgrades is a bug requiring more architectural emphasis to fix.

When I first read Jorgen’s blog, I assumed that John was talking about Web services; I have a one track mind, I know. But I’ve tried to ask Web services proponents what the architectural constraints of Web services are, and even made a good faith effort to write them down (as compared to REST), only to have the attempt called a blatant troll.

So somebody please tell me; what are the architectural constraints of Web services? If nobody knows, then aren’t Web services “Architecture by Accident”? But if they are known, let’s sit down and figure out what properties these constraints induce so that we can tell if they can do what people want them to do. Yes, that’s a challenge.

Dave Winer says;

SOAP and XML-RPC were started to make it easy to build applications that viewed the Internet as if it were a LAN.

which is 100% true, and at the same time, 100% the wrong thing to do. The Internet is not a LAN. On a LAN, there’s one administrative/trust domain, and on the Internet there’s, well, a whole lot more than one. Computing in those two domains – LAN and Internet – is not the same thing, and therefore requires different solutions (though arguably it could be said that the LAN is a special case of the Internet, where number of trust domains = 1, so what works for the Internet could also work on a LAN – but the converse obviously doesn’t hold).

And for the record Dave, I write software, thank you very much (and so does Paul). Not as much as I used to, but I still do, and still enjoy it (especially now that I’ve switched to Python from Java). It’s all too easy to put down a detractor rather than trying to understand what they have to say, I suppose.