RE: T is for Transfer

> From: Vinoski, Stephen [mailto:VINOSKI@iona.com]
[snip]
> 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.

My perception of the Web landscape is indeed that only some
web services/web-based apps will find good use for something
like a SOAP-ioctl -- as in Unix, few C/C++ programs make ioctl
calls.  The majority can just go on their own merry way without it.

> Also, there is indeed a large number of applications that *do* yield
> entire control of their lower layers to middleware. 

I don't disagree here.  In fact, from a network infrastructure
perspective, I see middleware in the role of an operating system
for the web.  That is, as ioctl resides in the Unix kernel,
SOAP-ioctl's logical embodiment will be in web middleware, which 
acts as the agent between web service endpoints and the underlying
infrastructures, i.e. network, database, security, etc.  
The scope of the agent's role is where our individual opinions
see-saw, I think.  (I also think the scope is elastic, variable
from application to application.

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

It's happened for the what's already out there, but not for
some network-infrastructure services that are still under wrap,
poising to make their presence to the user community in due time.
(That's yet more lying underneath that will provide more
for you salary, Steve. ;-)

I can't help making the "fantasy" reference.  "Fantasy" is a
good, positive, optimistic thing.  I'd have used "fallacy"
instead if I didn't believe in middleware.  As reality is
there's the reality gap.  Take BASIC for example, it's easy
to program because the BASIC interpreter (as a middleware)
does a good job of semantic abstraction for the programmer.
All is well, until the programmer wants to do something
that his C counterpart can do with ioctl.  The BASCI
programmer will then have to start hacking assembly code,
a messy proposition.  Needless to say I'm for the C model.
I think you as a middleware vendor would rather provide
C compilers (with ioctl semantics) than BASIC interpreters
(without iotcl semantics).  Wouldn't you?
My example may be clumsy, but that's what's come to mind
for the time being to illustrate my circumspect in
programming abstraction and my preference for web middleware
with SOAP-ioctl, built-in or optional.  

In the final analysis, in spite of our differences in views
or the same problem due likely to our different perspectives,
I find solace in the fact that we both recognize a SOAP-ioctl
can be useful for some web services, but not for all.
The difference of opinions (yours, others', mine) in the
scope and role of web middleware is natural and healthy,
thus I can certainly live with it without further ado.

Cheers,

Joe Hui
Exodus, a Cable & Wireless service
=======================================
 
> --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 14:58:14 UTC