W3C home > Mailing lists > Public > xml-dist-app@w3.org > April 2002

RE: T is for Transfer

From: Don Box <dbox@microsoft.com>
Date: Mon, 1 Apr 2002 10:46:51 -0800
Message-ID: <CFC4F26947496E4092489B2425614958042D358B@svc-msg-02.northamerica.corp.microsoft.com>
To: "Vinoski, Stephen" <VINOSKI@iona.com>, "Joseph Hui" <jhui@digisle.net>, "Mountain, Highland M" <highland.m.mountain@intel.com>, "Eugene Kuznetsov" <eugene@datapower.com>, "Mark Baker" <distobj@acm.org>, "Appleton Pete M" <PMAppleton@bemis.com>
Cc: <xml-dist-app@w3.org>
> -----Original Message-----
> From: Vinoski, Stephen [mailto:VINOSKI@iona.com]
> Sent: Thursday, March 28, 2002 10:11 PM
> To: Joseph Hui; Mountain, Highland M; Eugene Kuznetsov; Mark Baker;
> Appleton Pete M
> Cc: xml-dist-app@w3.org
> Subject: RE: T is for Transfer
> 
> Joe,
> 
> Two big problems with what you're proposing:
> 
> 1) Embedding ioctl, setsockopt, or things like it into applications
> makes them transport-specific. 

Of course, if an OS has a virtualized SOAP driver buried in kernel mode,
then DeviceIOControl et al would be reasonable ways to configure a
kernel-mode SOAP stack. Given the current state of the practice of
user-mode implementations, this isn't the way it is done today.

> Applications should be written at a level
> of abstraction such that they're unaware that they're using SOAP, let
> alone using SOAP over HTTP over TCP or other such combinations.

Certainly writing apps that depend on HTTP or TCP semantics is bad -
although most SOAP code today has a fair amount of dependency on HTTP,
in practice if not in theory.

> 2) Performing such transport-specific trickery at the application
level
> can prevent underlying middleware from performing optimally or
properly.
> It prevents middleware providers from maintaining control over the
> transport settings, thus putting the onus for transport-level issues
> back into the application, and as a result the benefits of middleware
> are largely negated.

I wouldn't frame this as middleware vs. the app. A properly factored
protocol stack gives people the opportunity to impose transport-level
policy in a fairly modular way.  I believe that your stack in orbix
allows this sort of thing. I know our stack in .NET does.

> I side squarely with Mark on these "chameleon vs. tunneling" issues --
> to me it's simply normal architecture and engineering practice to
ensure
> that the upper layers of any system obey and honor the semantics of
the
> lower layers they might rely upon, and I'm surprised that anyone would
> argue to the contrary 

Agreed. HTTP/1.0 is a great example of a case where the lower-level
protocol characteristics (e.g., TCP congestion control et al) didn't
inform the upper-level protocol design. 

DB
Received on Monday, 1 April 2002 13:47:25 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 7 December 2009 10:59:09 GMT