Revised MustUnderstand Proposal

[Greg Pavlik <greg.pavlik@oracle.com>]

And inline this time for Doug....

There is currently a problem with respect to Must Understand semantics 
(MUS) in WS-CAF: the context type is a neutral type that can be used to 
represent an activity of a single protocol domain. For example, a 
Context may include a URI indicating the activity is an atomic 
transaction type. At the same time, the specifications want to preserve 
MUS associated with SOAP processing rules. These rules are associated 
specifically with the outermost XML element type in the SOAP headers, 
not data elements within the enclosing header element.

This proposal seeks to resolve this problem with the following 
recommendations:

1) To preserve compatibility with the SOAP processing model, protocols 
should subtype the base context type with a derived type specific to the 
protocol domain. For example, an atomic transaction protocol would 
define an atomic transaction context type that would be useable in the 
context of the SOAP processing rules.

2) The type element in the base context type becomes redundant to the 
information encoded in the enclosing context element based on this 
proposal. However, many protocols have "subprotocols": for example, many 
TP monitors support two phase commit and synchronization capabilities. 
To eliminate the redundancy and to support subprotocols, zero or more 
subtype elements may be included in the context structure. The values of 
the subtype URIs and their semantics are defined by referencing 
specifications.

Subprotocols are of interest in establishing relationships between 
services. This is properly the domain of WS-Coordination Framework. The 
RegistrationContext should provide infrastructure/syntax to support 
lists of subprotocol zero or more URIs in RegistrationContexts. It 
should also allow services to pass lists of zero or more subprotocols to 
a service when registering for membership in an activity group; group 
members so registered will receive subsequent signals specific to the 
subprotocol set for which it has registered interest. A registration 
message without subprotocols included is assumed to represent the 
complete set of subprotocols.