Re: write-up of interaction patterns

Hi Sanjiva,

Somehow this note got stuck way up in my mail hierarchy and just 
noticed. Please see below some follow-up.

Regards, Prasad

Sanjiva Weerawarana wrote:

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

I thought the above was actually the document with instance of the 
interaction (given it is contained in the portType definition). Is it not?
I was suggesting, the schema (generic interaction syntax) for definition 
of specific interaction patterns needs to accommodate roles that are 
optional and multiply present, as in the case of a fault. E.g. an 
instance of a specific interaction pattern (operation) may not have any 
faults to return or may need to return > 1 type of fault (message).

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

I am suggesting we come-up with a concrete syntax and clear guidelines. 
Not really anything close to the level of getting into the choreography 
territory.

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

I guess one can see as that..

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

I am on the wall on this. If you would tug me hard enough I will fall 
that side :)

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