Web Things, by Mark Baker

Mark talks about how he implemented his Dive Into Mark Mobile Edition, and in doing so talks about XHTML Basic, which I co-edited. He’s mostly correct, but there are some points I’d like to respond to.

The “link” element has a extremely low conformance profile; all it means to support it is that you don’t fault when you discover it. Supporting “link” doesn’t mean you have to support CSS.

As for the list of elements which XHTML Basic left out, “b”, “i”, “center”, and “font” aren’t there because XHTML 1.0 – from which XHTML Basic builds – removed them in the “presentation belongs in stylesheets” blitz of 1999. Nested tables were indeed removed based on extensive feedback and wide industry support for doing so, due to the memory consumed during their processing. Though I don’t know for sure, I’m quite confident that AvantGo does not support arbitrarily complex nested tables, which suggests that some form of subset would need to be defined should their solution ever be opened up anyhow.

It is not true that XHTML Basic has to use the application/xhtml+xml media type. In many cases it is appropriate to use “text/html”, though the W3C apparently disagrees with me there; their “XHTML Media Types” note says that it “SHOULD NOT” be used. Whatever. I doubt any text/html processor would have trouble with XHTML Basic, just don’t expect it to be treated as XML or XHTML.

Mark’s conclusion, “As I said, XHTML Basic has no basis in reality. Ignore it.”, for North Americans, probably isn’t too far from the truth. In much of Asia and parts of Europe though, it’s important, and its importance will probably be spreading.

Not that I really care that much. The reason I contributed to its development was because of Sun’s objective that WAP should use commodity protocols rather than wireless specific ones, and we did that. Though WAP 2.0 extended XHTML Basic, I’m confident that in time, those extensions will be ignored and HTML/XHTML will remain in some form, likely richer than XHTML Basic. I look forward to seeing that language documented after the fact; XHTML Basic 3.2 anyone? 8-)

Sam comments on my Infopath feedback;

I’m pleased to see such a ringing endorsement by Mark Baker of XML Web Services.

Well hang on there. That isn’t “XML Web services”. Or if this is the new benchmark of a Web services architecture (has that been decided and nobody told me? 8-), then what the heck is this, because it sure doesn’t describe the architecture of Infopath – or at least not the configuration of Infopath I was praising (and probably extrapolating upon a little too). Perhaps with a handful more constraints, the architectural style described in that document will resemble the one in Infopath. But that doesn’t in any way mean that the WSA document is a good description of Infopath, any more than the null style is a useful description of all architectural styles.

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 responds to my comments on a presentation he gave last week.

Re my comment that architectural styles are pattern languages, not patterns, I can only point to Roy’s dissertation on this, where he suggests the association between an Alexendar “pattern language” and an “architectural style”, by suggesting indirectly that both are a system of patterns that constrain the form of the resultant system. “Stateless”, “Uniform interface”, “Layered Client Server”, etc.. are constraints, and when coordinated together, form the REST architectural style.

Re the stateful/stateless point (both parts), I don’t see how whether the targetted endpoint does additional dispatch or not, matters to this issue, unless of course that dispatch operation uses some state (which is not required of an OO style, AFAICT). You suggest that all object oriented styles are stateful, yet REST is stateless, and it’s object oriented in that messages are targetted at identifiable objects.

Re SQL, and to add to my last blog, it’s true that a SQL row may be a resource, but it’s not the case that all resources (as defined in 2396) can be manipulated via SQL.

Re POST, perhaps we miscommunicated, but by “partial update” I thought you meant that the meaning of POST permitted the updating of partial state changes to be communicated to the client, which it doesn’t. It is true that the effect of a POST may be a “partial update” of the state of the resource, but the issue is that a client will not know that. All a successful response to a POST can mean to a client is “thanks, I accept this data”. So I’d say that your comparison to SQL UPDATE is inaccurate, because after a successful UPDATE, the client knows the state of some part of some table. UPDATE is more like PUT for this reason, whose successful invocation informs that client that the state of the resource is what they asked for it to be.

Jorgen writes;

And there I was thinking this statement would be an olive branch for you, Mark ;-)

Heh, yah, I appreciated the attempt, but I felt it was pretty early to propose a synergy existed before you really understood REST. Oh, and please don’t take that the wrong way 8-); understanding REST isn’t a matter of smarts, it’s just a matter of recognizing what it is (or more specifically, what an application protocol is, at least in my experience as an ex-CORBA lover). I’m confident that you’ll understand soon enough because of your broad experience, and your eagerness to learn.

I still don’t see any real conflict – you can still have requests returning XML data, the only question would be whether the request data must be in XML format or whether it can be encoded into a URL/URI.

Depends what you mean by “request data”. A typical Web services centric solution, because its normally early bound, requires that the request data include a method name. REST, because it’s late bound, requires only that you provide an identifier. From a cost-of-coordination perspective, the latter is vastly superior.

You can use Web Services standards and do pure REST. Equally you can use Web Services standards and _not_ do REST.

Of course. As I said before, I consider this a bug, not a feature.

Roy defined the null architectural style which could be said to be another style in which you can do REST or not. The way it does this is by being entirely devoid of constraints, which has the “disadvantage” (cough 8-) of also being entirely devoid of any desirable properties.

I’m not suggesting that you believe that the null style is a useful thing, but I’ve heard from a lot of Web services folks who feel that architectural constraints are a bad thing. From a software architecture point of view, this is madness. Have they never heard of entropy? 8-/

Fundamentally, cacheability IS a big factor as the client implicitly caches a local copy of the resource data at least for a time.

Sure, it is important, but as a side effect of the client maintaining the state (i.e. the interaction being stateless). If the style were said to “revolve around” anything, this (statelessness) could be one of the big things, sure.

I am not sure Roy Fielding’s dissertation would agree with your assertions here, Mark – see bottom of page 14:

Roy’s comment about combining styles doesn’t suggest how styles are combined. As I see it, if you’re using an architectural style with constraints A, B, and C which yield desirable properties X and Y, and then you want to add property Z which is known to be obtained via constraints D and E, then in order to get Z without giving up X and Y, your new style needs to have constraints A, B, C, D, and E.

FWIW, this model of constraints and properties has been around for some time, since at least Perry and Wolf’s “Foundations for the study of software architecture” (using that terminology, anyhow). Some of the folks you quote, like Shaw, Garlan, Kazman, etc.. have accepted this model. I don’t see how what I’m saying is controversial in this regard.

I’m glad to hear you’re giving the presentation again, and I look forward to following up on this with you.

Jorgen asks Is REST the SQL of the Internet?.

There are definitely some similarities between REST’s uniform interface and the SQL language, most importantly that they are both coordination languages, a priori deployed application interfaces that defer component binding (i.e. late binding), which are ideal for deployment on a network between untrusted parties (hence the use of the word “coordination”). But “Resource oriented”, a term that Jorgen defines, doesn’t apply to SQL since its coordination semantics are not specific to “resources” as defined in RFC 2396 (i.e. they’re not uniform), just as it doesn’t apply to other coordination languages like Linda, SMTP, or IMAP. If I knew more about what he was trying to achieve with such a categorization, I might be able to recommend a better name.

Apparently OASIS has decided to tackle reliable messaging, with help from the usual non-IBM/MS Web services suspects.

I think “reliable messaging” is a huge waste of time. It’s akin to saying that the network is unreliable, so let’s just make a reliable network on top (which is different than “reliable data stream” ala TCP). Sorry, it just doesn’t work that way. “reliable network” is an oxymoron, for any number of reliability layers you might try to build on top.

As with most problems over the Internet, reliability is a coordination problem. That is, how do two or more independant pieces of software distributed on an unreliable network, coordinate to achieve some goal in a reliable manner (such that both know that the goal has been achieved or failed, etc..)? Unfortunately, you can’t coordinate “reliability” in a vacuum, like the typical reliable messaging approach of store/forward/timeout; you have to look at what task is being coordinated in the first place, and then figure out how to augment your coordination semantics such that the necessary degree of reliability can be achieved. In the context of the Web, that means using the uniform coordination semantics that are made available through HTTP.

Simple example. I want to turn on a lightbulb, and do it reliably such that I know if my attempt succeeded or not. I would use PUT. If I got back a 2xx, I would know the lightbulb was on. If I didn’t get back a response at all – say if the connection died after the request was sent – then I don’t know. But if I needed to know, I could do a GET. Perfectly reliable, no reliable messaging solution in sight.

That example doesn’t work for everything of course, because PUT is idempotent and not all operations you might want to perform are idempotent. POST is different, but the requirements on it are different too, since if you use POST, you accept that you won’t know the state of the resource after a successful submission (getting deeper into that is a topic too large for a blog, sorry).

Anyhow, I acknowledge that some work needs to be done to HTTP to help with reliability (as Paul describes). But that is in no way “reliable messaging”.

Bob DuCharme gets back to basics about RDF, and in doing so clearly hilights the value of partial understanding. Notice how the integration problem he undertakes scales linearly with the number of documents, rather than proportionally (O(N)) as it would if his code had to have full knowledge of all those schemas. By using RDF’s data model (note that each file uses a different serialization of the same basic RDF triples), this scaling problem is averted.

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.

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.