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
If so, then how is this different than having every service implement
a common “process this document” (aka POST) operation? That’s what uniform
that iTunes is doing a proprietary version of Web services. I don’t think so. He writes;
If, however, they wanted to describe the structure of that information, how would they do it? Theyd probably use XML Schema.
Yep, agreed there. I think RDF would be a better solution, but given they’re
using plain old XML, XML Schema would be the way to go.
And if they wanted to describe the message exchange patterns, the contract for the interactions with the store (e.g., “when the XML document with the order information for a song comes, the response will be the XML document with the song”)?
Hold on. Why would they ever do that? Why would they want to artificially
restrict the type of documents returned from an interaction? That would mean
that if they wanted to insert a step between order submission and and song download,
that they’d have to change the interface and its description? No thanks. I would
prefer that the client determine what to do based on the type of the document that
actually arrives. Let’s keep the perpetually-static stuff in the protocol, and
let everything else happen dynamically.
And if they wanted their service to be integrated with other applications without having to read Apple specifications on how to include the information in HTTP requests and how to read HTTP responses?
I don’t follow. One need only look at the HTTP spec to determine how that’s done.
SOAP buys you nothing in that case, AFAICT. It buys you other things (better
extensibility, richer intermediary model, etc..), but none of those seem relevant
to ITMS at present.
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?
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
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
… 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.
Congratulations to Tim
on his new position at Sun.
In an interview
he gave about the move, he said something interesting that I’d like to comment on.
When asked whether he’d looked into peer-to-peer technologies, he said;
Only trivially. That has some roots of its thinking in the old Linda [parallel programming coordination language] technology that [David] Gelertner did years and years ago, which I thought was wonderful and which I was astounded never changed the world. But I have been working so hard on search and user interface and things like that for the last couple of years that I haven’t had time to go deep on JXTA.
Linda – or something very Linda-like – did change the world;
the World Wide Web.
I’d really love to get Tim’s views on Web services. He’s said a
handful of things on
etc.. , almost all of which suggest that he totally gets the value of the Web
(unsurprisingly). But he’s also said
which have me wondering whether he appreciates the extent of the mistakes
being made with Web services.
BTW, I wonder what’s going to happen on the TAG now that both Tim and
Norm are at Sun, given that the
W3C process document
two members from the same company? Either way, it will be a big loss to the TAG. Bumber.
Update; Tim resigns
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.