[business-transaction] issue on participant and service identification

[Mark Little <mark_little@hp.com>]

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