Re: [ws-tx] Mixed Outcome scenario

[Alastair Green <alastair.green@choreology.com>]

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