Doug Kaye responds.
It seems we did miscommunicate. I like to tweak my terminology on occasion, to try to blur
distinctions for my readers that I believe are artificial, such as that between objects and resources.
It came back to bite me this time it seems. I’ll be more careful in the future.

Doug writes;

I continue to believe that dynamic documents, such as those which evolve during a complex business process, are best communicated through non-REST style interfaces.

Which is weird, because I’d say that is what REST does best. A URI
is just an identifier. I could use one to identify some instance of a business
process, and at any point, anybody with that URI could invoke GET to retrieve
a document which represented the state of the process. As the process
makes progress (in any direction 8-), subsequent GETs will return
different results representing the current state. I’m not sure how else to
handle viewing dynamic processes, other than transferring some mobile
agent pickled with its state, and then prodding the agent for the info,
but I don’t think Doug’s talking about that. Hmm…

If you’re following the TAG discussion
regarding the httpRange-14 issue,
you’re probably aware of the two (at least I think and hope it’s
just two) positions about this; either http URIs without a fragment identifier
can identify anything, or they can identify “documents”, aka “information
resources”, aka “cyc:ConceptualWork”s. I’m unapologetically in the “anything”
camp.

As this debate has flared up every few months in some forum for the past
several years, I thought a bit about some of the implications of my position,
and whether there was anything there that hadn’t yet been said. I came up
with a couple.

First, in general, who’s to say that any string can’t identify any
thing? My name is “Mark”, and that name identifies me; not globally uniquely
of course, but I don’t think anybody would claim that it wasn’t an
identifier. So as an identifier, it would be really nice to be able to
ask a HTTP proxy for a representation of me using that identifier, e.g.

GET Mark HTTP/1.0
Accept: image/jpeg, text/html

The only reason that isn’t possible, of course, is that HTTP accepts
URIs on the request line, not arbitrary words. This is because URIs have more
structure than your typical word such that a machine can extract out all
the information it needs in order to retrieve a representation via late
binding.

So assuming we all agree that “Mark” is an identifier for me, then we
should all expect that the request above would return a representation of
me. Why then, should our model of how this works be any different if I use
“http://www.markbaker.ca” as the identifier for me in that request? My
name is not “Mark#him”.

Second, it appears to me that adding a layer of indirection in the
form of having a URI-with-no-frag identify “ConceptualWork about <subject>”
rather than just having it identify the subject, removes the ability for
state changes to be made. Consider my canonical “Web
services are broken” example of a lightbulb; we have a URI that identifies
the lightbulb, GET returns a representation of it to us, we toggle the
“on/off” part of that representation, and then PUT it back to that same
URI. In that example, there exists a perfectly reasonable expectation on
the part of the client that PUT would change the state of the lightbulb
(assuming the history of representations returned via GET was consistent
with the URI identifying the bulb). Adopting the “http URIs identify
cyc:ConceptualWorks” position would appear to force PUT to mean “write a
new version of the ConceptualWork”, with no way to model actually changing
the state of the lightbulb. Not good!

Note that this example was sort of similar to
Roy’s
POST/robot example
, but using PUT instead of POST. I find PUT superior
to POST for examples like this, because it’s easier for most people to
understand what PUT does. But the principle is the same.

So to sum up, if it walks like a duck, and quacks like a duck, it’s
probably not a ConceptualWork about a duck.

Sean points
to a white paper
he co-authored on “Service Oriented Integration”. Now, the content is almost all RESTfully
delicious, but I can’t get past the terminology. It talks
about the need for very generic, coarse grained interfaces (yah!), document flow, etc..,
but uses the term “Service Oriented” all over the place too. I know it’s technically a very
generic term, but it’s extremely commonly understood to mean application-specific interfaces.
IMO, this takes away from the value of the paper, as it doesn’t provide a sufficient “jolt”
to the reader proficient and/or familiar with what “Service Oriented Architectures” are,
such that they’d recognize the major point the paper is trying to communicate.

But maybe it’s just me.

I was going to write more about services vs. resources
here, but it’s late and I’m tired. Perhaps later this week, once I finish the
DOA 2003 reviews (eight of them, ick!).

I just found this wonderfully written description, by Joseph Reagle,
of the value of both pragmatic and
principled approaches to group work
.

Often there are debates about the means used towards common ends: are we better served by being pragmatic or principled? I think both are useful positions. For example, some individuals might choose to be uncompromising, to stand far out on the edge of the lever. In their singular position they don’t weigh much, but their extremity does increase the torque by reminding us of the principle at stake. Others might devote themselves to the process and institutions of consensus. The fulcrum itself is unwieldy and difficult to move, but if one can shift it, that too can have a profound effect on the ultimate balance.

I’ve always felt this. I’ve experienced a couple of occasions in
my standards work, where a principle needed to be relaxed in order for
concensus to be reached so that the work could make any progress.
I’m happy to disregard principles when (and only when) I feel
that the value of getting something done, however flawed, is higher than
the value contributed by that principle. But, that’s quite often not
the case. My stance against the current “SOA” approach to Web services,
which rejects pretty much all the important principles that made the
Web such a success, is an example of that.

Back in May, I was worried that my prediction that XMethods would list
less than 400 available services
may not come true, as 358 services were listed back then. I just checked the
number now, and it was down to 342. I’m not sure why the dip – I’ll have to ask
Tony – but I’m breathing a little
bit easier. 8-)

I wonder, if Web services are going to be such a big thing, then surely
at some point there’ll have to be millions of them around, right? If so,
what do folks think it will it take to get there (other than tens of thousands
of years 8-)?

Clearly Doug hasn’t been following along on the home game version of “Tech Curmudgeon”! 8-)
He writes;

Mark Baker has thrown up his hands in frustration over the work of WS-Arch. “The sun will set on Web services, as it has on every other attempt to deploy object-specific interfaces on the Internet.” Object-specific, Mark?

Right, object-specific, in contrast to object-generic. That is, rather than each identifiable
thing in the system (service/object/resource/whatever) having an interface specific to its
offered functionality, all things have the same interface. I talk a lot about REST’s uniform
interface here; that’s one example of an object-generic interface.
JavaSpaces is another one.

Or perhaps I didn’t understand his question.

I’ve always considered WS-Routing to be one of the few shining stars
of the WS-* spec family. Conversely, I’ve
said before
that I consider WS-Addressing to be perhaps the biggest waste of time yet
developed. So imagine my surprise when
Edwin notes
this passage
from Microsoft’s WSE 2.0;

One of the changes between WSE 1.0 and WSE 2.0 is the support for WS-Addressing. WS-Addressing largely replaces the capabilities of the WS-Routing specification that was supported in WSE 1.0. Instead of focusing on routing paths, WS-Addressing functionally provides a mechanism for adding To and From headers to a SOAP envelope.

WS-Routing uses URIs for endpoint and intermediary identification, whereas
WS-Addressing exists because apparently URIs were considered deficient as
identifiers. If you buy WS-Addressing’s premise (I don’t, surprise), this
makes sense, sort of. But then you’re missing the value-add of WS-Routing and its
support for SOAP intermediaries. The WSE 2.0 use of WS-Addressing defines a much
less general routing infrastructure, premised upon only ever using gateways (where
messages must terminate) rather than both gateways and proxies as
WS-Routing supports.

While noticing one of the scaling problems with Web services (a topic
worthy of its own blog entry, but I can’t muster the energy),
Dave Orchard suggests
that XML’s “self-describing nature” will save the day.

Producing self-descriptive documents is hard. XML has some tools
that help, in particular XML namespaces, and that it’s markup. But I see
those as akin to having a hammer and nail in your hand as you attempt to
build a house. XML’s “self-descriptive nature”, even if you accept that
“XML” includes namespaces, is only slightly better than ASCII.

I’ve been doing a lot of self-describing data investigation over
the past few weeks, and the last thing I consider important is which
syntax is used. What I’ve found to be most important is that
identifiers be URIs, and not to use an identifier where what it
resolves to is what is really needed.

I unsubscribed from ws-arch today. There comes a point where you have to
throw your hands up, and realize that sometimes very smart people can be very
stupid, and aren’t interested in hearing that they’re wrong. Besides, my new
job is building RESTful services on an extremely large scale (international),
so I no longer have a personal stake in seeing Web services succeed.

To Mike; thanks, you made it bearable. I know you tried, and you’re
a good guy and a fine chair for doing so.

To working group members; it would serve you really well to understand
software architecture better than you do, and to understand why constraints
aren’t necessarily constraints on function, only form.

The sun will set on Web services, as it has on every other
attempt to deploy object-specific interfaces on the Internet. I was
hoping to be the guy who’d help people understand why this would happen,
and in the process, save the industry from wasting a whole lot of time
and money. But I suppose there’s no substitution for learning some lessons
the hard way.

I’ve been meaning to be more involved in this, but it’s been moving
too fast, and I’ve been too busy with other things (like a job).

A comment by Tim Bray in
today’s TAG meeting minutes,
however, prompted me to check back;

over in son-of-RSS-land, we’re converging on using POST for
entry creation/update/deletion for reasons that seem good

My concern with that is that the resulting API would not be RESTful,
and I thought that the objective was that it should be (as the name
RestEchoApi suggests!). It isn’t RESTful, because in the context
of HTTP, tunneling methods over POST – even uniform ones – reduces
visibility.

I added my two cents.