Minutes 13 July 04 Con Call

ws-choreography conference call meeting
2004 July 13

I. Roll Call
- Assaf Arkin
- Abbie Barbir
- Charlton Barreto
- Carine Bournez
- Gary Brown
- David Burdett
- Martin Chapman
- Tony Fletcher
- Mayilrag Krishnan
- Yves Lafon
- Monica Martin
- Greg Ritzinger
- Steve Ross-Talbot

Scribe: Charlton Barreto

Martin: no access to IRC or minutes or agenda

II. Minutes from last meeting
- Number of points for us to look at
  Mainly last week's roll call
  Steve couldn't figure out if anyone's missing
  If were on call and are not mentioned, inform Steve to include
  (no comments on conf call)

- Things decided
  General acceptance that XInclude is something we should look at
  Templates - David to flesh out
  Contact AC members for all members in bad standing (have not participated in last four months - must attend next meeting or be marked as members in bad standing)

- Move to have last week's minutes passed
  No objections
  Last week's minutes passed into the record
III. Agenda for today's meeting
  Quick action item review (oops, Steve forgot to put items in there, apologies)
  Standard issues category run through
  This week have three proposals on the agenda:
  - Bidirectional interactions (Gary)
  - Composition (Gary)
  - Transactions (Tony)
  - import (Monica)
IV. Action Items
- Action 1. (Tony, 0525, 0601, 0615, 0629, 0706)to look at element choreography notation to see how we may be able to roll up transaction features into it. 
IN PROGRESS as of last week.
  Tony: Let's leave in abeyance for another week or two
  Tony's had some discussions about it; Peter's come on booard
  They're reviewing previous proposals made; we've had internal discussions
  Steve: Let's mark as in progress, and revisit in a week or two
- Action 2. (SRT, 0525, 0601, 0615, 0629, 0706): Take the TWIST example we're working on, add part of the flow what can go wrong, see what happens when things go wrong.  We can see in front of us the choreography being executed, what we do today with current language, what we can do with transaction. Steve is 
starting to add exception handling.  Nick and Steve have corresponded on "perform" which revealed some errors in the specification to be corrected. 
PENDING COMMENTS FROM MA and BS (Matthew Arnott and Bill Specht) as of last week, 
  Steve: We haven't heard back Matthew/Bill
  No change
- Action item 3. (MARTIN/YVES, 0615, 0629, 0706) Martin/Yves put link on admin page for current spreadsheet. Yves has file now.
  Yves - done
  Issues tracking on page with link to spreadsheet
Steve: Only two action items left

V. Concrete Proposals
1. Bidirectional Interactions
   Gary Brown: 
   - interactions; based on examples Nick put into some slides
     e.g. placing an order
 	 	 cust may want to cancel order before complete
 		 scenarios: order completed scen
		 		    order cancelled scen
		            order completed and cancelled  
		                  can cross over because asychronously initiated
		 Steve: sent out email to group to see if anyone could provide CDL 
  		 	    example; as no one responded, Gary took on the task. 
		 Gary:  could not work out how best to do it, seems to be quite 
			    complicated, even impossible in some cases.
 		 Nick:  to explore how it may be possible with State alignment.
		 examine this again from busn POB
		 see how to address it such that only one such interaction
		 w/b enacted at the end of the day
		 if higher priority interaction received in place of
		 expected response, it is processed
		 this particular proposal only looks at simple case
		 simple relationship with interactions in same direction
		 weaken this such that can have interactions in 
		 opposite directions
		 increase complication with three or more particpants
		 with two particpiants - can validate CDl such that
		 both parties understand where they are and what
		 directions they need to take
	David:  What concrete change does this entail?
	Gary:   No explicit change to spec
	        Provided - and working from - simple example with choices and 
            relative sequences
	        There's an implicit understanding that priority order exists
	        when CDL performs bidirectional interactions
	David:  Without that, can endpoints decide difference priorities?
	Gary:   We can have two situations
	        1. If all interactions are in the same direction - priority is not 
               an issue
 	        2. If interactions are in different directions - we either need:
	           a. An explicit indication of priority, or
	           b. Priority based on order
	        With explicit priorities, the participant taking highest priority  
            knows that their path will be taken
	David, Monica: we should explicitly set priority
	        This sets expectations and is unambiguous.
	        Should this be in the spec - as a language construct?
	David:  Should we make them sequential? if important enough, this should not 
            be left to choice
	Monica: We need a sentence in spec to clarify requirements, 
	        vis-a-vis Gary's implied hierarchy, mandated sequence, and other 
            rules with respect to the processing of interactions. 
	ACTION: We need to include an explicit mechanism for     
            describing priority in a choice.
	Tony:   Peter thought he'd worked out how to do CDL challenge in this 
            respect; explored from the perspective of an interactions race 
	        Two state machines at either end - non-trivial process - given basic 
            protocol, work out two state machines at either end of two ended 
            relationship; tends to be very complicated in implementation; can 
            work it out and specify it
	        Tony still feels uncomfortable with respect to following path where 
            we may describe message sequence charts in CDL - fragile where other 
            sequences which spec may allow won't be allowed or vice versa - path 
            may not work out in the end.
	Steve:  CDL describes permissible and non-permissible message sequences; 
            excludes what you feel are not permissible without doubt; can't 
            think of many cases w/vertical protocols such as TWIST that we 
            couldn't encode in CDL....
	Tony:   Concerned that one taking particular sequence chart taking on 
            mainstream sequences that are intended
	        Write state machines on either end
	        We add more states, guards, etc to state machines as necessary
	        end up with state machines with certain definitions and sequence
	        charts. This may end up being too restrictive and inapplicable to 
            all the possibilibities....
	Steve:  We can translate sequence chart to process algebra....
	Steve:  Do we have what we need to bring it forward? (Yes)
	        Is this something worth pursuing? (Yes)
2. Composition
	Gary:   Composition can be addressed in two ways
  		    a. sub-choreography as if not atomic unit
	  	       limit complexity of any proposed choreography
		    b. binding: if different outcome in sub-chorepgraphy, 
		       the parent choreography would need to examine state info
		       to determine how to proceed
	        The first approach is the thrust of my proposal.
	        The next step - how to build interface between chors using 
            interactions, due to global model view of choreography
            A choreography doesn't present any interfaces to allow it to be used
	        as a service, so as to be used by something else
	        If we try to fuse two choreographies together, what do they have in 
            common? A similar set of interactions. 
	        As such, rather than treating a sub-choreography as something to be
	        invoked, we need to see how to fuse the definitions/interactions.

	        If we have sub choreography that's very simple, it just duplicates 
            interactions in main choreography - in this case Composition is not    
            that worth while.
	        If a sub-choreography performs a specific task - that task needs to 
	        be verified has having been performed within the parent 
 	        In reality we'll need to propose large set of complicated 
            choreographies - maybe even a hieracrhical relationship. 
	        This will help resuse choreographies in a better way. 
	        If we have sub-choreography that has multiple outcomes, parent 
            choreography can continue its path, rather thaninspect state 
            variables to make a decision.
	David:  Likes idea of composition;
	        But there are cases where the atomic approach may be less preclusive
	        of how this is implemented. 
	Gary:   We do not preclude of variations of implementations.
	        The interface between two choreographies are based on 
	        interactions; as long as interactions are preserved, how the
	        sub-choreography shares a relationship with the parent choreography 
            is up to the implementation
	        The examples share a relationship and define two roles common 
            between choreographies
	David:  What about multiple roles that have to exist in parent choreography  
            -> a parent choreography doesn't make sense in this context
	Gary:   If we have two choreographies - don't have to think of one as
	        parent or child - there are simply a set of interactions that they 
            will share, whether over one relationship, more relationships, 
            multiple roles, etc. 
	        A sub-choreography can provide wider interface than parent wants to 
            use; it solely defines the common relationship bet parent and 
	Monica: Gary said that parent-child rel: are both dependent? independent? 
            child can't exist w/o context of parent?	
	Gary proposes sub-choreographies to be independent - no dependency 
	        between parent and child standalone choreographies
	Monica: This touches on distributed choice issue: are these truly 
            independent given constraints?
	Gary:   To clarify - parent has dependency on sub-choreographies dependent 
            with respect to interfaces/interactions, etc. 
	        This could be different 20 odd ways payment could be performed as 
             long as have minimum interactions are used
	Steve:  This is bi-similar: as long as right things are put
	        in, right kind of things come out: dependency is behavioural and not  
            strictly between particular parent and particular children
	Gary:   Note that this behaviour is not related to transactions; 
            transactions can be shared via composition, something we should 
            explore transaction may need to span several children; parent?
	Monica: We need to have traceability with respect to fulfilment outside 
	        the scope of CDL	
	Gary:   Behavioural boundaries may introduce transactional 
	        constraints with respect to a choreography 	

	Steve:  Can we perform composition without an explicit 'perform' element?
	        If we want to do model checking - livelock, deadlock - it is harder
	        to achieve with 'perform'	
	Tony:   Higher level semantics are what CDL is concerned with, but today we  
            don't have such semantics built into CDL
	Steve:  Where do we take this one; Tony wants to reserve judgement on this 
            since he hasn't had time to study it sufficiently.			
	Gary:   And remember, we have problems if define choreographies via bindings

	Steve:  Let's leave this issue 'on the books', bring it back
	        and ask again just to get a feeling from the group.
	        I expect it to be stacked up for the F2F; people to have a good look 
	        at the proposals in the mean time and discuss them at the F2F; we 
            need to come to grips with these proposals given their complexity
 3. Tony's State Transaction email	
	Steve:  XInclude proposal, bring it back up at next neeting, let's talk 
            about Tony's state transaction email
	Tony:  I don't want to bring state alignment protocol into CDL
	       This interaction must have properties of alignment - not
  	       guaranteed by description, but in the way the description is 
           essentially run over the infrastructure
	       We can describe transactions in CDL, but can lead to weighty
	       descriptions; we don't want to describe transaction protocol
	David:  Here we have two problems to solve - one is aligning state:
	        states need to know about e.g. signal comes from recipient of 
            message -  "i've received your message"
	        With Anders and J.J., we're looking at ways of communicating these 
            sort of things in CDL, instead of separately defining it/
	        We need to make sure we understand where we are as this is diff
	        from state alignment.
	Tony:   This highlights the main difference between ws-choreography and 
            BPSS defines messages - ('signals' = BPSS defined messages)
	        This may be more flexible in BPSS v2.0
	        If allow the possibility of crossover...?
	        BPSS worked before in this because of it's constraints.	        
	Monica: BPSS 2.0 - need to look at changes in 2.0 before
	        we make/continue any assumptions....
	Tony:   CDL just describe messages; signals, etc. s/b done on top of CDL
	Steve:  I have not heard that we're going to define such a protocol;
	        We can describe external observable behaviour of such 
	        a protocol.
	        We can insert such messages into a CDL as suggested by Tony.
	        If we do Composition, it can address this usage. 
	        Tony's email duly noted - could be fairly big debate issue in 
	        next meeting and/or F2F. 	
	Steve:  Let's let this run on the mailing list

VI. Examples Subgroup
    Maylraj: About 80% of examples completed
	         We need feedback as next step as to how we start making the 
             document - such as what documents do we need other than source 
	Steve:   It makes sense to have those interested in what the sub-group is 
             doing join in a conference call; sometime this week around this 
             time might make sense. 
	ACTION:  Mayilraj to put down dates and time for this conference call and 
             send to the mailing list

	Steve: No other issues
	Meeting Closed.