Generalizing Operations

(Updated to be consistent with the proposal to remove <message>)

Sanjiva Weerawarana, January 18, 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.

This updated version is built upon the proposal to eliminate the <message> construct from WSDL 1.2.

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">+[sgg1] 

3       <message role="uri">+

4          <part [name="xsd:string"] type-indicator [cardinality-indicator]/>*

5       </message>

6    </interaction>

7 </portType>

Lines 2-6 define an interaction. An interaction has a name (an ncname scoped by the standard TNS with the same rules as current operation names [sgg2] ) 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. A message is simply a grouping of a set of things that constitutes the data that flows as a unit in some direction during this interaction. The role of the message (and its directionality etc.) are all clarified by the role attribute. The contents of the message is defined as a set of parts, where each part is typed and may occur multiple times. The attributes of <part> are the same as those of input/output/fault in the proposal to remove message (see remove-message-jan-18-2003.html) and hence are not re-defined here.

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 [sgg3] , 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. In particulare, it will not define a format for the information contained at that URI (if any).

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 suggestion 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)[sgg4]

If there's a desire to define patterns for specific usages of outbound operations we can do that too. However, note that the WSDL 1.1 style short-cut syntax will only be able to support one semantic for the outbound operations (which is good of course as that'll force us to clarify the semantics of the outbound syntax).

2.1 Defining the Input-Output Pattern

The proposed syntax for this pattern is:

 1 <portType name="ncname">

 2    <interaction name="ncname" 

 3                 pattern="http://www.w3.org/2003/ws/desc/patterns/input-output">

 4       <message role=".../patterns/input-output#input-message">

 5          <part [name="xsd:string"] type-indicator [cardinality-indicator]/>*

 6       </message>

 7       <message role=".../patterns/input-output#output-message">

 8          <part [name="xsd:string"] type-indicator [cardinality-indicator]/>*

 9       </message>

10       <message role=".../patterns/input-output#fault-message">*

11          <part type-indicator/>

12       </message>

13    </interaction>

14 </portType>

Thus, this pattern would have two required messages, one playing the input role and the other playing the output role. In addition, it could have zero or more messages one of which may be returned by the server instead of the output message. 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 operation syntax shown in the eliminating message proposal as a syntactic shortcut for precisely the above:

1 <portType name="ncname">

2    <operation name="ncname">+

3       <input [name="xsd:string"] type-indicator [cardinality-indicator]/>*

4       <output [name="xsd:string"] type-indicator [cardinality-indicator]/>*

5       <fault type-indicator/>*

6    </operation>

7 </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.[sgg5] This is basically the proposal I made in November.

1 <portType name="ncname">

2    <event name="ncname">

3       <subscription xsdType="qname"/>

4       <unsubscription xsdType="qname"/>

5       <notification portType="qname"/>

6    </event>

7 </portType>

The event is named and contains a subscription message which is an XSD complexType, a notification message (a complexType) and a notification portType. The subscription information must be sent to the service to subscribe to events. Part of the subscription information must be a service reference for the service to which the notifications must be delivered. The portType that that service must support is indicated by the notification element.

[NOTE: This small explanation is not meant to be a spec-speak quality definition of the semantics of the proposed <event> element. If the WG wishes to move in this direction it will be my pleasure to write a draft of such a specification.]

3. Defining a General Interaction Pattern - Option 2

[This section has not been updated on Jan. 18, 2003.]

An alternative approach to defining general interaction patterns is to use a modification of the current syntax as the generalization. The proposal (advocated by some on the WG, not me![sgg6] ) 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.)