Steve’s next article for his “Towards Integration” column is titled
“Web Services Notifications”.
It’s the usual high quality stuff you can count on from Steve, but I’d like to
respond a couple of comments made regarding my forte, Web architecture.
Something tells me Steve probably anticipated this response. 8-)
A URL specifies only a single protocol, but a service could be reachable via multiple
protocols. For example, a service might accept messages over both HTTP and SMTP, but
any URL for the service can specify only one of those access methods.
It’s very commonly believed that URI scheme == protocol, but that
really isn’t the case. A URI scheme defines a few things, but most
important are the properties of the namespace it forms, in particular
scope and persistence of uniqueness, whether it’s hierarchical, and
probably some other things I’m forgetting. Defining an algorithm for
mapping an identifier in that namespace, to a connection to a remote
server on the Internet someplace is independent of those properties.
- interactions with mailto URIs don’t necessarily begin or end
- an http URI can be minted and used successfully before a Web
server is installed, or even while the Internet connection is down
- RFC 2817 describes
how to interact using HTTPS with a resource identified by a http URI using
HTTP only as a bootstrap mechanism via Upgrade. Upgrade isn’t
specific to HTTPS either.
There is certainly a relationship – as defined in the aforementioned
algorithm above – between a URI scheme and a protocol in the context of
dereferencing and sending messages, but as those last two points above
describe, it’s not quite as clear-cut as “URI scheme == protocol”.
Steve also adds;
URLs can’t adequately describe some transport mechanism types. For example,
message queues typically are defined by a series of parameters that describe the queue
name, queue manager, get and put options, message-expiration settings, and message
characteristics. It isn’t practical to describe all of this information in some form of
I’ve had to tackle this exact problem recently, and I figure there’s
two ways to approach it. One is to suck up the ugly URI and embed all that
information in one; I’m confident that could be done in general, because I’ve
done something very similar. I would highly recommend this solution if you
can do it because it’s efficient. But, if you can’t, you can always use a
URI which doesn’t include that information, but which is minted at runtime
as a result of POSTing the endpoint descriptive data to a resource which
hands out URIs for that purpose; that requires an additional coordination
step, but you get nice, short, crisp looking URIs.
Moreover, not only do I believe that URIs are great for identifying
message queues, I believe (surprise!) that http URIs are. Consider what
it means to invoke GET on a message queue; what’s the state of a queue
(that will be returned on the GET)? Why, the queued messages of course.
This, plus POSTing into the same queue, is the fundamental innovation of
URLs do not necessarily convey interface information. This is especially true of HTTP URLs,
because Web services generally tunnel SOAP over HTTP.
Wait a sec, you’re blaming http URIs for the problems caused by tunneling?! 8-O 8-)
Most (good) URIs do convey interface information, at least in the context
of dereferencing (which is the only place that an interface is needed). So if I see
a http URI, I can try to invoke HTTP GET on it (keeping in mind some of the
considerations mentioned above).