Re: Proposal: MEP support in operations

First I like the general idea of adding explicit mep support in WSDL 
within operations.
I am not sure however that the direct use of SOAP meps would perfectly 
work...
The SOAP Request-Response mep fits nicely within your proposal and WSDL.
What about the SOAP-Response mep ?
I do not clearly see the implications of  selecting the SOAP-response 
mep in place of the Request-Response mep at the WSDL abstract operation 
level... Both meps implement a generic "request-response" mep, but the 
"message serialization" is not at all the same for the request message...
I think that it would be better to say:
    - operation Foo is request-response and safe at the abstract level
    - we implement Foo with a SOAP-Response mep at the binding level
than:
    - operation Foo is soap-response at the abstract level

Should there be a rewriting work of SOAP meps to extract them from SOAP 
and turn them into Web Services meps ?
Should we have something (nearer from today's WSDL model ) like a 
generic web service request-response mep (which would be quite similar 
to the SOAP Request-Response mep IMHO) that can be implemented at the 
binding level by these two SOAP meps ?
Any comment ?

    Youenn



Don Mullen wrote:

>The following is a proposal for generalizing message exchange pattern
>support in WSDL.
>
>Currently an operation's MEP is recognized by examining the order of its
>input and ouput children, and is limited to four varieties.  This proposal
>recommends instead that the MEP be made explicit by the use of a standard
>attribute on 'operation'.  The attribute would be described as follows:
>
>	local name: mep
>	namespace name: absent
>	type: xs:anyURI
>
>If backward compatibility is desired, then four "standard" URIs might be
>created, and associated as the default for operations conforming to their
>patterns.  In fact, since output-input and output-only have not been
>adequately supported in the past, they might have no default.  The same
>might also hold for input-only, which is also relatively underdescribed, in
>comparison to input-output (request/response).
>
>This has the advantage of allowing multiple definitions of semantics for
>certain patterns, as these prove needed.
>
>In addition, an attribute to 'input' and 'output' would be added in order to
>identify the specific role being played in the MEP.  The attribute would be
>described as follows:
>
>	local name: messageRole
>	namespace name: absent
>	type: xs:QName [or xs:anyURI depending on resolution in XMLP re:
>property type?]
>
>Example One (Request-Response):
>
><operation name="GetResponse"
>mep="http://www.w3.org/2002/06/soap/mep/request-response/"
> 
>xmlns:req-resp="http://www.w3.org/2002/06/soap/mep/request-response/">
>  <input type="GetResponse_Request" messageRole="req-resp:InboundMessage"/>
>  <output type="GetResponse_Response"
>messageRole="req-resp:OutboundMessage"/>
></operation>
>
>Example Two (Event-Notification):
>
><operation name="Event-1"
>mep="http://www.example.org/soap/mep/event-notification/"
> 
>xmlns:event="http://www.example.org/soap/mep/event-notification/">
>  <input  type="Subscription_Request" messageRole="event:subscribe"/>
>  <output type="Event_Notification" messageRole="event:event"/>
>  <input  type="Unsubscribe_Request" messageRole="event:unsubscribe"/>
></operation>
>
>Note here that the "Event_Notification" could be specified as being 'zero or
>more events'.
>
>----------------
>Don Mullen
>TIBCO Software
>
>  
>

Received on Friday, 13 December 2002 05:44:47 UTC