W3C home > Mailing lists > Public > www-ws@w3.org > July 2001

Re: open transport protocol for aysnc web services?

From: Mark Nottingham <mnot@akamai.com>
Date: Mon, 9 Jul 2001 11:35:38 -0700
To: Mark Baker <distobj@acm.org>
Cc: nick@invertica.com, www-ws@w3.org
Message-ID: <20010709113533.A30080@akamai.com>

So this is something I couldn't determine about KN and related
solutions, and didn't get into talks deep enough to get a solid

Do they do polling from the client, or send asynch messages from the
server to the client?

If they do polling, it's ugly, and they have built-in latency, as
well as infrastructure concerns, but it works.

If they do asynch server->client messaging, they fundamentally break
the HTTP, and will not work when HTTP proxies, etc. are interposed.


On Mon, Jul 09, 2001 at 10:40:08AM -0400, Mark Baker wrote:
> Hi Nick,
> Nick Nadgauda wrote:
> > If I understand their products correctly, what KnowNow, Kenamea, and Bang
> > Networks have basically done is build a tunnel over HTTP.  They've defined a
> > new closed "protocol" -- in this case the protocol being "use 2 HTTP
> > connections, one to send and one to receive, and keep the receive one
> > constantly open".  This works great because they control both ends of the
> > connection.  Unless other vendors (publishers and subscribers alike) adopt
> > this "protocol", you won't have true inter-vendor interoperability the way
> > you will with synchronous web services.  Kind of like I can't assume that
> > everything speaks Tibco or Vitria.
> I don't know much about Bang or Kenemea's technology, but happen to know
> a lot about KnowNow's.  You're incorrect in your characterization of
> them.
> They are definitely not creating a new protocol.  There is no tunnelling
> going on here.  At the server side, it's true that you're accessing URLs
> maintained by their software.  This is a good and valid thing to do, as
> their router provides a stateful service.  On the client side though, no
> software (runtime or library) is required (though a library may be used,
> and a runtime may also be used for persistent routing).  It's just GET
> and POST, with some *optional* parameters for doing stuff that will
> eventually be standardized.
> The basic HTTP idiom that they're following is simple; an HTTP GET on a
> router-provided URL implements the subscription, and an HTTP POST to
> that node provides for delivery of the event notification.
> MB

Mark Nottingham, Research Scientist
Akamai Technologies (San Mateo, CA USA)
Received on Monday, 9 July 2001 14:35:40 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:37:06 UTC