Issue 019 - WS-C: Split out 007 b)-- Avoid normative reference to subcoordinator identifier inheritance

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

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-Coordination-
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/archives/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.