[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: [bt-spec] Deferred BTP Issue 108 : Participant and serviceidentification
This issue has been added to the BTP issue list as a deferred issue, to be considered for a future edition of the spec.
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.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC