An oldie but a goodie on RESTful service composition.
(link) [del.icio.us/distobj]

A couple of quality posts today on some problems with Web services and agreement on what exactly service orientation is.

Good to see, especially when it comes from those who are largely WS/SOA proponents, rather than, well, me the outsider. 8-)

Dave suggests implementation details are important. As one of those who made the “implementation detail” claim, I’ll state my definition;

An “implementation detail” is an aspect of the design or implementation of a system, which has no effect on the architecture of that system, i.e. does not affect the relationships between components, connectors, and data.

Dave had argued for the use of EPRs instead of URIs based on what I believed to be “implementation details”, including this;

Separating the reference property from the URI may make it easier for service components to evolve. A service component may know nothing about the deployment address of the service from the reference properties. This effectively separates the concerns of identifiers into externally visible and evolvable from the internally visible and evolvable. For example, a dispatcher could evolve the format it uses for reference properties without concern of the URI related software.

to which I responded;

That separation you discuss is an implementation detail, not an aspect of the architecture. Consider Web servers that have a config file which is used to map URIs to code, freeing up the code from having to be bound to any particular URI.

Which is to say that the config file used by the Web server is not a part of the architecture of the operational system being discussed, because it is not exposed to the service consumer (not a data element), nor does it impact connector (transfer) semantics or the relationship between components. It would be a data element of the configuration subsystem architecture of course, but that’s not what we’re talking about.

A couple of weeks ago, Phil Wainewright had a great post on the role of standards. A few people picked up on it, but nobody picked up on the opening sentence (AFAICT);

Does anyone still believe that web services will be published and consumed indiscriminately on the open Internet?

I believe when people set out to build Web services five or so years ago, they were trying to enable just that, yes. But I agree that it hasn’t happened yet, nor will it likely ever with the current approach IMO.

Phil adds;

If standards bodies were supposed to innovate, they’d be called innovation bodies. Standards, by definition, can’t be innovative. This is the trouble with all the work currently being put into the WS-* stack. Talented people are wasting time and resources devising capabilities that will never, ever be used. Only those specs that reflect established, proven practices will successfully become durable standards.

Which, taken with the above, says to me that if we want to enable a world of indiscriminate consumption of remote third party services, we need to do so in a manner similar to other systems which have done just that, like the Web, email, instant messaging, etc… Namely, by using a constrained interface, and embracing (application) protocol dependence.

A good presentation by David Booth which elaborates on what I’ve been saying for some time now; messages should be self-descriptive, and that effectively requires an operation in the message itself (unless you’ll only ever have one operation).

I’ve got a couple of minor nits with the presentation, but nothing of consequence. Nice job, David.

I see no reason to tolerate harbingers of doom unless they are being constructive.

— Roy Fielding to the Atompub WG.

I always wanted a motto. Now I’ve got one. 8-)