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

Re: write-up of interaction patterns

From: Prasad Yendluri <pyendluri@webmethods.com>
Date: Thu, 16 Jan 2003 16:49:02 -0800
Message-ID: <3E2752FE.4000301@webmethods.com>
To: Sanjiva Weerawarana <sanjiva@watson.ibm.com>
CC: www-ws-desc@w3.org
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 

> 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.
Received on Thursday, 16 January 2003 19:48:00 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 23:06:27 UTC