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 Friday, 29 March 2002 13:55:19 UTC