----- Original Message -----
Sent: Tuesday, March 12, 2002 4:17
PM
Subject: [bt-spec] Deferred BTP Issue
108 : Participant and service identification
This issue has been added to the BTP
issue list as a deferred issue, to be considered for a future edition of
the spec.
BTP Issue 108 : Participant and service
identification
Category: minor technical
Submitter:
Mark Little, HP
Note: This issue was discussed on the main btp
list for some while before it was
made an identified issue. Description
is extracted from the first message of that thread
Description:
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).
To comment on this issue, please follow-up to this announcement on the
bt-spec@lists.oasis-open.org (replying to this message should automatically
send your message to that list).
The current draft, with line numbers is available in pdf
format and word
format.
To add a new issue, please email a description of the issue to Peter
Furniss peter.furniss@choreology.com.
Please propose a category (technical, minor technical, editorial, minor
editorial) and whether the issue proposed for the current edition or a
future edition.