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>

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.

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

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.

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.

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

Just a few thoughts..

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.
>  
>
>
> ------------------------------------------------------------------------
>
>
>   Generalizing Operations
>
> Sanjiva Weerawarana, January 13, 2003
>
>
>     1. Introduction
>
> This document is an attempt at summarizing the conclusion of several 
> months of discussions and proposals on how to generalize the 
> "operation" concept to support other kinds of message exchanges than 
> the ones supported in WSDL 1.1 (input-output, input-only and the 
> infamous output-oriented versions of these two).
>
> There now appears to be general consensus to generalize operations. 
> This document illustrates two possible syntactic approaches for doing 
> that; one which uses a new construct for the most general concept and 
> custom syntax for specific patterns we (the WG) identify. The other 
> approach is to extend the current operation syntax.
>
>
>     2. Defining a General Interaction Pattern - Option 1
>
> The new syntax proposal is as follows:
>
>1 <portType name="ncname">
>2    <interaction name="ncname" pattern="uri">+
>3      <message messageType="qname" role="uri"/>+
>4    </interaction>
>5 </portType>
>
> Lines 2-4 define an interaction. An interaction has a name (an ncname 
> scoped by the standard TNS with the same rules as current operation 
> names) and identifies the "kind" of interaction by indicating the 
> pattern that that interaction supports. The pattern is identified by a 
> URI. Within the interaction element there may be one or more messages 
> listed (line 3), where each message is a message that flows either to 
> or from the service. The role of the message (and its directionality 
> etc.) are all clarified by the role attribute and the kind of message 
> is declared by the messageType attribute which will reference a 
> previously defined <wsdl:message>.
>
> The semantics of an interaction are defined by whatever specification 
> that identifies the pattern URI as its interaction pattern identifier. 
> If the WSDL processor does not understand the pattern URI, then it 
> does not understand this interaction. The role that each message plays 
> in an interaction is also defined by a URI, the role URI, which must 
> also be defined by the specification that defines this interaction 
> pattern.
>
> WSDL 1.2 will not specify whether or whether not deferencing a pattern 
> URI or a role URI will result anything useful.
>
> WSDL 1.2 will only have the above as <interaction> element as the 
> mechanism to define new patterns. However, it will define a few 
> "well-known" / "widely-used" patterns for people to use in an 
> interoperable manner. When defining an interaction pattern, we can 
> either require users to use the generic syntax to define a usage of a 
> given pattern or provide custom syntax for these patterns. My suggest 
> is that we provide custom syntax for those patterns that we will 
> identify and define.
>
> I suggest that we define the following patterns as a part of our work:
>
>     * input-output
>     * input-only
>     * event (see below)
>
> If there's a desire to define patterns for specific usages of outbound 
> operations we can do that too.
>
>
>       2.1 Defining the Input-Output Pattern
>
> The proposed syntax for this pattern is:
>
>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    </interaction>
>6 </portType>
>
> Thus, this pattern would have two messages, one playing the input role 
> and the other playing the output role. The explanation that is 
> currently embodied in the specification for the semantics of 
> input-output operations would be the definition of this interaction 
> pattern.
>
> Because of the frequent usage of this pattern, I suggest we define the 
> current operation syntax as being a syntactic shortcut for precisely 
> the above:
>
>1 <portType name="ncname">
>2    <operation name="ncname">
>3       <input message="qname"/>
>4       <output message="qname"/>
>5    </operation>
>6 </portType>
>
> Note that this is a syntactic convenience only; the semantics of 
> input-output operations will be defined by the semantics given to the 
> pattern URI indicated above.
>
>
>       2.2 Defining the Input-Only Pattern
>
> This is basically the same as above, except that the output message is 
> removed.
>
>
>       2.3 Defining the Event Pattern
>
> I suggest that we also define the languages like Java, JavaScript, 
> ActiveX, C# etc.. Note that this "event" pattern as found in is not 
> intended to be sufficient for the most general pub-sub 
> infrastructures. This is basically the proposal I made in November.
>
>1 <portType name="ncname">
>2    <event name="ncname">
>3       <subscription message="qname"/>
>4       <notification message="qname"/>
>5       <listener portType="qname"/>
>6    </event>
>7 </portType>
>
> The event is named and contains a subscription message, a notification 
> message and a portType via which the notification message will be 
> delivered to the recipient.
>
>
>     3. Defining a General Interaction Pattern - Option 2
>
> An alternative approach to defining general interaction patterns is to 
> use a modification of the current syntax as the generalization. The 
> proposal (advoced by some on the WG, not me!) is as follows:
>
>1 <portType name="ncname">
>2    <operation name="ncname" [pattern="uri"]>
>3       <input message="qname" [role="uri"]/>*
>4       <output message="qname" [role="uri"]/>*
>5    </operation>
>6 </portType>
>
> The pattern is like in Section 2- it provides the semantics for the 
> overall operation and the role attribute on the input and output 
> operations will be similar as well.
>
> The proposed approach for defining the convenience syntax for a few 
> well-known patterns is to basically provide default values the 
> pattern/role attributes. Thus, in effect, the absence of the pattern 
> and role attributes with one input and one output element would 
> signify an input-output operation.
>
> There are however difficulties with this approach:
>
>     * Because of the proposed order sensitivity of the <input> and
>       <output> child elements in this approach, the message role
>       definitions overlap with semantics captured elsewhere (e.g., in
>       a BPEL4WS document) and will be restrictive (the possible
>       interaction patterns will be constrained by the
>       regular-expression scope of linear specification.
>     * It will be impossible to provide the convenience syntax and two
>       different semantics (i.e., provide two diffferent pattern URIs)
>       for the two different styles of using outbound operations as we
>       would need to select one default value.
>
> (And more .. but its late now.)
>