[
Lists Home |
Date Index |
Thread Index
]
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
> -----Original Message-----
> From: Paul Prescod [mailto:paul@prescod.net]
>
> Bill de hÓra wrote:
> >
> >...
> >
> > This is a holy grail within distributed computing just as much
> > as mantra for the people lumbered with the jobs of buying and
> > selling middleware. The point of convergence, or agreement,
> > between web services (eg XMLP), p2p (eg JXTA) and agent
> > systems (eg FIPA-AA) is that networked applications must be
> > allowed to be transport
> agnostic.
> > Transport Agnostic==The Good is an axiom of many architectures.
>
> Transport agnosticism makes a lot of sense. If the firewalls
> of tomorrow block TCP/IP then you want to be able to switch
> to IPX or whatever comes next.
There's more to it than that. Transport agnosticism also protects
an application or communicating applications from changes in the
underlying network topology.
> But HTTP is not a transport protocol (though you can use it
> that way). It is an application protocol, with a set of
> generic semantics.
No doubt. You will see the HTTP/SMTP-TCP/IP layers flattened in the
future for better or worse. A transport is somewhat relative. As
Sean points out that has consequences if you expect messaging
behaviour to remain consistent across what can be characterized as
"transport soup". From the application's standpoint what it really
wants are service or policy guarantees for message sending; how
that is realised isn't that interesting to it. An application of a
few years hence, should expect a service to make good decisions
with respect to transport/transfer for it. The agent and p2p worlds
are getting this right for the most part.
> Eventually you need to figure out what the data, addressing
> and invocation model of your web service is. You cannot be
> "model-agnostic." You must decide. HTTP already gets you far
> down this path with its URI addressing model and 4 main
> methods for invocation. "Abstracting" over HTTP by erasing
> its model is not abstracting at all. It's like implementing
> the JVM in Lisp and saying that you are now "programming
> model independent" because you've put some byte codes over
> the Lisp object model. Well, no, you've obliterated the
> programming model and someone is going to be forced to build
> another one on top. And guess
> what: you won't be programming model independent anymore!
I'm not sure about this. Future network protocols will ideally
concentrate on creating languages to articulate messaging policy
and quality of service guarantees. An application can be remain
agnostic if it can express its requirements to another service.
All HTTP methods can be subsumed by SEND and RECEIVE, I don't care
to argue whether that's desirable. And I'm wary of absolutism; "the
end of science", "there's nothing left to patent" type utterances
about HTTP and REST (or any computing item) don't convince me as
rhetoric. The issue with abstracting over HTTP is more strategic
than technological: if you pull that abstraction off, you
commoditize web infrastructure. Not at all unlike, say, the way
hardware makers were commoditized by proprietary operating systems.
Bill de hÓra
-----BEGIN PGP SIGNATURE-----
Version: PGP 7.0.4
iQA/AwUBPH37n+aWiFwg2CH4EQKgnwCgsK6WIo4u+LCGhvwW08NKCiNb+i0AnjQF
xqwHUpKd7eD0uKCFhpx7z6Vl
=z4LS
-----END PGP SIGNATURE-----
|
