W3C home > Mailing lists > Public > www-ws-desc@w3.org > January 2003

reverse of out-(in|ifault)*

From: FABLET Youenn <youenn.fablet@crf.canon.fr>
Date: Fri, 24 Jan 2003 10:40:08 -0500 (EST)
Message-ID: <3E315E1B.3090308@crf.canon.fr>
To: www-ws-desc@w3.org
This is a follow-up on the out-(in|ifault)* pattern (i.e. a multicast 
output message followed by input/fault messages from different nodes) 
discussion.
There was some discussion about its related reverse pattern.
If I remember correctly, the reverse chosen pattern was in-(out|ofault) 
which is also the reverse of the out-(in|ifault).
I would argue that the reverse pattern might in fact probably be 
in-(out|ofault)? because a multicasted receiving node might not even 
want to answer to the incoming multicasted message.
The desired number of interaction patterns to describe would grow from 7 
to 8.
in
out
in-(out|ofault)
out-(in|ifault)
in-out*-ofault?
out-in*-ifault?
out-(in|ifault)*
in-(out|ofault)?

Following the "soapish" mep approach (where nodes are defined but the 
service is not identified), we would need to write 4 specs.
Following the "non-soapish" mep approach (where the service is 
identified in the spec), we would need to write 8 specs.
Interestingly, it seems that the out-(in|ifault)* pattern is not 
entirely defined if we do not define its reverse pattern: the pattern 
out-(in|ifault)* is very different whether all receiving nodes must or 
may answer (i.e. whether its reverse mep is in-(out|ofault) or 
in-(out|ofault)?)

What is interesting with the "soapish" mep approach is that you do not 
need to care about the reverse patterns, they are already in the 'not 
reversed' specs  :-) . And because they are already defined somewhere, 
we do not need to define by their own  ;-)

    Youenn
Received on Friday, 24 January 2003 12:40:46 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 7 December 2009 10:58:22 GMT