W3C home > Mailing lists > Public > public-sws-ig@w3.org > November 2003

Re: Broken Layering (was Re: What protocols are in scope?)

From: Paul Denning <pauld@mitre.org>
Date: Thu, 20 Nov 2003 13:17:24 -0500
Message-Id: <>
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 

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

Received on Thursday, 20 November 2003 13:19:30 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:32:43 UTC