[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [ws-tx] Mixed Outcome scenario
Sorry, I am travelling, and with very limited time. But not ignoring the TC's request. I believe we don't meet again till the 21st? I will try to respond by the end of the weekend, very likely before. Alastair Peter Furniss wrote: > Sorry not to get onto this sooner. > > On looking at it more closely, I think 1.12 already has the > characteristics we wanted to demonstrate. It doesn't have to be a single > message sent to one PA - the same message sent to multiple Pas has the > same features: > > This assumes, in 1.12, that PA1 and PA2 are sent exactly the same > message, including all elements of the context. The Register messages > for PS1 and PS2 will then only differ in fields that are opaque to the > coordinator. Although IA/CS will know there are two participants, it > doesn't know which is considered to be PS1 and which PS2. Hence the > need for an identification that is carried in the Register and > understood by CS/IA. > > With these assumptions, 1.12 is modelling an auction or invitation to > tender scenario. A common message and context is "broadcast" to > potential partners who respond with register and are ready to deliver. > The BA protocol is used to signal who wins. (it doesn't need to be a > single 'winner' of course - maybe everyone who meets some criterion is > accepted) > > (if 1.12 is interpreted as sending different contexts to PA1 and PA2, > then it is really demonstrating nested atomic activities) > > The proposal for one PA with two PS's would be the same thing, where the > same party offered more than one response > > > Note that although there has to be an identification carried in Register > and understood by CS/IA, it doesn't have to be specified outside this > application. But the ability to carry it DOES have to be supported by > the WS-BA implemenation and made accessible via its (non-standard) API. > (c.f. you steer with a wheel, a tiller or a joystick but you must be > able to steer). > > In this instance, it would work for the Register to carry a field that > had values PS1 or PS2, and there doesn't need to be anything carried in > the application message. That would apply in reality if the difference > between the offered responses could be summarised in a shortish element. > > In a more general case, there may be a whole lot of information > travelling in the application response - in which case a (sufficiently) > unique field from the application response is sent on the Register. > Again, the applications on each side need to know what it signifies and > the WS-BA implementations need to be able carry it identifiably and > transparently. > > Peter > > >> -----Original Message----- >> From: Ian Robinson [mailto:ian_robinson@uk.ibm.com] >> Sent: 31 August 2006 23:45 >> To: Peter Furniss; Alastair Green >> Cc: ws-tx@lists.oasis-open.org >> Subject: Re: [ws-tx] Mixed Outcome scenario >> >> >> 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 >> >> >> >> >> > > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]