Answer me this; is it the objective of the Web services architecture to permit a document (e.g. a purchase order) to be submitted to any service for processing?

If so, then how is this different than having every service implement a common “process this document” (aka POST) operation? That’s what uniform means.

Via Mnot, Aaron’s reverse engineering ITMS.

So let me understand… ITMS is presenting an HTTP/URI based interface intended for use by automata, and not human-controlled browsers? How is such a thing possible?! THE WEB IS FOR HUMANS (isn’t it?)! Head .. about to … explode. 8-)

Steve responds to my response to his article.

One of Mark’s comments was about my discussion around the difficulties of using URIs to represent some types of endpoints such as message queues. I don’t disagree with Mark that you could devise a way to do it, but it’s just that there’s no good standardized way to do it. I mean, if worse came to worst, you could use a URI with the stringified OMG interoperable object reference format (“IOR:” followed by any number of hex digits), especially given that a single IOR can simultaneously represent any number of endpoints, regardless of the complexity of any individual endpoint being represented. But I suspect most people would not want to take that approach.

But there is a standardized way, which I recommended; the http URI. You don’t need any more standardization than that, as an http URI provides sufficient information to enable anybody to grab data from it via GET (aka, it enables the late binding of the identifier to data).

FWIW, I agree that the URI-construction mechanism has its problems, and I try to avoid it when I can, especially where queues are created frequently. I just mentioned it as another option.

Thought for the day; how different would the Web services architecture be, if the Web didn’t exist?

Via Savas, a pointer to a paper by Jeff Schneider titled The World Wide Grid. It includes some incorrect assumptions about the Web that I’d like to address. Luckily, they’re summed up in this statement;

The focus for the web was to describe pages that could be linked together and read by people.

Bzzt. Can this be read by people? Nope.

The same mechanisms used to permit a browser to pull in HTML from any HTML-serving site around the world, can also be used to enable an automaton to pull in any kind of data from anywhere around the world (namely, GET + URIs). You are using data, right? 8-)

Even if you accept that all of these different approaches (Grid, WS, Web) are workable solutions to the over-the-Internet application-to-application integration problem, do you really want to bet against the world’s most successful distributed application?

Patrick and Stefan pick up on my “Linda did win” meme

Obviously the Web isn’t Linda; clearly, there are important differences. But IMO, there are more important similarities. Both Stefan and Patrick claim, in effect, that the way the Web is used today doesn’t leverage those similarities. While I agree that we haven’t yet taken full advantage of it, the most common use of the Web today is for browsing in a Web browser, and I see that as very similar to just rd()-ing (reading) a space, or at least far more similiar to the Web than a Web services approach of invoking getStockQuote or getPurchaseOrder.

How different from the human-centric Web is a tuple space returning HTML on a rd()?

… you’d have to negotiate much of the hard stuff that TCP accomplishes (e.g. flow control), for each different party you wanted to interact with.

When building an Internet scale machine-to-machine stack, your objective is to embue it with sufficient information to enable ad-hoc integration between parties which implement it. Agreeing on only a “messaging layer” while not agreeing on an interface, prevents two parties from integrating in an ad-hoc manner, just as agreeing on IP alone (or IP plus part of the TCP spec) is insufficient to permit an ad-hoc TCP connection to be established.

Jim writes, regarding a diagram by Savas;

It shows that managing virtualised resources across organisations isn’t scalable, whereas composition of services is. Why the difference in terms of scalability? In the service-oriented view, services can manage whatever backend resources they have for themselves, therefore the complexity of the application driving the services increases linearly with the number of services. In the resource-oriented view, the consuming application must deal with each resource directly and so complexity increases as the sum of a multiple (the number of resources) of each service.

Aside; I think Jim’s using the WS-RF notion of “resource”, which is cool, since it jives so closely with the Web’s notion of one (stateful resource, stateless interaction).

I think the scalability claim above is only correct if you ignore a whole class of useful resources; containers which contain other resources. So I could layout a resource centric view of the network in that diagram to look exactly like the service centric view Savas draws. For example, I might define a container called “the aggregate log ‘file’ of all devices in this building”, and this might be dynamically constructed in basically the same way that aggregate RSS feeds are constructed. And, of course, it would be given a http URI so that I could snarf data from it. Each log entry could also provide the URI of the more granular “device” that it came from so that I, or an automata, could visit there to find its current status.