RE: [bt-spec] Deferred BTP Issue 108 : Participant and serviceidentification

[Peter Furniss <peter.furniss@choreology.com>]

Issue 108 was deferred-on-submission, but concerns a possible bug, so should be addressed.

 

Concerning the main issue - identifying enrolled inferiors in a cohesion, I think we have all we need, with one or two possible omissions/tweaks.

if the initiator/terminator end creates a cohesion, and then creates atoms as immediate subordinates, then it can put the atom context on an invocation, and thus directly knows which is which.

 

with a propagated cohesion context:

On an upcoming enrol, there already is a unambiguous identifier (the inferior identifier). This is visible to the cohesions terminator, on INFERIOR_STATUSES etc. If the terminator can work out which bit of application work this belongs to, it has the unique handle to it. So how to ensure that it can make the link

The enrol could come associated with some application message (e.g. it is the only ENROL in the soap header, and the soap body contains the bid/quote/reservation details etc.). The application can then know that the inferior so enrolled (identified by its identifier) is doing the confirm/cancel for that work. Note that this association is strictly part of the application protocol (or the application+btp protocol, not part of btp. ( In fact the SOAP binding does say that a single enrol in the header is associated to the body - an argument can be made that this is wrong and should be left to the app. pcol and not included in the binding.)

OR The enrol could carry an inferior name qualifier, which by some convention known to the applications allows the app work and the enrollment to be linked. I don't believe there is any need or capability in making this guaranteed unique, though it probably would be often unique. It would be things like "Acme taxis", "BA 23+UA 658", "ABN AMRO:hp option". The point is it must be meaningful to the application, and this more or less precludes it being unique -(think peoples' names, versus their id numbers)

The application message could carry a field that was known to be in the ENROL - this could be the "inferior name", but the identifier would probably be more use, precisely because it is known to be unambiguous. (In fact, I'm not so sure the inferior name is any use on thinking this through). This is clearly an application [protocol] responsibility - the identifier becomes a parameter on their message.

All those are possible with what we already have in the text. The possible improvements are:

there is no statement that an ENROL can be directly associated with an application message unless it is a related-group with context-reply. It ought to be possible to associate them directly, with a naked enrol in the header (for example) - if the address usage makes this feasible. BUT, since this association is really an application matter, it can be argued that we don't need to say anything, as it is already implicit.

If the address usage means that context-reply *must* be used to send the enrol back in association with the app msg (i.e. the Superior address is not the same as the applications, but they need to be sent together), then it is possible there will be more than one context-reply sent back, which means one (at least) must have a completion flag meaning "not-completed" - which isn't a valid value at the moment.

In fact, the description of CONTEXT_REPLY currently mis-uses "completed" in this case, to mean (effectively) incomplete.

So, I've put in a proposed solution (included in 0.9.2.4, 0.9.3) to add "incomplete" as a value for the completion-status of CONTEXT_REPLY.

 

Other clarifications are probably best considered as review comments, especially on the model (or the primer)

 

Peter

 

 

-----Original Message-----
From: Mark Little [mailto:mark_little@hp.com]
Sent: 12 March 2002 18:08
To: bt-spec@lists.oasis-open.org; Peter Furniss
Subject: Re: [bt-spec] Deferred BTP Issue 108 : Participant and service identification

I believe this problem was raised before the decision to defer everything. In our opinion, being able to tie participants in some way to services is so critical to the use of cohesions that without it it's hard to sell them on their useability. As such, we'd like to get this resolved within the 1.0 timeframe.

 

Mark.

 

----- Original Message -----

From: BTP issues maintainer

To: bt-spec@lists.oasis-open.org

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.