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
condition;
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
choreography.
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
sub-choreography
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:
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
code?
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.