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

Re: SOAP Binding Framework Concerns

From: Steve Vinoski <vinoski@iona.com>
Date: Fri, 26 Oct 2001 10:43:58 -0400
Message-Id: <>
To: Noah_Mendelsohn@lotus.com
Cc: Marwan Sabbouh <ms@mitre.org>, 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
I agree 110% with Noah. There are several middleware systems out there, 
such as IONA's Adaptive Runtime Technology (ART), that provide 
application-transparent multiprotocol binding and transport capabilities. 
Such systems have been used in production for years now. We don't want to 
take any steps backward in this area with SOAP.


At 10:34 PM 10/25/01 -0400, Noah_Mendelsohn@lotus.com wrote:
>Marwah Sabbouh writes:
> >> It seems to me that the SOAP application
> >> programmer still needs ( and wants) to specify the protocol
> >> he needs to use.
>Perhaps this is the essence of the disagreement.  When I write a program
>to read a file, I typically don't know at the time I write and compile the
>program whether I will read from a hard drive or a floppy, NTFS vs. FAT or
>whatever.   Of course, when I run the program, it will be one or the
>other.  Indeed, sometimes the same program on Unix can read from a socket,
>pipe or tape drive too.  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."
>I expect that some middleware, not specified in SOAP, but very possibly
>some combination of UDDI and WSDL will allow me at deployment time or
>runtime (long after the application is coded and compiled) to figure out
>which transport each of my partners is using.  So, I might use
>Request/Resp over http to reach some partners, and Request/Resp over
>MQSeries to reach those with whom I have set up such a link.  I do _NOT_
>want to recode my application when switching from one supplier to another:
>  I expect Request/Resp to look the same over both, and I expect middleware
>to make the transport binding switch for me, just as the OS and filesystem
>know whether to go to the floppy or the harddrive.
>I think this flexibility is powerful and important in practice.  I can see
>why, if you are not interested in these scenarios, the binding framework
>would be of less use.  Some of us very much want to build applications in
>this manner and therefore look to the binding framework to provide the
>coordination across bindings.  I hope this makes sense.  Thank you.
>Noah Mendelsohn                                    Voice: 1-617-693-4036
>Lotus Development Corp.                            Fax: 1-617-693-8676
>One Rogers Street
>Cambridge, MA 02142
Received on Friday, 26 October 2001 11:36:45 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 22:01:16 UTC