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: Issues 79, 77 and others (was RE: [bt-spec] identity)


There's been silence on the suggestion here, but I'd like to get it cleared up because it is one of few open issues that have multiple impact on the xml (unless someone wants to rename everything again :-). If we can get this done, the XML can be revised with some expectation of finality.
 
To summarise:
 
The "Identifier" will be defined as a URI, and therefore as globally unambiguous.
 
All address parameters that have the explanation "the parameter is present to disambiguate the ... identifier" or "with the ... identifier, this determines who the message is from" are deleted from both the abstract messages and the XML.
 
The different kinds of Identifier (transaction, superior, inferior) will be kept as potentially distinct; they will appear in each message as now, and it should not be assumed one identifier will be recognised other than at the address(es) it was offered with (e.g. transaction identifier (in BEGUN) is known at the address-as-decider, it should not be assumed that it is necessarily the same as the superior identificaiton, or will be recognised at the address-as-superior on the related CONTEXT (although in fact they might be the same)
 
Text to adjusted appropriately.
 
Expressions of dissent or assent ? (not a vote)
 
Peter
 
 -----Original Message-----
From: Peter Furniss [mailto:peter.furniss@choreology.com]
Sent: 17 January 2002 00:11
To: 'Bt-Spec '
Subject: RE: [bt-spec] identity

We had a considerable discussion about identity and identifiers earlier this week here in Choreology. This included our implementation group, so we had some hard reality in the mix :-)
 
We concluded that it will help things very considerably if change the identifiers from being only unambiguous in the scope of the (set of) addresses for the role to being globally unambiguous.  Making an identifier globally unambiguous isn't difficult - just making it a URI is sufficient.
 
What we have in the current drafts is kind of an overload of the addresses - they are being used both to route (future) messages to the holder of the state (= location of the actor in that role) and to disambiguate the identifiers. In implemenations where the actor is liable to migrate, and so the set of address is multiple, the disambiguation requires that the identifer is unambiguous among all the places the actor might move to - including potentially ones that currently don't exist and will require redirection to get to.
 
The point raised in issue 78 is that the address parameters only used to disambiguate could be single, even if the original address was a set of several addresses (e.g. ENROL carries several addresses in the address-as-inferior set, but PREPARED need carry only one). However, if that inferior migrates (and uses REDIRECT to say where it has gone), you could get a completely different set of addresses on a later message.
 
The double use of the addresses also adds complexity to the implementation, which has to retain the addresses for comparison purposes, again rummaging through the set.
 
We wondered about defining a simpler rule for matching sets of addresses (e.g. always take first, or having a special "pseudo-binding" that was only used for disambiguation) but then realised that what we were doing was taking advantage of the fact that BTP addresses are always globally unambiguous themselves. It would be simpler, both conceptually, and more significantly, for implementation (everybody's, we suspect), to include the disambiguating "address" in the identifier itself. Then the addresses proper can be used purely for the purpose getting the message to the right place.
 
If we do this, we don't need those address-as-inferior in the Inferior -> Superior messages.
 
There is a question as to whether we make the identifier construct structured - with a disambiguating URI and a separate "suffix", which unambigously identifies the entity (state information) within the scope of that URI; or make the whole thing a URI, taking advantage of the indefinite granularity of URIs (both URN and URL). I slightly lean to non-structured, just saying that it is globally unambiguous.
 
This is different from Alastair's answer to Sanjay below. There wouldn't be an "identity-as-X", including an address, just an "identifier-as-X", which would be specified as globally unambiguous.
 
This doesn't change the basis of Alastair's answer to Sanjay's original question: the reason why the transaction-identifier is on BEGUN and a Superior identifier is on the CONTEXT is because they got to different places and some implementations might want them different.
 
 
On Pyouguk's questions (which I think are essentially the same) : there is no reason why a particular implementation can't make the various identifiers the same, but equally no reason why they can't be different. It's an implementation choice, and I can imagine reasons why either might be preferred. So we specify them as if they were different, allowing perhaps some optimisations if they are the same.
 
Peter (based on discussion with my colleagues here, though not reviewed by them before sending)
 
 
 
 -----Original Message-----
From: Cho, Pyounguk [mailto:PCho@iona.com]
Sent: 15 January 2002 19:25
To: 'Sanjay Dalal'; 'Bt-Spec '
Cc: William Cox; Sazi Temel
Subject: RE: [bt-spec] identity

Hi Sanjay,
    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?
 
<questions>
  <facts>
    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.
  </facts>
  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?
</questions>
 
Regards,
Pyounguk
 
-----Original Message-----
From: Sanjay Dalal [mailto:sanjay@bea.com]
Sent: Tuesday, January 15, 2002 6:46 AM
To: 'Bt-Spec '
Cc: William Cox; Sazi Temel
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