Re: [ws-tx] Mixed Outcome scenario

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

In general, if the number and nature of participants cannot be deduced 
from the number and nature of application requests, then you cannot make 
Mixed Outcome work without participant identifiers without significant 
complexity/additional network traffic at the app level.

Consider any scenario where an application request leads to the 
registration of more than one participant (as in "left", "right").

Consider any scenario where an application request is sent to an unknown 
number of services (broadcast for auction, for example).

Consider any scenario where services poll a hub for expressions of 
interest (Offer to buy: 80 widgets of class X), and the number of 
responses is variable.

Without participant identifiers we need to create as many coordinator 
identifiers as there are participants.

This requires: either a static, one coordinator, one participant 
relationship, or application protocol traffic to retrieve a coordinator 
context that is specific.

L/R example. RA receives app request. RA sends "want to register L" app 
message to IA. Receive back "your unique coordination context for L" in 
response. Now register participant L against context(L).

Forcing segmentation of a single business activity into multiple 
activities on the wire also creates information loss. I can no longer 
use the context's coordinator identifier to track related activities for 
MIS or sysadmin purposes. I cannot use the  unique id to identify and 
correlate application messages between the parties (we're talking about 
transaction 65 here).

By using discrete transaction identifiers I also lose a critical tool 
for managing isolation. Two requests to services that share data can 
identify work as being on behalf of the same activity in an 
application-level isolation scheme of some kind. Knowing that work is 
being carried out for some instance of P Left is not the same thing as 
knowing work is being carried out for P Left on behalf of activity X.

Finally, the use of coordination id (in the case of Mixed Outcome) 
causes more information to be sent than is required:


Peter Furniss wrote:
> 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
>
>
>