RE: [ws-tx] Issue 019 - WS-C: Split out 007 b)-- Avoid normative reference to subcoordinator identifier inheritance

["Peter Furniss" <peter.furniss@choreology.com>]

This escaped before I'd checked it - subject line should say Split out
of 002 b)

> -----Original Message-----
> From: Peter Furniss [mailto:peter.furniss@choreology.com] 
> Sent: 21 December 2005 15:07
> To: ws-tx@lists.oasis-open.org
> Subject: [ws-tx] Issue 019 - WS-C: Split out 007 b)-- Avoid 
> normative reference to subcoordinator identifier inheritance 
> 
> 
> 
> This is hereby identified as ws-tx issue 019.
> 
> Please follow up to this message or otherwise ensure your 
> subject line starts "Issue 019 - " 
>   (after any Re:, [ws-tx] etc)
> 
> Alastair pointed out his original message referred to 007 
> when it should have said 002. I have corrected the 
> misreferences below.
> 
> ==============================================
> 
> Issue name -- WS-C: Split out 002 b)-- Avoid normative reference to 
> subcoordinator identifier inheritance
> 
> Target document and draft:
> 
> 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-Coo
rdination-
> 2005-11-22.pdf
> 
> Section and PDF line number:
> 
> Section 3 "Coordination Service", ll. 181-209
> 
> 
> Issue type:
> 
> Design / editorial
> 
> 
> Related issues:
> 
> 002, 018, 020, 021
> 
> 
> Issue Description:
> 
> This issue separates out sub-issue b) of Issue 002, which can be found
> here:
> 
> http://www.oasis-open.org/apps/org/workgroup/ws-tx/email/archi
ves/200512
> /msg00059.html
> 
> Avoid any normative reference to subcoordinator identifier 
> inheritance.
> 
> 
> Issue Details:
> 
> [This issue stems from Choreology Contribution issue TX-17.]
> 
> 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.
>  
> On the last point: 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.
> 
> One of these statements is contained within the following call-out, 
> which refers to the diagram. It is flagged
> with the inserted tags [Statement 1].
> 
> ll. 197-199
> 
>     "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.
> 
> 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.
> 
> 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).
> 
> 
> Proposed Resolution:
> 
> Remove any normative reference to subcoordinator identifier 
> inheritance 
> in WS-Coordination.
> 
>