OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

ws-tx message

[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]