[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: [Fwd: DRAFT REPLY -- Re: [ws-tx] Issue 018 - WS-C: split out of002 a) - Distinguish example from normative, for subordinated CreateCoordinationContextbehaviour]
|
Ian, Further to your thought-provoking question on mixing coordination types in a tree, and Peter's response, which I think gave some good examples. My view is that there are some subtleties that need to be carefully included or carefully excluded when it comes to any bridging behaviour, including bridging of like protocols. Take an example where the top of the tree is BA, and some of the BA subordinates have an AT relationship to their participants. Thus, the AT sub-coordinator speaks AT to its participants, but receives BA signals from its superior. An example implementation might choose to translate Close or Compensate from the BA Coordinator into Commit to all of the AT children; Cancel to Rollback. (There are other rules that might be applied, incidentally, especially if Close can be faulted). Now, you could argue that the bridging from BA to AT is a local (intra-node) matter for the implementer. If you made that argument you would be arguing in favour of removing the subordinated coordinator behaviour altogether. A BA Participant might choose to control and govern an AT coordinator, using implementation-specific means. This would not require expression of the coordinator-to-coordinator relationship in the protocol. A sub-coordinator is a Janus-like beast that appears externally to one counterpart as a Participant, and to others as a Coordinator. Each counterpart can be unaware of its duplicity. In fact you could argue that visibility of the implementation of the counterpart is a violation of service interface implementation encapsulation. One might argue in response: if we have a normative rule that sub-coordination only applies to common coordination types then we have a simple optimization in place, which requires no statements about the bridging behaviour. I would respond: you have not eliminated the complexity of bridging. Once you lose the atomic relationship (e.g. BA MixedOutcome) then you must put more intelligence into the bridge than "pass through the message to all subordinates". And even with the atomic relationship you have to describe the effects of partial failures on the whole node: somewhere it must be said that atomic protocols require the cancellation of any participant in the whole tree to cause the transaction as a whole to rollback. This requires two sub-rules to be explicitly stated (neither of which is currently stated fully anywhere in the three specs, I believe): that cancellation of a Participant registered with a Coordinator of identity X will cause all other Participants of X to be cancelled, and that cancellation of any Participant of an atomic sub-coordinator will cause it to send cancel [whatever that semantic is called in the referencing spec] to its coordinator. You could certainly argue that all of this is not the business of WS-Coordination, which can only create tree structures at most, as it is ignorant of the intended use of those structures. I think I would favour either a) eliminating sub-coordination as a visible interoperable concept, or b) allowing the "joint" to be visible, but describing its rules of behaviour and translation outside these specs, or in some future bridging spec for any pair of coordination protocols. With option b) you can express the coordinator/sub-coordinator relationship directly. In that case you have to cater for transitions from one protocol to another through further specification elsewhere (e.g. rules could be defined for WS-AT). This implies that registration of a sub-coordinator means that the sub-coordinator will act as a Participant of coordination type A, and as a Coordinator of coordination type B. The exact bridging relationship is either a matter for a bridging spec, or for implementation choice. Personally, I'd be happy to eliminate the explicit notion of sub-coordination, as bridging (including the special case of interposition of like protocols) can always be achieved as a "local" matter. This would simplify WS-Coordination, and avoid the need for exemplary text at all. A final comment: I can see the need for domain bridges, but I can't see the need for standardized interoperable distributed protocols to express the bridge behaviours (i.e. I don't see the point of something like WS-CAF BP in this context). At maximum one might argue for standard bridging rulebooks for particular combinations, but it's not clear why XML or WSDL or WS-A need be used to express the mapping rules. Alastair Ian Robinson wrote: Peter, can you give an example of when Cb might have a different coordination type from Ca? 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> 13/01/2006 15:09 cc Subject RE: [ws-tx] Issue 018 - WS-C: split out of 002 a) - Distinguish example from normative, for subordinated CreateCoordinationContext behaviour Proposal for 018, 019, 020 and 021 (ex 002) Rationale: Following the discussion on 018, 019, 020, 021 yesterday, I believe it was the consensus of the meeting that there was not meant to be any normative implication of the illustration in lines 190-209. Accordingly, the request of 018 would be met just by making that clear. However, part of the concern was that the text, by its placement in 3.0, and in the absence of stated alternatives, appeared to be defining *the* model for sub-coordination, hence the particular points of 019 (same identifier), 020 (same coordination protocol) and 021 (timing of sub-coordinator's registration). Thus making the illustrative nature of the text clear should identify points where things could have been different. (note that, if 190-209 are considered currently non-normative, this is must be in fact an editorial change) Since it is likely that some coordination types won't work if implementations have total freedom on these points, the requirement on specifications to say what sub-coordination behaviour is required should be called out. Proposed changes: in line 190, add "an example of", making the paragraph begin "Figure 2 illustrates an example of how two application services ..." Add the following after line 206: Note that several features of this example are actions that are not required by this specification, but which may be defined by the coordination type specification or are implementation/configuration choices. In particular . App2 and its platform could have requested direct registration for protocol Y with Coordinator A . CoordinatorContext Cb could have a different activity identifier and different coordination type to Ca . App2 registration with CoordinatorB and CoordinatorB's registration with CoordinatorA could be for a different coordination protocol, or for more than one protocol . CoordinatorB could register with CoordinatorA when CoordinationContext Cb is created, before receiving any registration requests itself Specifications of coordination types and coordination protocols that need to constrain the subcoordination behaviour of implementations MUST state these requirements in their specification. ------------- Peter ----------------------------------- Chief Scientist Choreology Ltd web: www.choreology.com <-- now with Cohesions 3.0 available for download ! email: peter.furniss@choreology.com phone: +44 20 8313 1833 mobile: +44 7951 536168 |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]