RE: SOAP Binding Framework Concerns

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