[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: Re: [business-transaction] Re: [bt-spec] URIs and address-as-X (M AJOR)
> I'm stealing time from some charmless administration tasks, so I will be brief, > and may inadvertently sound curt. I may also be tardy in replying to any replies Ditto. > We discussed all of this about two weeks ago. That's good but it obviously doesn't preclude us discussing this in a much wider audience. [lots of stuff deleted.] > g) This is getting ridiculous: why waste our time conflating addresses with > transaction ids: just state the rule that the tid is a URI and let addresses be > addresses. The overload is confusing and unnecessary, and gives zero benefit. OK, this all sounds exactly like what we have been proposing for the last 2 days. Or have we missed something? > Also, not all carrier protocols can be relied upon to transmit user data in the > address to the recipient, and some addresses may be malformed if they attempt to > carry user data (I suspect Java RMI fits into both these categories at once). I think there is definitely some confusion about what we are describing. We want a separation between BTP payload (information necessary to conduct the transaction) and the delivery information (information necessary to deliver the payload). Currently the specification mixes these up and this is what is wrong in our opinion: if a BTP message/operation requires a transaction id, for example, and that tid is now embedded in the delivery URI (for uniqueness) then the tid *must* also occur in the payload. You are correct in saying that if the tid was in the "delivery" information only then the higher-level layers simply wouldn't be able to have access to it in all circumstances. Take a specific example: suppose the end point for some entity that implements XAResource is identified by some CORBA reference and we decide to embed the tid in the IOR and remove it as a parameter from all of the xaEnd et al methods. This simply wouldn't work since the resource could not determine which transaction it was being told to prepare/commit/rollback on behalf of now unless it inspected its own address - not a good idea. However, if we leave the xid in then all works well and good. What we're saying is that replace all addresses with URIs and make the tid a URI. If the tid needs to go in the payload in order to conduct the operation (c.f. xaEnd) then it goes in the BTP payload as well. If it doesn't, then it doesn't! > Therefore, you can never eliminate the need for optional addressing information, And as I said yesterday, if we want additional addresses for fail-over/redirect then they would go in the BTP payload too. > and if you want to make an address globally unique it must be unique across > "carrier protocol address" and "optional addressing information", so ... URL > alone cannot be generally good enough to capture global uniqueness, unless it is > a special btp:// URL which we have to define, which indirects the > abstract-to-concrete mapping that must take place anyway. Mark. ---------------------------------------------- Dr. Mark Little, Distinguished Engineer, Transactions Architect, HP Arjuna Labs Email: mark_little@hp.com Phone: +44 191 2606216 Fax : +44 191 2606250
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC