W3C home > Mailing lists > Public > xml-dist-app@w3.org > October 2001

RE: SOAP Binding Framework Concerns

From: Joseph Hui <jhui@digisle.net>
Date: Fri, 26 Oct 2001 12:30:34 -0700
Message-ID: <C153D39717E5F444B81E7B85018A460B0244B439@ex-sj-5.digisle.com>
To: <Noah_Mendelsohn@lotus.com>, "Marwan Sabbouh" <ms@mitre.org>
Cc: "Kumeda" <kumeda@atc.yamatake.co.jp>, "Marc Hadley" <marc.hadley@sun.com>, "Williams, Stuart" <skw@hplb.hpl.hp.com>, <xml-dist-app@w3.org>, <xml-dist-app-request@w3.org>
> -----Original Message-----
> From: Noah_Mendelsohn@lotus.com [mailto:Noah_Mendelsohn@lotus.com]
[snip]
> Marwah Sabbouh writes:
> 
> >> It seems to me that the SOAP application 
> >> programmer still needs ( and wants) to specify the protocol
> >> he needs to use.
[snip]
> The general notions of 
> Open/Close/Read/Write are 
> analagous to our binding framework:  they state what's common 
> across all these diverse data management systems.
> 
> The mechanisms of the binding framework allow a similar and 
> very important 
> late coupling for SOAP applications.  With respect, I claim 
> that in many 
> cases I do _not_ want to hard code knowledge of the transport into my 
> application business logic.  I want to say:  "send this 
> envelope as a soap request, using whatever transport is appropriate."

Not to make the binding framework more complicated than it has to be or
less useful to "nosy" SOAP apps, I think that an ioctl-analogous
mechanism
would make the framework more complete, let alone addressing the need
for protocol selection that Marwah was alluding to.  The semantics may
be built around some simple get/set, e.g. fetching error codes/messages
from the transport when a soap request has failed, or switching from
TCP to HTTP (to slip through firewalls).  In more far-fetching cases,
which MUST only be optional for framework implementations, app modules
may be pushed downward, well beneath SOAP.

Joe Hui
Digital Island, a Cable & Wireless company

 
Received on Friday, 26 October 2001 15:29:21 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 7 December 2009 10:59:04 GMT