[dais-wg] Top-Level Operations in DAIS

[Norman Paton]

At various points, DAIS-WG members have expressed an interest in there 
being top-level operations in the WS-DAI specifications, and not just 
the more narrowly-defined operations in the relational and XML 
realisations.  This message seeks to encourage thought and interaction 
on the role and nature that such higher-level operations might play.

The current WS-DAI specification identifies two generic operation 
templates: a request-response template and a factory template.

The request-response template is of the form:

<wsdai:RequestMessage>
   <wsdai:RequestDocument/>
   <wsdai:ResponseType/>?
</wsdai:RequestMessage>

where RequestMessage and RequestDocument are replaced by specific names 
in realisations.  The ResponseType contains the QName of a type in the 
property RequestMessageResponseTypeList, which is also renamed in 
specific realisations.

A top-level operation could be defined in line with the above by:

1. Providing a concrete name for the RequestMessage (such as DAIExecute).
2. Providing a property that describes the supported types for the 
RequestDocument.

Note that there may be a many-to-many relationship between 
RequestDocument types and associated ResponseTypes, and that not all 
combinations can be expected to be valid.  As such, a more precise 
characterisation of the valid operations would be to have a single 
property that contains pairs of QNames associating RequestDocumentTypes 
and ResponseTypes.

The provision of a top-level request-response operation opens the 
question as to the relationship to the realisations.  At the moment the 
relationship is simple:

- The WS-DAI specification defines no operations and thus all 
operartions are in the realisations.

If WS-DAI does define a request-response operation, then there are 
choices for realisations:

1. Use only the generic operation, and remove the operations that 
currently instantiate the template from the realisations. The 
realisations then specifiy valid RequestDocumentType and ResponseType 
pairs.
2. In realisations, define specific operations and provide no sanctioned 
support for the generic operations.
3. In realisations, define specific operations as well as specifiying 
valid RequestDocumentTypes and ResponseTypes pairs.

The factory message template is of the form:

<wsdai:RequestMessage>
   <wsdai:RequestDocument/>
   <wsdai:BehavioralProperties/>
</wsdai:RequestMessage>

where RequestMessage, RequestDocument and BehavioualProperties are 
replaced by specific names in realisations.  The valid set of 
BehavioralProperties schemas may be defined in the 
RequestMessagePropertyTypeList, and both the WS-DAI specification and 
the realisations identify properties that may apply in different cases.  
The response to the message is mapping-specific, but is a 
wsa:EndPointReference in the WSRF mapping provided in the WS-DAIR 
specification. Note that the BehavioralProperties document SHOULD 
contain the QName of the portType that is required to access this resource.

A top-level operation could be defined in line with the above by:

1. Providing a concrete name for the RequestMessage (such as DAIFactory).
2. Providing a property that describes the supported types for the 
RequestDocument.

The provision of a top-level factory operation opens the question as to 
the relationship to the realisations.  At the moment the relationship is 
simple:

- The WS-DAI specification defines no operations and thus all 
operartions are in the realisations.

If WS-DAI does define a Factory operation, then there are choices for 
realisations that are similar to those for request-response:

1. Use only the generic operation, and remove the operations that 
currently instantiate the template from the realisations. The 
realisations then specifiy recognised RequestDocumentTypes.
2. In realisations, define specific operations and provide no sanctioned 
support for the generic operations.
3. In realisations, define specific operations as well as specifiying 
valid RequestDocumentTypes.

Note that the WS-DAI Factory template is in some ways more general than 
the WS-DAI RequestResponse template, as the capabilities of the service 
that provides access to the resource returned by the factory operation 
are effectively a parameter of the Factory operation (the QName of the 
relevant portType).  This is as flexible as the use of an "any" type as 
the result of a request-response operation.

The pros and cons of the three options for the specifications are 
similar in both cases:

A disadvantage of defining only rather generic operations as in (1) is 
that tooling can make few assumptions about the available message 
parts.  An advantage is the uniform exploitation of an explicitly open 
mechanism.

An advantage of (2) is that the tooling can help more; a disadvantage is 
that it leaves the top-level operations looking a bit stranded.

An advantage of (3) is that it both exploits the flexible framework and 
allows tighter message typing, at user selection; a disadvantage is that 
the specification may be felt to provide too much choice; it also makes 
the specifications slightly longer and a little harder to implement.

It would be interesting to see a discussion of the pros/cons of the 
alternative options, and to hear how much support there is in general 
for the generic top-level operations. 

Regards, Norman