Re: write-up of interaction patterns

Please see below within <sw> .. </sw> (in blue, if the email format
changing gods approve it).

Sanjiva.

----- Original Message ----- 
From: Prasad Yendluri 
To: Sanjiva Weerawarana 
Cc: www-ws-desc@w3.org 
Sent: Monday, January 13, 2003 6:47 PM
Subject: Re: write-up of interaction patterns


Sanjiva,

Looks pretty good to me. Couple of reflections based on a quick read:

1. The  interaction syntax certainly permits this (message+) but, we need to account for the "fault" 'role' as well in the interactions shown. I am not sure if it is an intentional omission but, I take there is no intended simplification or departure from the current <fault>* (0,1,more) approach. Accounting for that, the input-output interaction could look as follows:


1 <portType name="ncname">
2    <interaction name="ncname" 
                  pattern="http://www.w3.org/2003/ws/desc/patterns/input-output">
3       <message messageType="qname" role=".../patterns/input-output#input-message"/>
4       <message messageType="qname" role=".../patterns/input-output#output-message"/>
5       <message messageType="qname" role=".../patterns/input-output#fault-message"/>*
6    </interaction>
7 </portType>

<sw>OOPS, yes of course .. my mistake. Will correct.</sw>

The interesting aspect here perhaps is the optional and multiply-definable nature of the interaction. That is, an instance of an interaction defined by this "pattern" MAY NOT have a message of a particular kind of role and MAY have more than one message of a certain kind of role.  The generic interaction syntax needs to accommodate that as well, which it currently does not.

<sw>I don't grok this; can u elaborate please? The proposed synax doens't
preclude anything IMHO as it doesn't do anything other than listing stuff
and giving them roles .. the actual MAY/MAY NOT/MUST etc. comes from the
document that defines the pattern.</sw>

2. To be really usable, I think we need to specify/constrain how one should define the "pattern" that is identified in an interaction, is defined (i.e. the stuff the URI refers to). Without that, people are likely to define things in varying formats and with lots of scope for interpretation etc. (we would have created another WSDL 1.1:).

<sw>The problem is that defining the format of the stuff at the end of 
the pattern URI would put us, not dangerously close to, but *in* 
choreography territory. I don't think any of wants that right now
do we?</sw>

3. You wrote: 
I suggest that we define the following patterns as a part of our work:
input-output 
input-only 
event (see below) 
Adding event is great (and looks good). I would like to see "output" and "output-input" (equivalents of current solicit-response and Notification) covered as well. Without that we would have just introduced a new syntax w/o really resolving the issue that is the impetus behind all this.

<sw>I think this approach provides a way to define clear and precise 
semantics for any pattern, including the infamous outbound ones. If
we want to do that I can live with it ..</sw>

4. In a generic interaction (syntax) for an interaction, it seems useful to define the order of messages (which goes first,second, etc.), instead of pushing that to the semantics of the pattern. 

<sw>The problem is that order will not typically be just linear. In that
case we're again in the choregraphy camp.</sw>

5. I guess I was supportive of this but, having introduced a lot of new syntax throughout WSDL 1.2, I am wondering if keeping the old "operation" syntax is really worth it. I was thinking from a backward compatibility perspective but, when much of the other syntax is incompatible, trying to keep this for that sake seems unnecessary.  We could however specify default values for the attributes so that most frequently used interaction patterns can be defined with simpler syntax, based on how other parts of the interaction laid out if desired..

<sw>I like the idea of supporting the old syntax for common cases. I'm a
firm believer in "simple things must be simple" ..</sw>

Just a few thoughts..

<sw>Thanks for the thoughts!</sw>

Regards, Prasad

Sanjiva Weerawarana wrote:

At the last call I was asked to write up the interaction pattern stuff
to try to get convergence. Document attached.

Glen, I don't think I did justice to your preferred approach. Please
edit as appropriate ..

Bye,

Sanjiva.