- From: Joseph Hui <jhui@digisle.net>
- Date: Fri, 26 Oct 2001 12:30:34 -0700
- 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 UTC