RE: T is for Transfer

The points I made were not black and white. My main point was only that
there are applications for which ioctl-like approaches do not work well.
This in no way implies that ioctl-like approaches won't work for other
types of applications, but it's not a panacea.

Also, there is indeed a large number of applications that *do* yield
entire control of their lower layers to middleware. To say that this
will never happen or that "it's a fantasy" is ignoring reality, because
it's already happened, and in fact it's what pays my salary.

--steve

> -----Original Message-----
> From: Joseph Hui [mailto:jhui@digisle.net]
> Sent: Friday, March 29, 2002 1:55 PM
> To: Vinoski, Stephen; Mountain, Highland M; Eugene Kuznetsov; Mark
> Baker; Appleton Pete M
> Cc: xml-dist-app@w3.org
> Subject: RE: T is for Transfer
> 
> 
> > > From: Vinoski, Stephen [mailto:VINOSKI@iona.com]
> [snip]
> 
> Stephen,
> 
> I think you were confused.
> My comments are inlined below.
> 
> > Joe,
> > 
> > Two big problems with what you're proposing:
> > 
> > 1) Embedding ioctl, setsockopt, or things like it into applications
> > makes them transport-specific. 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.
> 
> Ioctl semantics are not embedded in applications.
> Ioctl semantics are about letting user applications (at
> an upper layer of a computing abstraction) access a class of
> system resources (e.g. files, devices, network, etc) controlled
> by the operating system (at a lower layer of the same computing
> abstraction).  That is, ioctl is just an API (aka "system call"
> in Unix nomenclature) between the upper and lower layers.
> The "SOAP-ioctl" is no hindrance to SOAP-agnostic applications.
> They can just keep going on their own merry way.
> How are they to know SOAP-ioctl anyway, if they don't even
> care to know SOAP? 
> 
> There are applications that don't care what lies underneath.
> There are many of them, some of which, highly abstracted, can
> even be generated straight from graphs, whose creators may 
> not even be cognizant of the concept or the term "application."
> 
> However, there are those that do care.  E.g. an app may want to
> utilize CDN and/or security services offered by its hosting or
> network infrastructure provider, without having to shell out a
> king's ransom for a middleware package just for the interface.
> (Of course, that king's ransom in some cases is well worth it,
> but not in all cases.)  BTW, I haven't even begun to tell how
> powerful (and useful in sophisticated ways, when properly done)
> that the concept of context-switching (between upper and lower
> layers) associated with ioctl can be applied in the Web space.
> That's yet some other subject, for some other time.
>  
> > 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.
> 
> It's a fantasy that upper-layer applications and lower-layer
> infrastructures would surrender their prerogatives to middleware
> in the Web space.  It'll never happen.  (This is not to undermine
> the value that middleware offers.)  There're applications that
> want direct lower level access.  The notion that middleware knows
> best, i.e. what's best for all applications above it and all network
> infrastructures beneath it, is not an axiom.  
> 
> > 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 -- so I'm certainly sympathetic to your 
> > wanting to help resolve the arguments.
> 
> I can't take credit for wanting to help.  I wasn't even keenly
> aware there were arguments to be resolved.
> 
> In equal measure, I'm sympathetic to your allowing yourself confused.
> 
> Firstly, this was a new and separate thread that gave no pretext
> that there had been some HTTP-SOAP-binding arguments going on 
> elsewhere.
> This thread is about how interesting that HTTP is seen a transport
> vs transport protocol.
> Where did this "chameleon vs. tunneling" thing come from?
> Looks like you have tided the issues on some other thread
> onto this one.  At this rate, the tidal pool's going to
> overtake the ocean. :-)  
> 
> Secondly, providing API for access to lower-level semantics/primitives
> is a proven concept that has served well and will continue to
> serve into the foreseeable future.
> 
> As far as "architecture and engineering practice" goes, I'm among
> those who don't allow themselves the luxury of dogmatic indulgence.
> Often there's more than one *right* solution for a same problem.
> 
> > But rather than pushing the problem up to
> > the application, we should try harder to find the appropriate
> > abstractions that allow SOAP to REST easy with HTTP :-) 
> without being
> > locked into HTTP. (Had all the energy put into the argument 
> > to date been
> > spent searching for such abstractions instead, I'm sure the problem
> > would be solved by now.)
> 
> You folks apparently were pushing and shoving some problem somewhere
> else.  I had no part of it and don't intend to start now, though
> I'm curious of what problem/thread the fuzz is about.
> 
> Good luck,
> 
> Joe Hui
> Exodus, a Cable & Wireless service
> =================================================
> 
> > 
> > --steve
> > 
> > > -----Original Message-----
> > > From: Joseph Hui [mailto:jhui@digisle.net]
> > > Sent: Thursday, March 28, 2002 8:58 PM
> > > To: Mountain, Highland M; Eugene Kuznetsov; Mark Baker; 
> > > Appleton Pete M
> > > Cc: xml-dist-app@w3.org
> > > Subject: RE: T is for Transfer
> > > 
> > > 
> > > > From: Mountain, Highland M 
> [mailto:highland.m.mountain@intel.com]
> > > [snip]
> > > > +1 to Eugene
> > > > 
> > > > All,
> > > > 
> > > > Given the reality of the industry, we need to find the best 
> > > > resolution to
> > > > both sides of the transport/transfer argument. SOAP envelopes 
> > > > will be "sent"
> > > > via HTTP, BUT we also need to preserve SOAP's protocol 
> > > > neutrality.  I like
> > > > Joe's PDU view of the SOAP envelope sitting on top of 
> > > > HTTP(see snip below),
> > > > but HTTP does provide features we should not ignore.  
> > >       ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> > > 
> > > Yes, HTTP, and the TCP below HTTP, and the IP below TCP,
> > > and the physical network infrastructure below IP, all
> > > provide features that some SOAP nodes would like to use.
> > > And the SOAP nodes can indeed use them without violating
> > > the stack/layering model.  It can be done by borrowing
> > > from Unix's ioctl(2) model.  (Ioctl's counterpart in
> > > networking is getsockopt(3N) and setsockopt(3N), both.)
> > > As a Unix user application can make setsockopt() to
> > > configure socket, TCP, or IP options across layers,
> > > e.g. setsockopt(...,SO_OOBINLINE,...), a SOAP application
> > > should also be able to do so similarly, provided there's
> > > an ioctl-like feature in SOAP.  So far, such feature is
> > > not intrinsic to SOAP.  So one would have to improvise with
> > > SOAP extensions.  (I've been doing that in my research into
> > > SOAP Extensions for Web Services Delivery Networks (SEWSD).)  
> > > 
> > > The idea is to keep SOAP as clean as possible, no pun intended,
> > > by providing a single interface to reach and touch the gunk
> > > in underlying layers.
> > > 
> > > BTW, I never wanted to get sucked into SOAP threads.
> > > Aren't you folks supposed to wrap up SOAP 1.2 by April?
> > > The above SOAP-ioctl thing was intended for SOAP 1.3 only.
> > > 
> > > Joe Hui
> > > Exodus, a Cable & Wireless service
> > > ==================================================
> > > 
> > > > Concerns addressed by
> > > > Scott Cantor (and others) should be addressed by separate 
> > > > HTTP Bindings.
> > > > 
> > > > 
> > > > SOAP 1.2 and the Protocol Binding Framework do not get in the 
> > > > way of these 2
> > > > views. What does is the lack of process for developing and 
> > > publishing
> > > > Normative Bindings that the whole industry can reference in a 
> > > > consistent
> > > > manner.  Earlier today, Glen Daniels proposed a SOAP module 
> > > > specification
> > > > template activity.  While there is a Protocol Binding 
> > > > Framework in the spec,
> > > > which is somewhat analogous to Glen's Module Spec Template 
> > > > idea, the process
> > > > for publishing Normative Binding Specifications and/or Module 
> > > > Specifications
> > > > appears to be lacking.  Until the process of publishing a 
> > > > Normative Protocol
> > > > Binding is ironed out and well understood, developers may be 
> > > > driven to use
> > > > the Default HTTP POST binding even if another HTTP 
> method is more
> > > > appropriate for their application.
> > > > 
> > > > Thoughts?
> > > > 
> > > > Highland
> > > > 
> > > > 
> > > > 
> > > > Joe Hue wrote:
> > > > > It's bad engineering to transfer data of identical PDU
> > > > > type -- in this case, SOAP is the PDU type -- in separate
> > > > > protocols, let alone seperate protocol layers.  (SOAP sits
> > > > > above HTTP.)  
> > > > 
> > > > 
> > > > 
> > > > Scott Cantor wrote:
> > > > .....you're using GET, POST, PUT, DELETE, etc. and following
> > > > all the usual, expected rules that HTTP specifies, which 
> > > > allows a whole
> > > > lot of interesting things to happen in the world automatically. 
> > > > 
> > > > -----Original Message-----
> > > > From: Eugene Kuznetsov [mailto:eugene@datapower.com]
> > > > Sent: Thursday, March 28, 2002 4:58 PM
> > > > To: Joseph Hui; Mark Baker; Appleton Pete M
> > > > Cc: highland.m.mountain@intel.com; xml-dist-app@w3.org
> > > > Subject: RE: T is for Transfer
> > > > 
> > > > 
> > > > > HTTP is not a transport protocol by design; but it doesn't 
> > > > stop people
> > > > > from seeing it as one creatively, often for its 
> > "port-80 firewall
> > > > > friendliness." 
> > > > 
> > > > Exactly. One may hold any one of several views on the 
> > > morality of this
> > > > reality, but it's a reality nonetheless.
> > > > 
> > > > \\ Eugene Kuznetsov
> > > > \\ eugene@datapower.com
> > > > \\ DataPower Technology, Inc.
> > > >  
> > > > 
> > > > 
> > > 
> > > 
> > 
>

Received on Monday, 1 April 2002 02:11:01 UTC