----- 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.