Fw: [business-transaction] issue on participant and serviceidentification

[Mark Little <mark_little@hp.com>]

Forwarded on behalf of Bill Pope.

----- Original Message -----
From: <zpope@attbi.com>
To: "JIM (HP-UnitedKingdom WEBBER), peter.furniss@choreology.com (Peter
Furniss), Mark Little <mark_little@hp.com>" <jim_webber@hp.com>
Cc: "Alex Ceponkus" <alex@ceponkus.org>
Sent: Wednesday, February 27, 2002 4:25 PM
Subject: Re: [business-transaction] issue on participant and service
identification


> Hello, I'm still not able to post to the list.
> Apologies for sending this to such a narrow audience.
> It's all the people I have in this address book.
>
>
>
> The only potential answer I can see with our current
> spec is that this
> information is application specific and would be passed
> in the
> application context.  Cases that had multiple
> participants enrolling
> from a single request would need to distinguish each
> participant (the
> "Dutch Auction").  I don't think  that the participant
> does needs to be
> correlated to a service but instead to the application
> data contained in
> a specific response.
>
> Agreeing with Mark, there is nothing in the spec that
> defines this
> today.  It could be done but would be done ad hoc by
> each application
> but that limits the usefullness of cohesions.
>
> I remember something like the proposed solution too.  It
> would benefit
> from being amended to
> <ServiceType>:<SuperiorId>:<InferiorId>.  The
> service type and Superior ID are assigned by the
> application/decider.
> The InferiorId is assigned by the Inferior to provide
> for multiple
> responses.
>
> That does beg the question as to how multiple responses
> are returned to
> the application.
>
> =bill
> > I remember sending something similar to what follows
> many months ago as more
> > of a discussion point, but I can't find the answer in
> the archives (and I
> > think the suggested solution was fairly vague anyway).
> This is more of a
> > heads-up reminder of a basic problem.
> >
> > Basically, in a traditional transaction system users
> don't see participants
> > they see services or objects. What participants are
> enlisted with a
> > transaction on behalf of those services and objects
> isn't really of interest
> > to the user. When it comes to commit or rollback the
> transaction, it acts on
> > the transaction and not on the individual participants.
> >
> > Now in BTP that's still the case if I work purely with
> atoms. However, in
> > the cohesive world, we're in a completely different
> ball park . Now the
> > "user" has to know explicitly what the participants
> are and how they are
> > tied to services. Otherwise, it can't use business
> logic to say "cancel that
> > insurance quote and prepare that one". How does
> the "user" get this
> > information when all it typically sees is the
> mechanisms to begin and end a
> > cohesion? When an invocation is made within the scope
> of a cohesion+atom
> > then the user will have to remember the atom id. But
> if the invocation is
> > made within a top-level cohesion (no atom) then the
> user will need to
> > somehow keep track of what participants were enrolled
> for each service
> > invocation. Otherwise, if the user simply asks "what
> are the participants"
> > (e.g., via a statuses message) it has no way of
> knowing that participant X
> > was for service Y.
> >
> > Now if memory serves, the original proposed solution
> to this was that
> > participant identifiers could contain service
> identifying text, e.g.,
> > "TaxiService:1234". OK, but this service
> identification needs to be unique
> > too (obviously). If participants can only be used
> within atoms then this
> > becomes less of an issue, but I'm not keen on that
> restriction.
> >
> > The current specification doesn't mention this problem
> at all and paints a
> > fairly rosey picture that cohesions can be used out-of-
> the-box and are going
> > to simplify our lives. If I can't identify which
> participants to
> > cancel/prepare/confirm then this isn't going to
> happen. So, I think whatever
> > we decide (and decide we must) we need to put
> appropriate text in the
> > specification. Otherwise I think people will stick
> with atoms or end up
> > doing things in a proprietary manner which then breaks
> one of the basic
> > principles behind BTP (interoperability).
> >
> > Mark.
> >
> > ----------------------------------------------
> > Dr. Mark Little, Distinguished Engineer,
> > Transactions Architect, HP Arjuna Labs
> > Email: mark_little@hp.com
> > Phone: +44 191 2606216
> > Fax  : +44 191 2606250
> >
> >
> >
> >
> > -------------------------------------------------------
> ---------
> > To subscribe or unsubscribe from this elist use the
> subscription
> > manager: <http://lists.oasis-open.org/ob/adm.pl>
> >
>