[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [ws-tx] Issue 018 - WS-C: split out of 002 a) - Distinguish examplefrom normative, for subordinated CreateCoordinationContext behaviour
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]