[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [ws-tx] Issue 014 - WS-C: EPR equality comparison is problematic
And, replying to myself ... Whatever means of Register replay is selected, the ability to detect a duplicate registration depends on the ability to identify which participant the Register refers to, otherwise "duplicate" and "same" have no meaning. The RegistrationService must be able to compare message n and message m, and determine that they refer to the same registrant. At present, the EPR is the only means provided of identification. Either it must be comparable, or another comparable identity must be provided. Alastair Alastair Green wrote: > Ian, > > I am sympathetic to the idea of avoiding EPR comparison, and that goal > might steer us towards a different solution (provision of participant > identifiers, cognate to the context [transaction] identifier, as a > separate element in the Register message). > > However, I am not convinced that the issue will disappear if 7 and 8 > are resolved appropriately. > > WS-BA MixedOutcome requires a participant identification capability, > as described in the latter half of the issue description, to work > correctly. And WS-BA MixedOutcome is required to support > sub-transactional and selective compensation behaviours for a wide > variety of potential applications, including the </compensate > scope=/name/> feature of WS-BPEL. > > Alastair > > Ian Robinson wrote: >> >> >> Depending on the outcomes of issues 7 and 8, this may be a non-issue. >> ws-tx should avoid the need for EPR comparison if at all possible. >> >> Regards, >> Ian Robinson >> STSM, WebSphere Messaging and Transactions Architect >> IBM Hursley Lab, UK >> ian_robinson@uk.ibm.com >> >> >> >> "Peter >> Furniss" >> <peter.furniss@ch >> >> oreology.com> To >> >> <ws-tx@lists.oasis-open.org> 10/12/2005 >> 12:44 cc >> >> >> Subject [ws-tx] Issue 014 - >> WS-C: EPR equality >> comparison is problematic >> >> >> >> >> >> >> >> >> >> >> This is hereby declared to be ws-tx Issue 014. >> >> Please follow-up to this message or ensure the subject line starts Issue >> 014 (ignoring Re:, [ws-tx] etc) >> >> The Related Issues list has been updated to show the issue numbers. >> >> >> Issue name : WS-C: EPR equality comparison is problematic >> >> Owner: Peter Furniss >> >> Target document and draft: >> >> Protocol: Coord >> >> Artifact: spec / schema >> >> Draft: Coord spec working draft uploaded 2005-12-02 >> >> Link to the document referenced: >> >> http://www.oasis-open.org/committees/download.php/15738/WS-Coordination- >> 2005-11-22.pdf >> >> WS-Coordination schema contributed by input authors, not yet uploaded to >> Working Drafts folder >> >> Section and PDF line number: >> >> Coord: Section 4.6 "Already Registered", ll. 460-468 >> >> >> Issue type: Design >> >> >> Related issues: >> >> Issue 007 - WS-C: Make Register/RegisterResponse retriable >> Issue 008 - WS-C: Remove fault 4.6 AlreadyRegistered >> >> >> Issue Description: >> >> EPR comparison to establish identity of participants is problematic. >> Additional mechanism required to identify Participants. >> >> >> Issue Details: >> >> [This issue stems from Choreology Contribution issues TX-15, TX-16 and >> TX-20.] >> >> The latest, 17 August 2005, Candidate Recommendation version of >> WS-Addressing >> >> "Web Services Addressing Core -- 1.0", >> http://www.w3.org/TR/2005/CR-wsaddr-core-20050817 >> >> has a section 2.3 "Endpoint Reference Comparison", which reads: >> >> "This specification provides no concept of endpoint identity and >> therefore does not provide any mechanism to >> determine equality or inequality of EPRs and does not specify the >> consequences of their equality or >> inequality. However, note that it is possible for other specifications >> to provide a comparison function that >> is applicable within a limited scope." >> >> Protocols using the WS-Coordination address/identity Register/Response >> exchange require that Coordinator and Participant information be capable >> >> of unambiguous comparison by the receiving party. >> >> EPR reference parameters are explicitly defined by WS-A as being opaque: >> >> they are intended to make sense only >> to the publisher of the EPR, and are available to be used by it for >> purposes such as routing when a message is >> received which is directed to a previously published EPR. >> >> The reference parameters of a coordination protocol EPR will contain >> information that the publisher can map >> unambigously to a reference to a Coordinator object or to a reference to >> >> a Participant object, or to the >> parameters of operations on an object which lead it work for a >> particular transaction). It is quite likely >> that this information is an invariant and unambiguous identity (for a >> given implementation) of a transaction, >> but this is not guaranteed to be so, and reference parameter information >> >> is not designed to be understood or >> interpreted by EPR receivers, so reliance on byte-for-byte comparision >> (even if it may frequently work) is not >> a reliable technique. >> >> Currently, this is not a problem for Participants: the >> CoordinationContext that they receive contains >> /CoordinationContext/Identifier, and this can be used to map the RS EPR >> (/CoordinationContext/RegistrationService) to the transaction being >> worked upon. Potentially, this allows >> different RS EPRs to represent a single transaction. >> >> The same is not true for Coordinators. The Register they receive >> contains an EPR >> /Register/ParticipantProtocolService which is an opaque value if it >> contains opaque reference parameters. It >> is a requirement that the Coordinator be able to establish that two or >> more Register messages actually refer >> to the same Participant. However, there is no guarantee, for example, >> that the Participant EPR embedded in >> Register will remain stable across repeated attempted registrations. >> >> Scenario: >> >> [This scenario is closely related to the one used in related issue >> "WS-C: Make Register/RegisterResponse >> retriable". Note that any resolution of that issue will require prior >> resolution of this issue: the ability to >> correctly detect duplicate registrations is a prequisite.] >> >> A Coordination Service (CS) creates a Coordinator (C) for a new business >> >> activity (BA), and emits a >> CoordinationContext (CC). >> >> The CC is transmitted to an application service (AS). AS (logically) >> creates a P which sends Register (R) to >> the Registration Service (RS) EPR for BA, embedding the EPR for receipt >> of protocol messages outbound from C >> to P (CP EPR). >> >> The RS, on receiving Register, creates an EPR for inbound protocol >> messages from P to C (PC EPR), and embeds >> this in the RegisterResponse (RR), which it sends to P. >> >> AS and P crash before the RR message is received by P. The AS on >> recovery causes P to resend R to RS. RS >> examines the inbound Register, and seeks to determine that it has come >> from a known P, i.e. that it is a >> duplicate registration. >> >> The CP EPR (/Register/ParticipantProtocolService) has changed. The >> reference parameters denote that the >> recovered application is a different instance of the application service >> >> (e.g. load balancing, cluster), and >> all of its Participants are similarly repositioned in terms of their >> full address. (Of course, for this to >> work the old address must be capable of redirecting to the recovered >> Participant.) >> >> If the RS uses a simple EPR comparision (byte stream against byte stream >> >> for the reference parameters) then it >> will conclude that the second Register relates to a different >> Participant than the first (pre-crash) Register. >> >> It will generate a new, different RegisterResponse, containing a new, >> unique PC EPR >> (/RegisterResponse/CoordinatorProtocolService) so that it can >> differentiate subsequent protocol messages sent >> from "P1" to C from those sent from P2 to C. >> >> Of course, P1 never received the first RR, and does not in fact exist as >> >> a separate entity - its address is a >> synonym for the address of P2. If the BA is AtomicOutcome it will expect >> >> all registered Participants to go >> Completed. This will either occur because the Participant sends >> Completed (Participant Completion) or because >> the Coordinator sent Complete (Coordinator Completion). In the first >> case, the P1 Completed will never arrive, >> and the activity will ultimately expire in the Active state. In the >> second case the Complete will be directed >> twice to P2 (once to "P1" and once to P2), and the Coordinator is liable >> >> to receive Completed twice from P2, >> but never from P1. In either case the activity will end up being >> ditched. >> >> If the BA is MixedOutcome, it may be able to tolerate missing or >> unwilling Participants. Its controlling >> application may have a business rule that says that P1 is not vital to a >> >> successful outcome. Or it may know >> that two registrations from one business service is an unexpected >> situation. However, this raises a second, >> and related problem. How does the controlling application know what P1 >> represents? How does it correlate P1 >> and P2 against an initial application request to the AS, that carried >> the CC in the first place? It has no way >> of knowing that P1 and P2 are intended to represent one and the same P. >> It cannot detect the duplication at >> the application level, even though such duplication may immediately >> violate a business rule. >> >> This latter problem also arises in non-pathological cases. An >> application which has created a MixedOutcome BA >> may send out contexts to three AS: AS-Car, AS-Hotel, AS-Plane. The >> application response for each must contain >> an identifier which a) different for each of the responses for -Car, >> -Plane and -Hotel, and b) which >> will match some value in the Register message, such that the controlling >> >> application can correlate the >> registered participant with the relevant application response. >> >> If the app-response Plane-Reservation contains an IRI element with value >> >> IRI[plane], and the Register contains >> a distinguishable element with the same value, then the controlling >> application can use some API to say: >> BA.close(IRI[Plane]). If the same pattern applies to Car-Reservation and >> >> Hotel-Reservation, it can also say, >> for example: BA.close(IRI[Hotel]), but BA.compensate(IRI[Car]) because >> £500 for a limo is no good to the user. >> These instructions can be mapped by the BA Coordinator into "send Close >> to the P EPR keyed by IRI[Plane]", >> "send Close to the P EPR keyed by IRI[Hotel]" and "send Compensate to >> the P EPR keyed by IRI[Car]". >> >> [IRI seems to be the correct type for such identities, as they are >> intimately tied to application behaviour >> (and may be coined by the application service rather than the system), >> and because they must be guaranteed to >> be unique, interoperably.] >> >> For all of the above to work, it is necessary for the RS, on receiving >> the Register, to be able to distinguish >> the IRI which correlates the Register (thence the Participant), and to >> pluck it out for use as a key for >> direct access into a collection of Participant EPRs. But, to go full >> circle, if the Register only contains an >> EPR which is differentiated by opaque reference parameters, it cannot >> properly use those ref param values as >> part of the key. Once again, they may change over retries. Or the >> Participant implementation may be perverse, >> and may emit EPRs which compare differently by reference parameter >> values, but which in fact map to a single >> Participant. The introduction of a time-related component in the EPR >> reference parameters (perhaps to help >> with auditing) is a conceivable non-perverse variant of this problem. >> >> To avoid these problems we need the ability to specify a distinguished >> non-opaque identifier for each >> Participant across multiple Participants. >> >> >> Proposed Resolution: >> >> There are three possible resolutions that come to mind. >> >> One is to allow a brand-new IRI element in Register, e.g. >> /Register/Identifier, which mirrors the /CoordinationContext/Identifier. >> >> The other is to define an extension IRI element, for WS-Coordination, >> that can be added into the RS EPR >> (/CoordinationContext/RegistrationService), to identify the Coordinator; >> >> and into the C-P EPR (the >> /Register/ParticipantProtocolService) to identify the Participant. This >> would be permitted, as we see it, by >> the WS-Addressing statement quoted earlier: >> >> "However, note that it is possible for other specifications to >> provide a comparison function that is >> applicable within a limited scope." >> >> The third is to ask WS-Addressing to provide a standard comparable >> element in the EPR. This seems extremely >> unlikely, as the move to Candidate Recommendation from Submisssion >> removed the capacity to compare EPRs. >> >> >> >> >> >> >> > > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]