OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

bt-spec message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Subject: [bt-spec] identity


Hi Peter,
 
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.
 
thanks,
sanjay 
 
-----Original Message-----
From: Alastair Green [mailto:alastair.green@choreology.com]
Sent: Saturday, January 05, 2002 3:26 AM
To: Sanjay Dalal
 <snip>
 
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> 


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Powered by eList eXpress LLC