Re: [ws-tx] Issue 002 - WS-C: Clarify subordinated CreateCoordinationContextbehaviour

[Alastair Green <alastair.green@choreology.com>]

Colleen,

As current owner, I am very happy to split these as you suggest. I 
wasn't sure what to do when I raised it, but I think you're quite right.

In BPEL they seem to do xxx.y or xxx.a when this happens, to make 
keeping track easier. E.g. 002 and then 002.1, 002.2 or whatever.

Alastair

Colleen Evans wrote:
> There are four sub-issues identified in the proposed resolution:
>
> 	Sub-issue a). Editorial work required to clarify example, and
>  accompanying figure, and to create a section that describes the model 
>  and normative operation of sub-coordination.
>  
>  	Sub-issue b). Remove any normative reference to subcoordinator
>  identifier inheritance in WS-Coordination.
>  
>  	Sub-issue c). Remove any normative statement relating to
> sameness of
>  superior and sub-coordinator coordination types or protocols.
>  
>  	Sub-issue d). Remove any normative statement relating to the
> timing of 
>  sub-coordinator registration, other than to state that the 
>  sub-coordinator must be registered to take part in activity 
>  completion.
>
> I propose we split sub-issues b) and c) each into a separate new issue,
> referencing issue 2 for context.  Sub-issues a) and d) could remain
> together as issue 2.
>
> Colleen
>
> -----Original Message-----
> From: Peter Furniss [mailto:peter.furniss@choreology.com] 
> Sent: Friday, December 09, 2005 10:54 AM
> To: ws-tx@lists.oasis-open.org
> Subject: [ws-tx] Issue 002 - WS-C: Clarify subordinated
> CreateCoordinationContext behaviour
>
> This is hereby declared to be ws-tx Issue 002.
>
> Please follow-up to this message or ensure the subject line starts Issue
> 002 - (ignoring Re:, [ws-tx] etc)
>
>
>
> Issue name -- WS-C: Clarify subordinated CreateCoordinationContext
> behaviour
>
> Owner: Alastair Green [mailto:alastair.green@choreology.com] 
>
> Protocol:  Coord
>
> Artifact:  spec
>
> 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
>  
> Section and PDF line number:
>  
>  Section 3 "Coordination Service", ll. 181-209
>  
> Issue type: Design / editorial
>
> Related issues:
>
> None
>
> Issue Description:
>
> Precisely specify normative behaviour of CreateCoordinationContext
> against existing (superior) context
>  
>
> Issue Details:
>  
>  [This issue stems from Choreology Contribution issue TX-17.]
>  
> There are two intertwined problems. One is presentational, the other
> more substantive. The initial part of Section 3 (up to and inluding 
> the diagram, Figure 2., on p. 10) uses an example to convey three
> things:
>  
>     a) the basic interactions of a registering application service and
>        a Registration Service, and their relationship to Coordinators
> and Participants
>
>     b) the notion of an interposed Coordinator, and
>
>     c) some seemingly normative rules relating to how interposed
>        coordination works.
>
> It should be made clear what is exemplification, and what is
> normative. It is possible that the exposition of basic (C-P) and 
> interposed (C-P/C-P) behaviours may be easier to grasp
> with two successive and related
> examples. These are primarily editorial matters. In the proposed 
> resolution I will call this sub-issue a).
>  
> The substantive problem concerns the implied or stated normative rules 
> of interposed coordination. There are two statements, which are too 
> restrictive -- or perhaps which seem too restrictive because they are 
> actually intended only as examples of one possible use of the 
> protocol, but appear to have normative weight because
> there are no other statements at all in the specification about the 
> behaviours being discussed.
>
> These statements are contained within the following three call-outs
> which refer to the diagram. They are  flagged with the inserted tags 
> [Statement 1] and [Statement 2].
>  
> ll. 197-206
>  
>      "3. App2 prefers CoordinatorB, so it uses CreateCoordinationContext
> with Ca as an input to interpose
>      CoordinatorB. CoordinatorB creates its own CoordinationContext Cb
> that [Statement 1] contains the same
>      activity identifier and coordination type as Ca but with its own
> Registration service RSb.
>
>      "4. App2 determines the coordination protocols supported by the
> coordination type Q and then Registers for
>       a coordination protocol Y at CoordinatorB, exchanging Endpoint
> References for App2 and the protocol
>       service Yb. This forms a logical connection between these Endpoint
> References that the protocol Y can use.
>
>      "5. [Statement 2] This registration causes CoordinatorB to forward
> the registration onto CoordinatorA's
>      Registration service RSa, exchanging Endpoint References for Yb and
> the protocol service Ya. This forms a
>      logical connection between these Endpoint References that the
> protocol Y can use."
>
>  Dealing with Statement [1] first:
>  
> It is wrong to mandate, in the WS-Coordination specification, that the 
> activity identifier of the newly created CoordinationContext should be 
> the same as that of the pre-existing (superior) Coordinator's 
> CoordinationContext. (Proposed resolution sub-issue b).)
>  
> For the purposes of correct operation of the interposed coordinator
> per se, the identity of the top transaction and the identity of the 
> bottom transaction are irrelevant.
>
> For the purposes of data sharing, every data-accessing participant in
> a tree or sub-tree that is known to have an atomic outcome (e.g. WS-AT 
> and WS-BA AO) should have available an identical value which can be 
> used as an accessor token. A single, tree-wide value for all 
> propagated context's /Identifier is a convenient way of
> achieving this. It would be appropriate to insert a rule in WS-AT and 
> WS-BA to the effect that a new atomic
> context which is registered against an existing /atomic/ outcome must 
> inherit the /Identifier value of the
> existing context. It is inappropriate to place this rule in WS-Coord.
>  
> (The above point implicitly rests on the assumption that, for atomic
> outcomes, every participant which registers with an RS associated with 
> a given /Identifier will receive the same outcome. Issues are required 
> to explicitly state this for WS-AT and WS-BA.)
>
> To create a mixed outcome, one must either send differently identified 
> contexts, or send identically identified contexts with a flag 
> indicating that they cannot be relied upon to receive the same outcome 
> (the MixedOutcome flag in a WS-BA context permits the latter option).
>  
> In this case we cannot assume data sharing, but nor can we rule it out 
> (it may still be useful to have a common accessor identity for more 
> sophisticated forms of isolation control than outright blocking). At 
> this point, we might conclude that the identifier-inheritance rule is 
> strictly unnecessary but harmless.
>  
> Scenario: A BA tree which combines MixedOutcome with AtomicOutcome.
> (Other cases can be created involving combining WS-AT and WS-BA, and 
> we have no control (at the level of
> WS-Coordination) on future interposition or
> sub-coordination behaviours for entirely new coordination types.)
>  
> A consuming service CS-Buyer uses three provider services: PS-Goods,
> PS-Shipping, PS-Insurance. There are two viable (successful) outcomes 
> possible -- {G,S}, {G,S,I} -- so we use MixedOutcome to govern the 
> relationship of the CS to the three PS. Inside each PS (and these are 
> likely to be separate legal entities), there may be several services 
> that are composed to offer a single transactional, contingent service. 
> To take one example: PS-Goods uses internal services IS-Stock, 
> IS-Credit, IS-Accounting to create a single atomic outcome
> "OrderGoods" operation. PS-Goods creates a WS-BA AtomicOutcome 
> sub-coordinator, and hooks it in to the CS-
> propagated B2B transaction.  
>
> Imagine that IS-Credit accesses an external bureau service.
> PS-Insurance uses the same service. Both Goods and Insurance use the 
> CS-Buyer transaction id to identify access to the credit system. If 
> this has access control implications (causes data sharing) then the 
> fact that Insurance may fail independently of Goods can cause
> unexpected side effects, if the rule "common id = atomic outcome" is 
> relied upon.
>   
> (Less strained examples can be created using trees which combine WS-BA 
> MO and WS-AT in intra-enterprise environments where data sharing is 
> more likely.)
>  
> WS-Coordination should say nothing about identifier inheritance. It is
> a matter for coordination protocols, for transaction domain bridging 
> software, and for applications (which may use identifiers to create 
> groupings or dependencies which are far more subtle).
>  
> Much of the above discussion hinged on the business need to combine
> coordination types in a transaction tree. But the second part of 
> [Statement 1] implies that interposition can only occur between 
> contexts of identical coordination types. As Tom Freund pointed out at 
> the first F2F, the design intent hitherto has been to permit
> combined-type tree creation. (Proposed resolution sub-issue c).)
>  
> Turning to Statement [2] (proposed resolution sub-issue d)):
>  
> The practice of having a subcoordinator delay registration with its
> nominated superior coordinator until it first receives registration(s) 
> from Participant(s) is viable, given certain rules. So is the practice 
> of eagerly registering subcoordinators as they are created. The 
> lazy/eager choice is not the property of WS-
> Coordination, and the spec should make it clear that subcoordinator 
> registration time is not defined.
>  
>
> Proposed Resolution:
>
>  Sub-issue a). Editorial work required to clarify example, and
>  accompanying figure, and to create a section that describes the model 
>  and normative operation of sub-coordination.
>  
>  Sub-issue b). Remove any normative reference to subcoordinator
>  identifier inheritance in WS-Coordination.
>  
>  Sub-issue c). Remove any normative statement relating to sameness of
>  superior and sub-coordinator coordination types or protocols.
>  
>  Sub-issue d). Remove any normative statement relating to the timing of 
>  sub-coordinator registration, other than to state that the 
>  sub-coordinator must be registered to take part in activity 
>  completion.
>  
>  
>
>
>
>