Re: Proposal: MEP support in operations

Don,

a quick glance over your proposal makes me raise an objection:

As I have said on a few occasions before, SOAP MEPs are not the same as
WSDL operation types. SOAP MEPs (even though possibly independent of
SOAP) deal with multiple nodes and what they do (usually they pass
messages among themselves), while WSDL operation types describe the
logically related sequences of messages coming in and going out of an
interface. I have never noticed disagreement with this distinction,
except maybe on details.

I think that indicating the WSDL operation type by reference to a SOAP
MEP is ambiguous unless the specific mapping from a SOAP MEP to a WSDL
operation type is defined, which AFAICS your proposal doesn't do.

Anyhow, the 'logically related sequence of messages' can be seen on
different levels. The current WSDL says that one-message and
message-and-response are the only such sequences. If we go into event
notifications as complex as you seem to indicate, we might have a
significant overlap with the orchestration/choreography area. I'd like
to avoid it.

Hope this makes sense,

                   Jacek Kopecky

                   Senior Architect, Systinet Corporation
                   http://www.systinet.com/



On Wed, 2002-11-20 at 19:48, 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 Thursday, 21 November 2002 09:17:48 UTC