Over here. I’ve commented on it.

Jeff asked me to have a look at his
attempt to quantify the concept of “coupling”
from a REST perspective, which I’m happy to do.

I like what I read there quite a bit, in particular the emphasis on an
aspect of large scale systems that I rarely see mentioned; the role of
intermediary introduction at runtime. Jeff writes;

In addition, a fundamental belief that I hold is that ‘intermediaries’, if introduce-able at runtime, have the potential of bringing a coupling index to an unprecedented low level. This concept is conveyed via ‘Intermediary Decoupling’; where-by, other coupling concerns are mitigated by the use of one or more ‘intermediaries’.

A huge +1 from me on that. Roy Fielding describes a set of properties called
which I believe encompasses Jeff’s intermediary concept, though I’m unclear exactly
which sub-property it would refer to; I still have trouble recognizing some of those
properties as distinct from the others.

I also like the mention of “Standards Coupling”, as it gives additional weight to
reusing existing standardized solutions (HTTP, URIs), and de-emphasizes “reinventing the
wheel” approaches (ahem 8-).

In general, I think most of the value in trying to build a metric is in going
through the exercise. The “user weight” factor is much more dynamic than it appears
too, or else needs to accomodate the requirements of the context into which a
system will be deployed. For example, a system being deployed behind the firewall of
an enterprise doesn’t need the same degree of loose coupling that a system being
deployed outside a firewall does. That’s just one type of “context” of course,
though a pretty darned important one.

James Strachan responds to my
SDO comments
suggesting I missed the point. I don’t think I did. Perhaps James missed the
point of my comments. 8-)

He writes;

To help set Mark straight; Servlets are a Java API for implementing HTTP operations. (Incidentally Servlets don’t have a client side – for that you need to either use the URL class or the commons-httpclient library). So Servlets take care of the server-side part of HTTP protocol for you. To use REST speak, Servlets implement the server side of the transfer part of REST.

HttpServlets do expose a client side API, they just do it in a
language neutral way via the HTTP protocol. I could have also compared SDO
to java.net or HttpClient I suppose, but my argument would have been the same.

SDO on the other hand is a generic Java API for any arbitrary typesafe blob of state. It says nothing of how you fetch the state, where it comes from, what transfer/marshalling mechanism etc. The state could come from anywhere; from parsing any XML document, calling some RESTful service, a web service, an RMI call, an EJB / JDO / JDBC / JNDI / JMX query etc.

Yes, true, just as a RESTful service could front for an EJB, JDO, JDBC, JNDI, JMX query etc.

When I first reviewed it, I looked for a “smoking gun”; that thing that would
stand out as evidence that the authors hadn’t studied the Web in sufficient
detail. I didn’t see any at the time, but after having a second look I’d say
it’s the use of XPath; SDO should have used URIs (or perhaps both) as the means
of relating objects. Perhaps that might help you see where I’m coming from with
my objections, James.

Thanks for the feed/pushback.

Update: James responds again.
I think his last paragraph is all I really need to comment on;

Incidentally, the interesting thing about SDO is that the navigation mechanism is pluggable. So Mark, an SDO implementation could use URIs (or XPointer, or XQuery etc) to navigate through the data graph.

Yes, understood, but that misses the point of the Web. URIs aren’t just another
identification mechanism, they are the most general identification mechanism,
enabling other mechanisms to be defined in its terms (e.g. FTP file names engulfed via the
ftp URI scheme, email addresses engulfed via mailto: etc..).

Sure, the Web can be treated as just another system, but as soon as you do that,
any attempt to build a general model that includes it ends up being an attempt to
reinvent it, because that’s what the Web is; the system of all systems.

Stefan Tilkov thoughtfully responded
to my “Building the Web with Web services” blog. Here are some of his comments.

In response to my assertion that documents/state don’t ask anything of anyone, he writes;

Er … well, I think I can see the point, but I can’t really make sense of the examples. So, a purchase order isn’t asking anything from anyone? That can’t be true – so obviously, these are counter examples – a purchase order is asking something. Looking at the paragraph, even for some length of time, I have problems finding out what exactly Mark is getting at – I fail to see the similarity between a pure piece of data like current time and a very concrete, business level document like purchase order. Arguably, it’s just not phrased very clearly, or maybe it’s because I’m not a native English speaker.

A purchase order isn’t asking anything of anyone; it’s just capturing the state of
some order. It can be used to ask something of somebody. For example, I could give
it to a skywriter, and they could write the XML out in smoke overhead. Or I could give
it to an archiving service which promises to keep a copy around for some period of time.
Or, I could give it to a purchasing department with the intent that they fulfill the
order. But all those actions are where I’m asking somebody to do something. What would
you do if you found a paper purchase order lying in the street? Do you know the intent
of its author? No.

He also added this;

While Mark obviously was thinking of content negotiation, support for Expired headers and so on, he doesn’t talk about it at all. How is anybody supposed to make sense of that?

I quite intentionally (though I slipped some in at the last minute, sigh) tried to avoid mentioning Web
terms where I could, and just talk about the general approach. I did this because in my experience, once
you start using Web terms, people automatically import their preconceived views of the Web … which
is what I’m trying to fix.

And then this;

OK, I’m a bit puzzled by now, but surely things are going to be clarified in the next few sections. (Seriously, that’s what I thought when I first read the article). Imagine my surprise when I saw that the next paragraph’s title is Conclusions:

Well, that’s all there is! 8-) The intent of the essay was to describe how the Web relates to
document style Web services; that if you add identification of the things whose state is
represented by those documents, make semantics uniform and explicit on the wire in the form of
an application protocol, and dereferencing of identifiers to request a document, that you’ve
got the Web.

Thanks for the constructive comments, Stefan. I know how easy it is to get
all kneejerky on this. It just seems that the industry is SO close to
finally understanding the Web, that I feel an obligation to jump up and down and
yell “Yo, over here, we’ve already got one of those!”.

Service Data Objects. Oh my.

Here’s some snippets from a

The core SDO specification provides the base APIs that are applicable to all types of data sources

That’s the

The SDO architecture is based upon the concept of disconnected data graphs. Under the disconnected data graphs pattern, a client retrieves a data graph (i.e., a collection of tree-structured or graph-structured data) from a data source, mutates the data graph, and can then apply the data graph changes back to the data source. Most commonly, the update is performed with optimistic concurrency semantics, which means that if any of the underlying data was changed before the client applies the changes, the update is rejected and the application must take corrective action. Optimistic concurrency semantics is a natural semantic that serves most business applications well.

“Disconnected data graphs”? You mean like the Web? 8-). And optimistic concurrency?
Who knew?.

Ok, come on now, this is just getting silly. A Java API for all this stuff
is nice, but we’ve got Servlets,
and it’s not nearly as complex as SDO. Compare and contrast
(grr, no direct URI) to
the former is just missing the equivalent of POST (which would make it useful for
operating on more than just data), but consider that doGet/GET on a servlet is equivalent
to requesting that the state of a DataObject be serialized via Java serialization.

What am I missing? Why can nobody see this?

Via David Forslund,
a pointer to a set of workflow patterns.

Good stuff. I’ve been contemplating updating my
Hypermedia Workflow
paper, and this would be a good base from which to restructure it.

I also just stumbled across a paper entitled
“Workflow Description for Open Hypermedia Systems”
which sounded intriguing, but was I ever disappointed to read it; it just talks about
Web services and WSFL. It seems academia is making the same mistakes as industry. 8-(

On my O’Reilly weblog.
If this doesn’t convince you, I don’t know what will.

Norm lists the countries he’s visited.

I’ve wanted to put together a similar list of my own for a little while,
since I stumbled upon a
(wow!) put together by
Paul Cotton‘s daughter
Cecilia earlier this year.

Here’s mine.
That’s 22 I’ve slept in, and 26 I’ve been too. Not too bad. But I really
need to spend more time outside of Europe and Scandanavia.

Tim relays
some news from Jean Paoli, that in addition to releasing the schemas for the Office formats,
documentation will be released too. He writes;

In general, I think that this kind of tech doc is an order of magnitude more important than schemas,[…]

Big +1

Until last week, the SOAP document/literal examples I’d seen differed
from the rpc/encoded ones only by the encoding. Then I spotted
this example (in section 5.1 – sorry, no URI) in the
WSDL 2.0 Primer;

<?xml version='1.0' ?>
<env:Envelope xmlns:env="http://www.w3.org/2003/05/soap-envelope">
	<customerName>Kevin Liu</customerName>
	<comments>the customer will be arriving late in the evening</comments>

Ignoring the problem that there’s not a single child element of env:Body,
this is, from a Web architecture POV, quite encouraging; we have a SOAP
envelope encapsulating state. Very RESTful (at least the part of the
architecture that is visible in that example).

But if you know where (how?) to look, the Web is nearby. The key is to
realize, once you’re dealing in state, that the obvious next question is,
“The state of what?”