Hi Doug,
The reason we shouldn't do this is that it avoids testing or
exemplifying the real-world use/requirement of mixed outcome.
Can you give me a use-case where a controlling application tells a
coordinator at random to close one and compensate another?
Imagine Avis, Hertz and Alamo offering quotes to Orbitz, who then offer
the best to the customer as part of a fly/drive/hotel package.
Orbitz is not going to close 1, and compensate 2 and 3, where 1, 2 and
3 are the (arbitrary) order of response to an initial request for quote.
They are going to close Avis and compensate Hertz and Alamo. To do that
they need to know that Avis is #2.
Alastair
Doug Davis wrote:
Why can't we just have this:
IA sends MixedOutcome to PA
PA registers PS1 and PS2
PS1 and PS2 send Completed to CS
CS responds Close to one of them,
and
Compensated to the other
How the CS manages to keep track of
it is up to the CS. All we need to have happen is that one of them
(1st or 2nd) gets a Close and the other one (2nd or 1st) gets a
Compensated.
Nothing more complicated than a simply counter kept within the scope
of this Tx/scenario is needed.
Seems a lot easier than having some
new data that we need to standardized for the interop.
thanks,
-Doug
As requested:
Problematic scenario:
IA sends app message Mixed to PA which contains a single BA
mixed-outcome
context. [In passing: sending two contexts is liquidating the concept
of
mixed outcome, which means: different outcomes for different
participants
registered with the same business transaction.]
PA registers PS1 and PS2. PS1 is defined as being the first participant
registered, and PS2 as the second. One of the PS covers application
activity
"One" and one covers activity "Two". PS1 cannot be
assumed to map to "One", nor PS2 to "Two".
CS wants to send Close to "One" and Compensate to "Two".
Should CS send Close to PS1 or PS2?
Workable scenario:
IA sends app message wsba-scenario:Mixed to PA which contains a single
BA mixed-outcome context.
PA sends app message wsba-scenario:MixedResponse to IA, containing
elements
/MixedResponse/One and /MixedResponse/Two. These appear as:
One>{one URI}</One> and <Two>{another URI}</Two>.
PA registers PS1 and PS2. PA adds element
/Register/ParticipantIdentifier,
whose value is either (one URI} or {another URI}.
CS sends Close to PS registered with identifier {one URI}, and
Compensate
to that with identifier {another URI}.
Criterion for success: .
PS for One is closed, PS for Two is compensated.
Notes
A. This could be done with /MixedOne - /MixedOneResponse and /MixedTwo
- /MixedTwoResponse (i.e. two IA-PA exchanges).
B. If separate contexts are used then the initial message /Mixed now
contains
/Mixed/One and /Mixed/Two, which appear as:
One>{one context}</One> and <Two>{another
context}</Two>.
PS for One registers with {one context}and PS for Two with {another
context}.
In both cases the correlation One = X and Two = Y (where X and Y are
identifiers
which are unambiguous in the scope of the transaction instance) must be
mutually understood by IA and PA.
If the correlation is established in advance (hard-wired in the spec of
the scenario, analogous to saying Car Rental is "Car" and Airline
Reservation is "Air"), then the one-context approach requires
no /MixedResponse message, and presence of an identifier on each of the
Register messages.
In the two-context approach the /Mixed must contain two contexts, and
their
relationship to One and Two must be expressed as before.
C. In general: the two-context approach a) liquidates the shared
identity
of the transaction, and b) requires that the IA knows how many
participants
will be registered, and their identities, i.e. demands static
configuration
or transaction "shape".
The one-context approach a) requires a participant identifier in
Register,
b) allows dynamic, late-shaping of the transaction, and c) retains the
shared identity of the transaction.
The two-context approach is tantamount to removing Mixed Outcome; the
one-context
approach (use of Mixed Outcome) cannot be handled without participant
identifiers.
Alastair
Ian Robinson wrote:
We were unfortunately unable to complete the
discussion
with Alastair today
on the scenario he described in which a single application message
resulted
in multiple participant registrations. We did agree, within the TC, to
add
a mixed outcome scenario in which 2 PAs register one participant each -
PS1, which will ultimately be closed, and PS2, which will ultimately be
compensated.
The TC wishes Alastair or Peter to describe in more detail (i.e showing
the
required message flows in the manner of existing scenarios) a mixed
outcome
scenario in which the IDENTITY of the registered participant needs to be
communicated in some way.
Once we have such a scenario, we can then discuss whether or not this is
something that we believe is in scope for the the MixedOutcome
coordinator
type and, if it is, whether or not the existing specification actually
enables this to be implemented.
We can schedule discussion of any such detailed scenario on the TC
telecon
on Sep 21.
Regards,
Ian
"Peter Furniss"
<peter@furniss.co
.uk>
To
<ws-tx@lists.oasis-open.org>
31/08/2006 07:47
cc
<peter.furniss@erebor.co.uk>
Subject
[ws-tx]
Mixed Outcome scenario
Following the discussion yesterday, I'd suggest the following as an
outline of a scenario for Mixed Outcome:
IA sends application request to PA, with Mixed Outcome context
PA registers two participants "left" and "right" for
participant
completion, and replies
PA completes both participants
IA orders close of "left" and compensation of "right".
(only have a few minutes now, so elaborate with appropriate terminology
etc. And "left", "right" could be changed (in
the scenario
specification, not the implementations) to anything else - key thing is
the participant's "left" will close, "right" will compensate)
However, I believe to make that work, we will find we need to reverse
the no-change decision on participant identifiers. IA's "view"
of the
participants must allow it to know which is "left" and which
"right".
This doesn't require standardisation of "left" and "right"
outside the
scenario definition. It DOES require that the heterogeneous ws-c+ws-ba
implementations can pass a field on at least one message that is put in
by PA and received by IA.
Other variations - including coordinator completion, cancel one,
complete other would also be useful.
You will see this email is sent from a different address. I'm leaving
erebor today and joining another company on Monday. I'm not sure whether
I'll get messages from the distribution in the meantime, so please cc:
peter@furniss.co.uk
on replies. (but I'll respond faster on
peter.furniss@erebor.co.uk
until about 17:00 uk time today)
Peter
------------------------------------
Peter Furniss
phone: home +44 20 8460 8553
office +44 20 8313 1833
mobile +44 79 51 53 61 68
email: peter@furniss.co.uk
web: www.furniss.co.uk
|