RE: T is for Transfer

> -----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 UTC