ws-tx message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: WS-BA: Provide participant identification information for application use
- From: "Peter Furniss" <peter.furniss@erebor.co.uk>
- To: <ws-tx@lists.oasis-open.org>
- Date: Fri, 30 Jun 2006 00:52:42 +0100
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.)
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]