RE: [bt-spec] identity

I guess Alastair's description clarifies the confusion to some extent. And yet, the relationship among Context, TrID, and SupID in terms of their usage is not very clear in the spec. I'm inserting the related questions from my feedback for 0.9.0.2 version I sent out last time. Can anybody make them clear?

Context created by Factory includes SuperiorID but not TrID(TrID is optional for subcomposer/coordinator enrollment).

Exchanges between Superiors and Inferiors use SuperiorID.

Application sends Context to Factory if necessary.

Application sends Context with application messages to Participant, which responds with Context_Reply.

Application, as the Terminator, sends TrID to Decider.

Isn't it enough just to pass around TrID to keep track of things for the transaction?

What advantages do we get by using Context, SuperiorID, and TrID for different relationships?

How are they differnt from each other in terms of coverage of a given transaction tree especially when it has branches?

Why should TrID be separated from Context?

How is SuperiorID different from TrID?

What are the life cycles of each of them?

How shoud values like transaction timelimit defined inside Context be used for messages between Superiors and Inferiors?

This is a formal request to open an issue on defining the concept of identity in BTP. I am including the mail conversation between Alastair, myself and you fellows at Choreology for reference.

The point I was making was:

How come CONTEXT does not carry transaction-id returned in BEGUN? Is superior-identifier in CONTEXT the same as transaction-id of BEGUN?

Alastair has proposed one solution below which seems good as it makes Identity consistent.

Hi Sanjay,

<snip>
On your second point. If we take the XML encoding then a BEGUN looks something like this:

<btp:related>
<btp:begun>
. . .
</btp:transaction-identifier>
</btp:begun>
<btp:context>
. . .
</btp:superior-identifier>
</btp:context>
</btp:related>

(The existing XML example of BEGUN in the spec does not show this relationship. I believe I have shown the post-Liberty corner view correctly: Alex, Peter, Tony?).

The transaction-identifier is the identifier of the transaction in its role as a Decider. In other words, it is used in conjunction with the address-as-decider by a Terminator for the purposes of sending messages that are part of the Control (Terminator:Decider) relationship.

The superior-identifier is the identifier of the transaction in is role as a Superior. In other words, it is used in conjunction with the address-as-superior by an Enroller or Inferior for the purpose of sending messages that are part of the Outcome (Superior:Inferior) relationship.

There is nothing to stop these identities (identity-as-decider, identity-as-superior) being identical. They are highly likely to be identical in a concrete implementation. They are split out because the CONTEXT is an independently usable message which can be used to create associations with application messages.

Peter is pressing me to review the text in detail, which I am struggling to combine with the usual fund-raising that is my lot. So here is a set of comments on what I have just said:

I believe we have an issue to reinstate the concept of "Identity = Address + Identifier". From this it would follow, in my view, that the abstract message set should speak of "identity-as-superior", "identity-as-decider" in all places, avoiding the breakdown being repeated in every place of use.

The binding pro-forma should specify that the the encoding of an identity must be defined. I would propose that the XML encoding (the only one we currently have) defines a compound element thus:

<identity-as-superior>
</addresses>
</identifier>
</identity-as-superior>

and the like in all other appropriate places. This would happily finesse away the current inconsistency, whereby a decider has a "transaction identifier" while a superior has a "superior identifier".

<snip>

Best wishes,

Alastair

<snip>

bt-spec message