Issue 070 - WS-BA: Provide participant identification information for application use

["Ram Jeyaraman" <Ram.Jeyaraman@microsoft.com>]

This is identified as WS-TX issue 070.

 

Please ensure follow-ups have a subject line starting "Issue 070 - WS-BA: Provide participant identification information for application use".

 

From: Peter Furniss [mailto:peter.furniss@erebor.co.uk]
Sent: Thursday, June 29, 2006 4:53 PM
To: ws-tx@lists.oasis-open.org
Subject: [ws-tx] WS-BA: Provide participant identification information for application use

 

Issue name -- WS-BA: Provide participant identification information for application use
 
PLEASE DO NOT REPLY TO THIS EMAIL OR START A DISCUSSISON THREAD UNTIL THE ISSUE IS ASSIGNED A NUMBER.
 
The issues coordinator will notify the list when that has occurred.
 
Target document and draft:
 
Protocol:  WS-BA
 
Artifact:  spec
 
Draft:  BA spec cd 2
 
Link to the document referenced:
 
http://www.oasis-open.org/committees/download.php/18819/wstx-wsba-1.1-spec-cd-02.doc

 

Section and PDF line number:  section , lines 
 

 

Issue type:  Design
 

 

Related issues:
 
Issue Description:

 

Applications driving WS-BA coordinators need to be able to distinguish which of the
registered participants are responsible for which piece of application work. Some
identifying information has to be carried on (or associated with) the Register message,
and also on application message(s) exchanged between the parties. Both sides need to
be aware of the relationship.
 
Issue Details
 
The WS-C/WS-BA protocol combination must carry participant identification information to enable two facilities, without which WS-BA is unworkable for intended use cases:

 

a) Identification of registered and completed Participants, for “checking” purposes
b) Identification of Participants for selective cancellation/confirmation when using mixed outcome.

 

A [ParticipantIdentifier] element is required in the WS-C Register message whose value is Participant-defined and which allows the application driving the Coordinator to identify participants from an application standpoint. Typically, this identifier will be returned in an application response, and will also be present in the Register message. This allows the application to correlate application responses (e.g. quote details) and Participants.

 

This feature is required, to take one concrete example, by applications using a WS-BPEL or XLANG-like API, where inner scopes may be compensated selectively, and each such scope is named: <compensate scope="foo"/> .

 

The means by which the identifier requirement was avoided for WS-AT (leading to it not being made a base part of WS-C) do not apply to WS-BA, which therefore must provide elements to carry the information. It would not be appropriate to force
all WS-BA-using applications to specify application-specific extensions to WS-C just to make WS-BA usable.
 
Proposed resolution

 

Define new element
 
 [ParticipantIdentifier] : xs:any (0..1)

 

as an extension field in the Register message, whose use is mandatory when registering with a WS-BA Coordinator.

 

This element’s contents are defined by the agent that registers the Participant, and their meaning for the purposes of correlation with application messages that travel between the service and the consuming application is defined by agreement of those two parties, and is not a matter of further concern for the WS-BA specification. (though it would be for anyone specifying a WS-BA api or similar)

 

(Note that this definition is silent on the question of whether the value is application-generated or middleware-generated—this is an implementation issue.)