- From: Steve Vinoski <vinoski@iona.com>
- Date: Fri, 26 Oct 2001 10:43:58 -0400
- 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
<delurk> 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. </delurk> --steve 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