RE: T is for Transfer

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.

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

--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 01:11:54 UTC