[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)
Hi Jim, 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 ... We discussed all of this about two weeks ago. The reasoning which resulted in our proposal was as follows: a) got to have globally unique transaction ids: therefore axe the old "id" and use <address> as the id, by stating that each address must be globally unique b) if each address in the address vector is globally unique then we can pull one out and use it as the id c) promulgate a rule for which address should be pulled out: obvious rule is: the first (as it is always present, and any will do). [The scheme which says "choose the one you're using for communication as the id" deprives us of a reliably constant value for the id, and creates a plethora of nasty implementation/admin problems]. d) now, replace the old id by the "first address" to avoid sending address *vectors* all over the place e) what is the value of the "first address"? Answer, any valid URI (need not be a recognized carrier protocol URL, because the extensibility rules dictate that I may receive an "address" for a protocol that the impl doesn't recognize, or that is not specified in the spec (which specifically provides for unknown protocols) f) create a URI which has no relationship to any network protocol (i.e. is not a URL) and put it in the first slot in the vector -- it will come back to me as the transaction id (can't stop me doing this, makes my life as implementer simpler because transaction ids are produced according to a general rule and within a slice of the global namespace I own, like cohesions.com/octaword-as-hexstring or a URN form as Peter suggested. 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. Incidentally, the further away the "address-as-transaction-id" travels in the tree, the less "address-ness" it has, and the more "id-ness" it has (this is beginning to sound like Hegel). 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). Therefore, you can never eliminate the need for optional addressing information, 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. Alastair "WEBBER,JIM (HP-UnitedKingdom,ex1)" wrote: > Monring Peter, > > > I think no identifier should be expected to be resolved to > > any endpoint by any means. > > So an indentifier shouldn't be used to "dereference" the thing it > identifies. Hmm, this seems somewhat strange, maybe we could change its name > to an "un-identifier." > > > No, on our scheme you would use that in a fully interoperable > > exchange. The identifier is independent of the binding. It is > > used only to identify the state (not the communication > > endpoint). The address(es) define an > > endpoint(s) where the state can be found, using the identifier. > > I understand this, the addressing in the current revision is very rich > indeed and can be used to deal with a whole bunch of protocols. > > However I don't think we are in the game of building a protocol bridge. The > addresses in the abstract sense will have to be concrete at some point. If > we assume a homogeneous transport protocol then we can actually optimise > this at the binding stage. > > > Don't worry about the place the address belongs to - it can > > make its address and its logic align how it pleases. Worry > > about the sending side, which must take the address (our > > scheme) or URI (your scheme) and work out what goes where in > > what protocol. The address above, and the rules on addresses > > are defined as - put the additional-information in the > > message (special rules for relatedgroup, which is treated as > > a unit for this purpose), combine any number of messages with > > the same binding address in a bundle; put the bundle in SOAP > > header or body on an http request (or, defined > > circumstances, response) in accordance with various rules. For your > > scheme, btp-soap-http-1 specification has got to say the > > equivalent of all that, plus something about splitting the > > URI to find the http bit. (your scheme can merge > > additional-information and identifier proper) > > Right, and this is where the spec is cumbersome because it does not factor > out logistical parts of a message from the "active" BTP payload. > > > Yes - your approach may simplify the presentation of the > > abstract message set, but it greatly complicates the > > specification of the binding, including the soap/http binding > > we are including. > > I don't think it does. Assuming we are designing a coordination framework > and not a protocol bridge I think the simplification of messages is a good > one since the bindings become one-off chunks of (hard) work, rather than a > continuous drain on the resources of an BTP coordination service. > > Jim > > ---------------------------------------------------------------- > To subscribe or unsubscribe from this elist use the subscription > manager: <http://lists.oasis-open.org/ob/adm.pl>
begin:vcard n:Green;Alastair tel;cell:+44 795 841 2107 tel;fax:+44 207 670 1785 tel;work:+44 207 670 1780 x-mozilla-html:FALSE url:www.choreology.com org:Choreology Ltd version:2.1 email;internet:alastair.green@choreology.com title:Managing Director adr;quoted-printable:;;13 Austin Friars=0D=0A;London;;EC2N 2JX; fn:Alastair Green end:vcard
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC