RE: T is for Transfer

I agree that today there is a gaping hole in how endpoints discover
QOS-like aspects of a service contract.

That stated, I don't think SOAP proper should be addressing this. SOAP
specifically avoided folding in metadata-like features in order to ship,
leaving open issues like operational types for follow-on specs like
WSDL.

DB


> -----Original Message-----
> From: Joseph Hui [mailto:jhui@digisle.net]
> Sent: Monday, April 01, 2002 2:52 PM
> To: Don Box; Vinoski, Stephen; Mountain, Highland M; Eugene Kuznetsov;
> Mark Baker; Appleton Pete M
> Cc: xml-dist-app@w3.org
> Subject: 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 18:14:26 UTC