RE: T is for Transfer

For whatever it's worth, I'd like to clarify, in case I didn't
make it perfectly clear in the past, that what I have most in
mind for SOAP-ioctl is mainly to provide a clean interface for
web service endpoints to specify to underlying infrastructures
on the fly some lower-level parameters.  Of immediate interest to
me are those that are content-delivery related: QoS, cacheability,
security, etc.  In other words, the SOAP-ioctl was NOT motivated
by the possibility that it could be a "powerful" thing to allow
web service endpoints in general to mug with parameters at or
beneath the transport layer of the OSI stack, such as socket
buffer size, TCP/transport options, ..., though it can be
used for such purposes handily.  

Joe Hui
Exodus, a Cable & Wireless service
==================================================

> From: Don Box [mailto:dbox@microsoft.com]
> Sent: Monday, April 01, 2002 10:47 AM
> To: Vinoski, Stephen; Joseph Hui; Mountain, Highland M;
[snip]
> > 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 17:51:59 UTC