RE: [ws-tx] Issue 018 - WS-C: split out of 002 a) - Distinguish example from normative, for subordinated CreateCoordinationContext behaviour

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

Ian,

That rather depends on how many coordination types there are ! 

Consider the implications of 

"WS-AtomicTransaction defines a specific set of protocols that plug into
the WS-Coordination model to implement traditional two-phase atomic
transaction protocols. It is important to note that the atomic,
two-phase model is only with respect to the services involved. Sites or
infrastructure offering services may advertise two-phase commit, but use
some other intra-enterprise model like compensation or versioning. This
freedom makes a simple two-phase commit model more useful for
long-running Internet computations"

(section 3.7 of charter reference 15 (
http://www-128.ibm.com/developerworks/webservices/library/ws-securtrans/
index.html - also at Microsoft)

That could well be implemented by having a WS-BA subtree below a WS-AT
context.  The other way round is possible too - you probably would only
do that where you knew how the ultimate resources were actually going to
fulfil their WS-AT promises.


If something roughly like the ws-caf BP protocol were brought under the
WS-C umbrella, I would think it very likely that a new coordinator for,
say WS-AT, might be created passing it the BP context (and expecting the
AT coordinator to register as a BP participant/sub-coordinator). [I
don't necessarily agree with all the details of BP, but the general
concept that transaction protocols can be bridged between because (or
when) they are semantically mappable I do agree with]

Or consider some of the features that have been excluded by the charter.
Precisely because we have agreed that we won't include them in WS-AT and
WS-BA implies that there could be other coordination types that do
include them, but are otherwise similar.  A mixed tree would then
certainly be reasonable, especially where one side was "legacy"
(supporting only one of the current TC's types) linking from or to an
environment that supported the more general, future type. For example:

	- heuristics in atomic : boundary node either stops and reports
heuristics from below (WS-AT over WS-ATH), or registers with but never
actually produces heuristics (WS-ATH over WS-AT)

	- delegation of outcome decision : (only for WS-TXD over WS-AT
or WS-BA) - boundary node can accept delegation but not pass it on down

	- last-participant optimization : as for delegation


We should make sure WS-C is flexible. Avoiding unnecessarily limiting
normative statements (as distinct from example ways of using it) is key
to this.


Peter




> -----Original Message-----
> From: Ian Robinson [mailto:ian_robinson@uk.ibm.com] 
> Sent: 18 January 2006 17:36
> To: Peter Furniss
> Cc: ws-tx@lists.oasis-open.org
> Subject: RE: [ws-tx] Issue 018 - WS-C: split out of 002 a) - 
> Distinguish example from 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
> 
> 
>