- From: Paul Denning <pauld@mitre.org>
- Date: Thu, 20 Nov 2003 13:17:24 -0500
- To: public-sws-ig@w3.org
At 12:51 PM 2003-11-20, Geoff Arnold wrote: >I'm more concerned about SOAP over non-HTTP messaging schemes, particularly >MOMs. Just to make your head hurt, consider the case of multiple SOAP >intermediaries where the complete path may involve HTTP and non-HTTP hops. >Today MOM vendors use proprietary encodings to fake an HTTP-like >view at each end. That won't do for standards, though. DIME may be >dead, but the need still exists. That is where the concept of "features" and "modules" comes in, and seems like it can be layered quite well. Also the idea of Message Exchange Patterns (MEPs) was to essentially fake out or abstract the service provided by the lower layer binding. If apps were designed to expect the synchronous response of HTTP, that app is effectively designed to use a request/response MEP. If the underlying (non-HTTP) binding does not provide a synchronous response, then you may need a "feature" to fake it out so that the application using SOAP sees the same MEP behavior. If a non-HTTP binding natively implements the req/rsp MEP, then you should be able to substitute the non-HTTP binding and not break the application. I have not seen much emphasis for declaring an application's MEP requirements. I have not followed WSDL 2.0 close enough to know if they can describe ways of doing a request response MEP over bindings that do not natively support it. Perhaps we need some new MEPs defined for use with MOM's, or new features/modules that make the MOMs look like request/response MEPs. If you a re using MOMs, you are probably in the realm of higher level choreographies. I know WSAWG is expecting WSDWG to look harder at intermediaries and how to describe them (when the ultimate receiver may not know about them, but the original sender needs to know what to do). Paul
Received on Thursday, 20 November 2003 13:19:30 UTC