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