-------------------------------------------------------------------------------
Minutes CHOR F2F, May 11-2004 Morning session
Note taker: Abbie Barbir, Nortel Networks
-------------------------------------------------------------------------------
Agenda:
http://lists.w3.org/Archives/Public/public-ws-chor/2004Apr/att-0045/DRAFT_May_04_F2F_Agenda_-_1.txt
1. Role Call:
Chairs
Martin Chapman (Oracle)
Steve Ross-Talbot (Enigmatec Corporation)
W3C Staff
Yves Lafon (W3C)
Members
Mayilraj Krishnan (Cisco Systems)
David Burdett (CommerceOne)
Tony Fletcher (Choreology Ltd)
Monica Martin (Sun Microsystems)
Kevin Liu (SAP AG)
Nickolas Kavantzas (Oracle)
Jeff Mischkinsky (Oracle)
Charlton Barreto (webMethods)
Peter Furniss (Choreology Ltd) 13th May
Observer
Matthew Arnott (CommerceNet) - invited as TWIST/fpML expert 11th May
Bill Specht (Currnex) - invited as TWIST/fpML expert 11th May
2. Review and approve Agenda:
- Approved with the ebxml and laisons
3. Approve of outstanding minutes:
- None taken not ready yet.
4. Outstanding Action Items
- Postponed until next day
5. Need a clear understanding of where we are?
Nick: Look at dependencies to other spec's
Steve: Need to create a list
List:
- Now we have three docs out there, requirement, model overview and CDL
- We need to do the following:
o Primer doc.
o Handle issues with CDL
o Implementations: what are they, after CR need to interoperable implementations, last call and then CR.
o Test suite
o Examples
o Collateral
- Need to interoperable implementations
Steve: We have success factors that require the generation of code skeleton and the notion of choreography monitor and typing system (enable detecting of live locks/deadlocks etc.)
Steve: CSF: Ease of use (tools for modeling) must be met. Need some conformance tools per legacy SOA.
10:15 break
Nick describes how he reached to the newest version of the CDL from March to April
o Addressed issues on the list
o editorial feedback and other proposals
o basically layering was addressed but nothing major
o clean out typos etc.
Monica: it is more readable
Tony: editor copy is not always the latest
Steve: editors should be the latest version on the page
Tony: I do not see a conformance section.
Yves: We need it before last call
Martin: MUST, MAY are also conformance
Tony: Need a separate close for that.
Martin: we need a conformance section.
Steve: what is the main problem for the editors since April? There was some QA on the list.
Martin: editing team can not add any new info into the doc with group blessing. Basically fold in the changes that the WG reach.
David: At what point we know.
Martin: The WG will let you know. Some will edit the spec's directly.
Tony: Need a formal resolution process on the teleconference. Need that in the minutes.
Martin: Steve: Action points will show that.
Nick: Do we have logged issues in Bugzella. Need to know the process
Steve: Need to be clear on the process.
Group discussion, No minutes.
Nick: In this F2F are we going to solve issues.
Martin: Tom. We need to assign owners to the non-assigned issues.
Steve: This is the flow for bugs/issues
o An issue is raised on bugzella or by e-mail
o Issues can be in one of the following categories: Valid, invalid, will not fix etc.
o Issues are assigned. Owners propose a resolution and publish on the list.
o Not assigned issues have a default owner.
o Deadline depends on dependencies etc.
o All open issues need proposal from original owner to progress
o Proposals are discussed at WG, and resolved (closed by various means)
o Accepted proposals result in actions against the editors to add to the doc.
Martin: When we resolve something in the group we mark it as resolved later so the editors can add to the doc. It is marked fully resolved fixed when it is in the doc. So resolved later is an intermediate step before resolved Fixed. This also will be shown in the doc when the WG moved into a WG draft.
Martin shows the issues from the triage meeting. The motion on the table is to adopt what has been resolved. Contentious issues were left open.
Issues at http://lists.w3.org/Archives/Member/member-ws-chor/2004Mar/0033.html
o Issues 271/272 are agreed on by the WG as done on the triage list.
o Issues 276/281 are closed as the documented in the triage.
o Issues 276/321 are closed as the documented in the triage.
o Issue 326 marked resolved later.
Issues at http://lists.w3.org/Archives/Member/member-ws-chor/2004Apr/0009.html
o Issues 474 accepted as resolved.
o Issue 487 is reopened. Assigned to Steve.
o Issue 488 resolved
o Issue 492 resolved
o All decisions are the same as the triage notes.
-------------------------------------------------------------------------------
Minutes CHOR F2F, May 11-2004 Afternoon session
Note taker: From: Charlton Barreto wesbMmethods
-------------------------------------------------------------------------------
1. Example led walkthough of current Working Draft
Steve: We need to start walking through the process of writing an example.
Steve: After the break, we need to actually build this example, and we need to build one that is non-trivial.
Steve: Let's go through Greg's example; he sent it via email and it is also in the current Working Draft of the spec.
Steve: It would be good to go through his example, even though Greg is not present, as it is a good starting point. Nick will walk us through the example.
What we actually did was walk through the example in the current working draft.
http://www.w3.org/TR/2004/WD-ws-cdl-10-20040427/ see 2.5.2.4 Interaction Life-line
Example
-------
informationType - provides layer of indirection: e.g. purchaseOrderType as an alias for pons:PurchaseOrderMessage. Relationships between roles are defined using the relationship element. It corresponds to a C style typeDef, providing indirection so that the choreography doesn't point directly to actual source types, and without the part/xsd complexity of wsdl.
An issue has been filed to address this approach, as it does increase the complexity or writing CDL; per Nick, people in his team feel strongly about it. However, Steve feels that it doesn't overburden the CDL author.
channel: concept of the collaboration point; it cna restrict what can be passed along the pipe. It corresponds to correlation infornation. channelType describes what types are used to id wsdl reference, or for identity, or a web service addressing structure abstraction layer to describe different addressing.
it abstracts addressing and correlation info. can it reference a wsdl fragment? yes, because a token is an abstraction to a fragment
locator is how to get to a document and the query to extract its information - the info can be in the header or body, the query gives this to you
Steve: wanted to clarify some things about channel
reference - instance of endpoint which is an implmenentation of the channel
identity - declares how to hold a conversation on this channel
channelTypes - ports in a pi-calculus sense, but more than a wsdl port - it is a qualified port gives you all the info you need to know in order to mfg a channel
Nick: concurred with this description.
Kevin: asked if a reference is an endpointReference? Nick confirmed this.
Kevin: also asked is channelType a correlationId?
Nick: indicated that partnerLink describes channelType reference, correlationId describes channelType identity, and that channelType is used - with skeletons - to create correlation sets, providing compatibility
Martin: indicated that we need extensibility for policy type.
Tony: expressed that the correlation between relationship and channelType was confusing.
Martin: responded that it is not just about one channel - it is not static endpoint.
Nick: responded that a relationship is a static coupling; channel is a dynamic coupling.
David: responded that this describes how communications are unique in this usage and instance.
Steve: indicated that this seems to be a naming issue and that we should move on.
Steve: asked about the roleType association with a channelType is this always a TO role and never a FROM? David respondend that for now it is, but it may be useful to have a FROM role to clarify the two endpoints in a communication.
Matthew: mentioned that this is not about socket-style communication, but about the constraints in communicating with an endpoint - for anyone wanting to talk to an endpoint; he then asked, what if the identifier is as ephemeral as a purchaseOrder? David indicated that channelType describes the constraints on a channel, more than a channel itself; i.e. which instances of choreography, providiving context between ws interactions.
ACTION: Participant
Participants aren't explicitly used anywhere - is it a candidate for removal?
Matthew: indicated that the instance of a role is a participant.
Martin: indicated that a participant is a more concrete description of a role instance.
David: indicated that we want to define a choreography such that one can deal with as many participants as one needs to, in order to perform a business process. As such in summary there seems to be a real need for participant, and this needs to be evaluated for further use and to see where is can be explicity used, if applicable.
Nick: describes choreography as a way to aggregate interactions define vars, scoping rules, reuse existing choreographies. Variables live at a role, inside of a role. There is no concept of global data/global memory as with BPEL. It is a peer-to-peer environment, taking knowledge from one role and propagating it to others. It creates endpoints and passes them around; data exists solely in the data pools of the [participants]. Any shared data must be synchronized.
Tony: indicated that participants can describe much of this (the above). He asked whether this led to two possible models? colocated interactions [vs. remote]?
Martin: indicated that one should never use a model to model an interaction with only one participant; can do assignments within participants
Matthew: expressed concern with this since we don't know whether participants are geogographically colocated - it certainly makes a difference in finance - and the infrastructure must determine whether roles/participants are colocated.
David: indicated that even the same roles can represent different entities/businesses, and in this context, variables shared within a role present a problem.
Nick: affirmed that a participant is purely a modelling concept.
ACTION: Roles within Roles
Nick: asked if one can have a role within a role (Robin Miller had asked this in the Cambridge F2F and it had not yet been addressed)? We will need to resolve this as it has considerable repercussions for CDL.
ACTION: Delegation Use Case (The Agent Acting On Behalf)
Matthew: asked if one can have an agent within a role. We will need to look into this.
At this point we completed the declarative portion of the example CDL and began examining interaction, where the actual interaction work takes place. It specifies the operation to invoke (defined in the TO role behaviour; defines an interface, and this operation belongs to this interface).
Kevin: asked what the participant is going to pick up from the interaction element. Nick: eventually responded that this operation can be an alias to a wsdl operation name, normalising the system, which is why message content type shows up in interaction.
Matthew: questioned why this is restricted to only web services and not a proprietary MOM system.
Nick: broached whether wsdl 2.0 interfacing can replace some of this interfacing in CDL?
Kevin: indicated that we have a charter to use wsdl 2.0. Per Steve it is raised as an issue.
Nick: indicated that we also have dependencies on BPEL (which itself depends on wsdl 1.1) -
Steve: indicated that it is a CSF and not necessarily binding.
Continuing on w.r.t. interaction....
Tony: asked why we have initiateChoreography = true.
Martin: responded that so far we haven't actually performed an action.
Kevin: added that one choreography can perform multiple interactions.
Martin: indicated that "this interaction" initiates a new choreography. There was some discussion around whether the first interaction in the CDL can autoinitiate if there is no ambiguity.
Tony: mentioned that once it is started, it is started, so he questioned whether we needed an explicit statement to start it?
Matthew: asked what it means to actually start? Is initiateChoreography a main (as in most procedural PLs and a number of OOPLs), and how does it relate to subroutines/subprocesses?
Tony: added the question concering the difference between programming models for individual systems; given the global viewpoint, we want to desc chors such as choreography a is finished, and we have to wait for choreography b.
Matthew: added that this describes meta process or self-monitoring processes.
Martin: replied that we need an explicit 'start' statement - initiateChoreography - to indicate that "this is really where [the interaction] starts".
Tony: asked that if this is left out, how would the chor differ?
Tony: is viewing this from the perspective that choreographies can call one another or be initiated from joins of other choreographies.
Nick: then asked whether we can have small things, endpoints, w/o this global transaction context?
Martin/Steve: replied that we can.
Matthew: brought up the concept of the composite transaction - making a transaction out of other transactions, which can be other individually used transactions, so each composite transaction. This has the concept of 'start'/'begin'; here's how the individual transactions are used in a larger context.
Tony: indicated that we need to specify this in a char - here's a context identifier, and we start this chor when we rec this id.
Nick: responded that as such we need a declarative method to indicate when to start.
Steve: indicated that if don't like this, because of multiple points of entries, that we should raise it as an issue.
Tony: mentioned may indeed need it explicitly rather than implicitly.
Monica: added that this relates to composability and import issues that she has.
Nick: agreed, although the example doesn't involve import (maybe it should).
Nick: described exchange in the interaction - this element exchanges information between roles.
ACTION: Exchanges & MEPs. We will need to explore this relationship.
Martin: elaborated on use and populate - one does request, other response; the messagecontenttype is what they send from one end. to another.
Matthew: asked if use and populate are both used to construct exchange, then realized that he was mistaken, as these refer to two separate exchanges.
Nick: elaborated that exchange handles moving message from one endpoint to another.
We then proceeded to look at the relationship element in interaction. Relationship is used to associate one behaviour between two roles.
Matthew: asked can we articulate more than one behaviour within a relationship?
Nick: added the question of how we define this (noting that this issue is addressed by allowing roles within roles).
Martin: added that we can use queue name to define this, but let's raise this as an issue, noting that we can put queue name inside relationship.
Matthew: then brought the following: Say I have a buyer and a seller with lots of interactions; I want to use relationship to encapsulate behaviours between the two.
Nick: reiterated that a role is collection of behaviours - so how do we know which one to associate with another - right now use relationship to do this.
Martin: added that a role has a name and >= 1 behaviour.
Matthew: then voiced his understanding that in relationship you call forward behaviours to be used in the interaction in question.
Martin: reiterated that we should be able to use queue names to identify role behaviour groupings in interaction level relationships.
Matthew: then asked where would this bind.
Martin: responded that we're not binding in CDL as of yet.
Nick: then proceeded to say that we should an issue w.r.t. the redundant info between interaction and channel.
Tony: raised the point that we should review naming in the example so that we can clarify what needs to be related back to what in different sections of CDL.
ACTION: For the editors: All examples should have unique names except where related to other elements.
Nick: then broached the record element in the interaction. We use record as an assign for endpoints, while we use exchange across endpoints. It was then asked what "align = true" signified.
Nick: responded that this implies the understanding that you really exchanged and really recorded and that we have action level coordiation, while "align = false" implies that you are making no assumptions about the other side.
Matthew: then asked whether "align = true" implies guaranteed delivery?
Nick: responded that it does imply guaranteed delivery at the application level.
Steve: provided the following example - it is as in the letter you posted made it to the letter box, but not that the other side has actually opened the letter.
Matthew: then asked how do we artculate an order to these actions?
Martin: then queried syntactic/semantic order [serialization implied]?
Nick: then responded that for exchange semantic order is defined for both one and two way, but how this request and response happens needs to be elaborated.
Monica: then indicated that sequence can be required, and it is required by the contract - there are several defns we're using for sequence and it can be explicit, and defined in the [business] interaction order, and this can't be articulated using the present mechanisms.
Martin: then brought up that there is an issue here - an action to the editors
ACTION: Relationships (1:1 behaviour?)
Relationship has role behaviour, which is currently structured as 1:1 (relationship:behaviour) - does this behaviour need to be relaxed in this context to manage 1:m (relationship:behaviour). How do we defined this> Can we use roles within roles? Can we use queue?
Steve: then confirmed that record assigns variables in one model.
Nick: added that in a record, roles have to match bet role and target.
Martin: added that this is something in the acknowledgement, setting a variable with record, so now we know the variable has been set.
Matthew: then posited the scenario where these may occur in extremeley rapid succession.
Martin: responded that sequential order is guaranteed by the element block.
Matthew: then mentioned that record is not a synchronized event; the responder can assume interaction is completed before record has occurred; so in top-level view, are we building a state machine of variables? Tony responded that "align = true" forces synnchronization to take place at the end of interaction.
Martin: added that "align = false" along with no record indicates no synchronization takes place at this level.
Martin: also indicated that we can take record out of intearction, add an assign after the interaction, and do it there instead (more apt for managing complex scenarios).
At this point we completed the documented example.
Nick: indicated that we haven't discussed work unit, exceptions, and [a third element I didn't catch] - this is a very basic example - and you can see that it has many 100s of lines.
Matthew: then queried what was the difference between use/populate and source/target.
Tony and Nick: elaborated that use/populate is scoped for the message while source/target is scoped between elements [this needs more elaboration, actually].
Steve: then posed one last quick [set of] question[s] - If we're doing partial confirmation, how do we know when we're completed? The only way you know you've finished the order is to perform some confirmation associated with role. Is this what's record for?
Martin: confirmed that this is correct.
Nick: elaborated that without record, we cannot deal with race conditions; we need to deal with something that has not yet made it to the other side.
Tony: added that if we wanted to test the variable in target, we would test it via record.
2. Develop richer example working in two teams amongst the F2F participants
Ran out of time doing this due to extensive walkthrough in 1.
3. Matthew to walkthrough types of multilateral interactions which exist in the financial sphere.
This is posted to http://lists.w3.org/Archives/Public/www-archive/2004May/att-0016/TWISTWholesaleTradeRequirements.doc.
Matthew described the multilateral interactions involved in a shares purchase.
4. Agenda for tomorrow
Morning - up until coffee - build example using Matthew's multilateral interactions scenario.
After coffee - engage tomorrow's agenda as originally planned.
-------------------------------------------------------------------------------
Minutes CHOR F2F, May 12-2004 Morning session
Note taker: From: Mayilraj Krishnan Cisco Inc.
-------------------------------------------------------------------------------
(1) Steve walked thru the TWIST Finance Use case that Matthew presented.
Martin & Tony: Discussion on participant? do we need participant?
Tony: Do we need to define role if there is no call back?
Nick: This is the issue. Today spec does not support
Tony: Trading Service has 3 roles..
Steve: walked thru the example again for Nick & Kevin
Martin: described the buyer, seller roles exhibiting by Trading Service.
Kevin: Between trading service and seller message content could be different
Martin: Abstract WSDL is same, then we are better off defining the same role
Kevin: WSDL always described from the Service Provider perspective.
Monica: We need to define the interface from the client(consumer) perspective:
Martin: Disagree.
Martin: Described WSDL types of Buyer Seller Model.. Using Request - Response and two one way messages..
Martin & Nick &Kevin & Mayilraj - Discussion on WSDL MEPs..
Nick: Why are we not supporting Out - In, Out only.. ? JJ Question is valid
Steve: We have to look at from the TWIST perspective? Just client has to make sure the behavior type..
Nick: WSDL is not designed for that only server (provider).. To define both client and server
Kevin , Martin & everybody: No
Nick: Compatability on the types also.
Monica: Composability etc has to be fit in WSDL.. But looks like it does not..
Steve: Sounds like some req in the spec.. WSDL could not do..
Nick: Why do we have MEP?
Kevin: We have some products use Out only (Notification type). Available thru Registry etc.
Monica: We should not discuss more about the endpoint.. Should discuss on interaction
Steve: We need to concentrate on WS-CDL..
Martin: We can define participants..We don't use them now? Do we need to define?
Tony: Copying this role from another role is fine.. But what about what we cannot copy?
Martin: Implicit.. Relationship does the coupling of interactions.
Tony: We should do the internal relationship.
Martin: we don't do any internal realtionship.
Nick: Can we reset?
Martin: We dive into the details..
Nick: everything in role is other locations..BPEL instances etc.. You can do it right now?
Participant what is adds value?
Tony: I am trying to bring any value..?
Martin: We are doing any implementation..
David: In CDL we are doing what each field will do?
Steve: How do we do endpoints? Let us focus on the constructs..
That is better way to do.. Otherwise
Martin: Do we have to write pariticpant for the Buyer which is describing the single behavior?
Steve: In terms of spec.. what should we do?
Nick: No need. Could be a bug.
Steve: Next is behavior.. ( We have done roles & participant)
Assumption: notDone is seen as cancel in the sellerI
Nick: List of behaviors in role Type.. Do we have usecase?
Discussion on Channel Types for Request&Response and Two one ways ..
Tony: Is there any mechanism.. to pass around the channel within a participant?
Nick: I don't think we can talk treat channels from "other" variables.
Kevin: Do we have to change the name?
Nick: We can change.. But channel is not just one end point.
TWIST usecase (See page)
http://lists.w3.org/Archives/Public/www-archive/2004May/att-0016/TWISTWholesaleTradeRequirements.doc
Buyer -> Buyer Role
TS Credit -> Credit Role
TS -> TS Role
Seller A, Seller B -> Seller Role
Credit A, Credit B -> Credit Role
Example CDL:
http://lists.w3.org/Archives/Public/public-ws-chor/2004May/att-0032/TWIST-SimpleExample.doc
-------------------------------------------------------------------------------
Minutes CHOR F2F, May 12-2004 Afternoon session
Note taker: Abbie Barbir, Nortel Networks
-------------------------------------------------------------------------------
1. Decided to move on the example tomorrow
2. Need to discuss some open issues that we have known about from previous meetings:
o Imports
o Transactions (Tony proposal)
o Package binding
o Coordination Protocol
o Dependency on WSDL 2.0 vs WSDL 1.0
o Other dependencies (on us or them)
o Bananas
3. Discussing item f other dependencies
On us: BPSS? DAML? RuleML? May need to start a relationship with these groups. Action item on Steve to contact these groups with an e-mail.
On them: xx-addressing/ws-md, xx-Reliability, xx-policy/compositor, XML, XML Schema, OWL, RDF, ws-security, xx-notification, xx-transactions.
Tony: Three options: 1. neutral, 2. put language constructs to invoke a particular facility, 3. or back a particular approach
Steve proposal: can not make descions right now, which set of standards we reference and how.
Jeff: I read the spec and we can delete references to reliability with no loss
Nick: No not true
Steve: ISSUE: What is it that we use in standards/spec that we care about? This should be issue 555.
Nick: Issue section 2.5.3 in the document should be deleted.
4. WSDL 1.1 vs WSDL 2.0
Jeff: Leave this at the last moment for various issues with WSDL + charter constraint.
Martin: Jeff made a good point on WSDL. Need to take a close on the exact impact on CDL.
Kevin: BPEL can not use WSDL 2.0. Is it impossible for CDL to work with WSDL 1.1
Nick: Need to invent a mechanism for that.
Tony: I agree with Martin is to look at the impact> If we have impact we need to wait to decide. Due to the influx of WSDL 2.0 we may need to limit our ourselves to stable parts in WSDL.
Jeff: even if we use stuff in 2.0 can define the equivalent using WSDL 1.1 extension points.
Martin: We do the touch points of WSDL and we try to minimize the points.
Kevin: May need to go with 1.1 and then have a new version fro 2.0
Steve: This is a simple tactical decisions.
Nick: So can we add this in the deco in terms how we define dependencies. This does not exist in the language. If use 1.1 we need to invent compositor. Need to know how to do it now.
Martin: Group should make a tactical decision on basing CDL on the March 26th version of WSDL.
Motion Approved.
5. Package Binding: David will present.
Material is already on the list.
Discussion on why we need 3 levels of choreography. Newer version of the doc can support this leveling. There may be a need for more than one schema.
http://lists.w3.org/Archives/Public/www-archive/2004May/att-0020/WS-CDL_Package_Binding.ppt
Tony: 3 layers. There should be a continuum and need to specify a minimum. This is the simplest business case.
Steve: This is not the business case. This is ease of use.
Tony: That is that.
Martin: Motion ban Different Choreography from David proposal. This is a red hearing.
David:fine
Martin: In Cannes we said we two define the upper and lower and leave the middle
Jeff: This is a red hearing. We should argue about the specifics of the proposal
Nick: The draft does not have those three levels in it.
Tony: In our spec there was a single schema. We should consider think carefully when element/attribute are required. Can do a description using the minimum. Need to have a single a schema. More values could be added in new instances of the choreography. Another approach is that you start with an instance document against a schema and instead of expanding we can have another document that corresponds to a different schema and can bring them together and introduce a 3rd that can validate against the schema. Need to understand the advantages of that.
Martin: Two things here, one is evil. It is hard to do partial schema. Either do 2 schemas that each is incomplete. May need to override missing things. Remember we need to avoid re-writes. For ease of use we can have different schemas. There is No notion in WSDL of incomplete document. I think filling stuff we really do not need.
David: You saying we need a document that really defines the CDL and at some point we can replace it with something.
Martin: Missing things can be added through cut and paste.
Nick: How do you know if a document need to define a token locator or if it is required or not.
Steve: There is a precedent for using different schemas (RuleML). Can be reasonable to define different choreography schemas. This is not evil.
Nick: There are problems in doing that. I agree on slide 9 from David. Need to have balance in the two extremes.
Kevin: I agree it is useful. It should not be in this WG. CDL can define the minimum set that all 100 can do to use. We need to standardize the lower mapping.
Tony: If done probably this may be good.
Monica: Substitute is a good idea. This may be valuable.
Martin: package binding must provide new choreography. Can not override type values
David: Agree that this is a new choreography. But the fundamental thing is that you can not change interaction.
Nick: How does that relate to template.
Martin: Class Q
Add
new t ...
This is how template is used in C++. Can use this. This is like new schema.
Nick: No they have the same BNF.
Martin: David proposal is not the same as this.
Steve: There is merit in David proposal. Proposal is how to turn that into templates so there is no addition only substitution. Action item: New proposal from David.
Kevin thinks that this should be outside the WG scope.
Jeff: I have some problems with templates.
Martin: If somebody came back with a proposal, would Kevin or anyone else oppose.
Kevin: May be I miss understand something.
Monica: This relates about if the name is unique and does it change.
Nick: This may be a different thing.
6. Imports: Monica on the case. Slides on the list.
Nick: need to be clear what to import. What is visibility of horizon
Monica: Visibility spec it is whether you can use the import. Where segmentation occur, etc. Constrains on when and what you can import.
Jeff: I do not know what to do with your proposals. Need a proposal at the language level.
Kevin: Many other spec has done imports can leverage from there. What is the purpose of imports? Need to be flexible. Can allow different files by different people. Proposal 1 : imports are limited to CDL fragments, schema and wsdl. Proposal 2: Conflict resolution for imports.
Nick: +1 to Kevin. Keep it simple.
Martin: Need to beef up the text. Action item on somebody to do that.
Kevin: We need another import type
Steve: One of the difficulties understands what the intention of the section is. Importing statement can be used to support authoring styles etc..
Nick: I will take the action item in combination of Dave.
Martin: These apply about the receiver end.
Steve: This is more info hiding. This is an ISSUE. This is on the export side.
7. Coordination Protocols/Bananas
Steve: Will not discuss until we have a proposal
Nick: Main issues for coordination here: ISSUE 274 address part of that.
Martin: Why are they different than reliable/coordination
Nick: CHOR need to have an abstract definition of the characteristics
Martin: Need to state constrains on reliability protocol.
Tony: It is the clarity
Martin: goes back to dependencies. Need to enumerate the characteristics. This give the class of protocols that u can play with
Steve: Remember why used spec x and why. For this we know the why buy we do not which spec to use.
Martin: Need to define the abstract characteristics that we need
Steve: For alignment then what we need is a QoS on the message.
Nick: In the original proposal I felt that reliable messaging is the answerer to alignment. It is not in the current drive. Need to re-examine the sections in the doc.
Martin: Let us do it top down approach.
Nick: The spec does not work this way now.
8. Transactions: Do next day
-------------------------------------------------------------------------------
Minutes CHOR F2F, May 13-2004 Morning session
Note taker: Charlton Barreto webMethods
-------------------------------------------------------------------------------
Reviewed minutes from the 2004-May-04 teleconference.
http://lists.w3.org/Archives/Member/member-ws-chor/2004May/att-0015/20040504_0.txt
Action Items from 2004 May 04 teleconference/minutes
------------
ACTION: Greg to code up use case (from Requirements document) in CDL. (0301, 0309, 0316, 0323, 0407, 0413, 0420, 0504) Done
ACTION: Code banana calculus examples in CDL. (0316, 0323, 0407,0413, 0420, 0504) Done
ACTION: Steve, Nick and Greg to list the resolutions made at the face-to-face and the issues in Bugzilla that this version resolves (but may be none as the changes are mainly editorial in nature). (0407, 0413, 0420, 0504) Done
ACTION: Steve to send in the final Q&A. Done
ACTION: Steve to send the FIX protocol documents,links etc. (0413, 0420, 0504) Done
Transactions Presentation - Tony Fletcher
-------------------------
See Tony's presentation: 4 main points.
This is trying to say where does a transaction start? Or, which messages are included in a transaction and which are not?
We intend this to to overcome current limitations.
- Enable a single transaction cover several roles.
- Get a transaction from point A to point Z we need to propagate it as described in the proposal.
The proposal covers how the outcome affects the choreography.
We may ask for a choreography to cancel or confirm a transaction - to cancel in part or whole, or to confirm in part or in whole. Very often you want the ability on a transaction to confirm some roles and cancel others.
Martin: then asked the following - so in some transactions you care about the outcome and in others not.
Tony: replied yes, using the example of a travel booking - you choose one airline and cancel the reservation preparation with the others.
We tried to be as non-invasive with the syntax as possible with this proposal - what we want to happen, when we want it to happen, but not how it happens - purely declarative w/i CDL. What and when, not how. .
The only addition to syntax in the package blocks: transactionMappings - used for when you design two diff choreographies, yet want both to participate in the same transaction. Basically this is syntactic sugar that we many not need.
Per Nick, perform does this sort of gluing so we may not need it.
Interactions are bracketed to indicated which interactions are part of the transaction. We mirror how this works in this proposal with the use of the transactionLabel element.
David: asked when you see this, does it mean that when you do an interaction, it is implicitly a 'start'.
Tony: replied that if you see an interaction, it means that it is a straight interaction w/no transaction semantics. If you see one with a transactionlabel, it implies that it is part of a transaction.
David: then asked how do we know when a transaction is ended?
Nick: added that he doesn't like inferred behaviour; that he'd like this to be as explicit as possible.
Monica: feels the same way - she is concerned with implicit start, since one is assuming everything in the scope of a choreography is in a transaction.
David: then posited the following: Say you have A, B, C three roles in a choreography - message gores from A->B in an transaction, then you have B->C in a transaction, so either A->B or B->C can happen. What if we have different initiators? What are the overriding rules to ensure syntactic correctness?
Tony: replied that you label the interactions in a transaction and these can be interleaved freely, yet the interactions w/i a transaction must be in a tree.
Tony then continued with the presentation:
Terminating transactions - proposes using a work unit where you can say that using 'transactionAction' element you can tell what transaction action to perform - confirm or cancel.
Steve: then asked what does 'ncname' refer to? Have we mixed examples in this?
Tony: replied that we do and that we shouldn't have mixed them, and that he'll will fix them.
Tony continued:
Rules of use for transactions are on top of the syntax.
When you've done your confirm or cancel, you need to get the result back. transactionLabel morphs into a variable name which has a value of 'cancelled' or 'confirmed' which you can test in the guard. No syntax as of yet for this - can someone help with this (Martin or Steve)? Details of syntax may not be quite right at the momemt, but this covers the basic idea.
Steve: then asked: What i'm trying to understand - these aren't actually requirements - so i don't know what they are used for, and what are the benefits? when we're dealing with a choreography, we have put in alignment of state in CDL, so we know that two parties are aligned w.rt. their business understanding, so given that we have state alignment, i have difficulty understanding what you use transactions for. if i generate the endpoints, is there something it gives me there? if i have two interactions, and one is non transaction and the other is transaction, are they bi-similar? if so there's no reason to have this. Why have explicit transaction demarcation?
Tony: replied that we with this we have observable behaviour and choice.
Nick: then raised the following: With or without explicit demarcation, we need to answer whether we need to have the concept of a transaction in a choreography? Then we need to figure out whether we need more explicit power in this? Even if the proposal solves all the issues regarding this? What are we buying with it? Do we need to have transactions at all? I think this is what Steve is asking. Choreography has concept of isolation and transaction handling and finalisation- finalisation means more than composition. Yoran Goland doesn't agree with this, Nick believes finalisation is better than composition. I don't know if we can do it in first or second release, but prob is when you have two endpoints, if fault occurs on one side, how do you communicate it to the other side. They are not observable in the choreography layer (although at other layers). If something happens on the seller side, do we need to go back to the buyer side? This needs a coordination protocol. Do we want to do this? Aligning two partners means more than aligning interaction. We need to align this as well. This is QoS added to users of choreography. The same things that align gives them to ensure that values are exchanged, that transaction protocol gives you assureance that if something happens at leaf, you know about it, if it happens at parent, you know about it. If choreography doesn't handle this, we need to amend it, because choreography needs t/b able to describe this - Tony's proposal is to add extra power to this coordination. So there is a lot of business value in this proposal. I was looking at Michael Shop/Shore presentation on state alignment's importance for businesses. What choreography will do is give mechanism to declare thsi stuff, but not provide a full solution, but give you handlers at the same 'height' as per BPEL. So thisi is the value - compatibility for types, correlation sets, mirroring for free. So this is huge value proposition.
Martin: then asked for us to jump back to requirements. We're trying to do something. We tell the group whether something goes wrong, and how we're going to clean up. This is where I think the requirements are. So don't we already have this in CDL? Don't we already have this grouping/scoping things in the language? Tony my concern with this is tying the scope of a transaction to a choreography unit. So i may want a choreography with 2 or 3 transactions in it. There may be another approach that will work. If this can be provided already by existing methods or another approach, i'm open to it. But i think we needed an explicit way to scope this.
Steve: then indicated that he thinks it has to do with bananas at the end of the day. The reason we group things into choreographies, is so that when we do the endpoint projections, we can do things in a grouped fashion. But how do we deal with failure, how do we observe it and propragate notification of failure to the endpoints? We're reacting to a message that is observable, and if that message is the result of some transaction failure or success, it doesn't matter, what does is that it is observable, so how this is handled is all in the naming of this observable message. So do we need an explicit term 'transaction', since in Steve's POV, it is an observable.
Tony: replied that this has to do with delineating a block as being part of a transaction. We finish the transaction at this point, and want to confirm or cancel it at this point (via guard). How we make one decision or another may possibly be hidden. We may be making business decisions here - so if we make a decision to cancel or confirm a transaction - a block - we can follow choreography A for cancel and choreography B for confirm. If we know the result of a decision, we can pursue different choreography paths based on it. There's a clear choice point - this is what is meant by my single word response 'choice' - and we can use the choreography to map out all the possibilities.
Monica: brought up three things - she has questions about assuming transaction behaviour. she also asked ?s about propragation. and she saw that microsoft guy's presentation, and the last thing i saw from that presentation was [something inaudible which was not elaborated] then my last point - exceptions - do we really handle excptions in a choreography, or does it happen 'below' us - do we pass it through as a conduit (it relates across the board)?
Tony: responded to the last question (exceptions) - yes.
David: then indicated that this [transaction] is a separate way of grouping interactions beyond what choreography already does, so we're introducing complexity in this that may be hard to manage; I don't like the idea of introducing multiple mechanisms for addressing what I see is the same objective.
Tony: responded that we have a choreography here - and we want to put markers in to say, ok, this interaction in a choreography is part of a transaction.
David: replied - So I want this bit to be in a transaction, so i put it in a separate choreography.
Steve: then indicated that this may be a level of expressiveness that isn't covered in CDL, but Tony's document doesn't describe it. Nick agreed. Steve then proceeded to say Nick wants operation semantics, and given that CDL has this, we need operational semantics for your proposal, since it may well reduce operational mechamisms existing in CDL - we may need to make this expressive power, roll it into the system, avoid the multiple mechanism approach.
Martin: indicated that we may be hung up on the use of the term 'transaction'. What he thinks Steve is saying is that we need to understand the requirements, identify the gaps, and address it in a [wholistic] approach.
Nick: indicated that he disagrees with explicit transaction propagation, but agrees with explicit transaction cancel/confirmation, and expressed interest in seeing what Tony is trying to achieve with this.
ACTION: Tony to look at element choreography notation to see how we may be able to roll up transaction features into it.
ACTION (priority): From Nick: Let's 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: seconds the example approach - if we have a common example rich enough, there will be a lot of interest in expressibility to address this. Let's 'finish' this example, then have Tony take the 'brain dead' transaction version (existing model in CDL).
Tony: agreed to do this.
Nick: asked if can we have an example using bananas before the next F2F?
Steve: said he has Gary working on it.
Martin: then indicated that we know we have existing characteristics, there are some hooks there already, what can we do with these, what is the min we need to do, let's extract these and then see if we need something in addition to what we have.
The following are notes taken from the board
Planning
--------
1. Editing the spec
2. Primer editing
3. Examples (fully documented)
4. Issues resolution (proposals/contributions)
----- timelines ----->
Resources.
M J J A S O N D
-----------------------------
As we proceeded to planning,
Martin: asked what will it take to be acceptibly complete with this specification? CDL v1.0?
We then broke down the existing timeline and what we can hope to cover in this time.
Martin: - We have:
7 months @ 2 issues/proposals/month = 14 proposals.
We have 80 open issues.
1. Editing the spec
Martin & Steve: asked whether separate editors for proposals?
How do we maintain to-do list? Nick - need to assign owners of these tasks and the to-do list.
Nick pointed out that they have:
- Word based (golden copy owned by DB)
- To-Do spreadsheet (owned by GR)
Steve: asked when is the next editing call (Monday per Nick). Steve then asked if Nick give some assessment - tasks he wants people to do for editing - at the editing call, and see if anyone on the editing team can help.
ACTION: Nick to prepare a list of tasks for editing, and at the next editing conference call, will ask those present to help with them.
Kevin: then mentioned that we should address spec editing now and primer later - not as high prioriy.
[Steve crosses out the primer editing item].
Martin: then added that we have a WD today - which is a good starting point. If anyone comes along with the need to add wsdl binding, etc., that can be added. Someone will have to make a contribution for something they think is important.
Steve: then indicated he'd rather us not lose these items [because someone may not volunteer to contribute].
Martin: replied that he'd rather we identify what the blocks of work are - what we need for completeness for last call - and address these if the WG feels they are important. If no proposals are offered for something not in the spec, then apparently no one thinks that something isn't really needed for last call.
Nick: indicated that he though that this is incorrect assumption.
Tony: then indicated that he thinks we need to focus on the spec, but I also think we should carry on the primer in parallel. If it s/b or c/b in the primer, then put it in now.
3. Examples
Steve: then asked if we should have an examples sub-group?
PROPOSAL: To create an examples subgroup - was agreed (with no objections) that we should. Mayilraj volunteered to do coordinate this.
4. Issues
Group consenus on that tasks
1) Editing the spec,
3) Examples and
4) Issues [Resolution] are the priority items for the group.
Steve:then asked if there any more that we need to discuss today? Group affirmed that we did - we need to prioritize the above tasks. As such:
Top priority 4) Issues [Resolution]
Second priority 1) Editing the specification
Third priority 3) Examples (fully documented)
And we expect the primer to fall out of the other efforts.
Martin: then reiterated that we are editing spec as it is today; if anyone wants to change it, it must be as a contribution.
Next F2F - London: First week of August; August 4-6 (Wed-Fri; Fri 1/2 day out of convention)
Following F2F - Manhattan: September 28-30 (Tue-Fri; Fri 1/2 day out of convention)
Examples
--------
At this point, we have a lot of elements to complete; let's dive into channelType.
At this time Charlton (the scribe) and Tony had to depart. The remainder of the day was to be taken up with completing the TWIST example, which was being documented by Steve.
http://lists.w3.org/Archives/Public/public-ws-chor/2004May/att-0032/TWIST-SimpleExample.doc
Summary of Actions
ACTION: Participant
ACTION: Roles within Roles
ACTION: Delegation Use Case (The Agent Acting On Behalf)
ACTION: Exchanges & MEPs. We will need to explore this relationship.
ACTION: For the editors: All examples should have unique names except where related to other elements.
ACTION: Relationships (1:1 behaviour?)
ACTION: Tony to look at element choreography notation to see how we may be able to roll up transaction features into it.
ACTION (priority): From Nick: Let's 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.
ACTION: Nick to prepare a list of tasks for editing, and at the next editing conference call, will ask those present to help with them.
Summary of Resolutions
RESOLUTION: To create an examples subgroup - was agreed (with no objections) that we should. Mayilraj volunteered to do coordinate this. Passed.
RESOLUTION: Group should make a tactical decision on basing CDL on the March 26th version of WSDL. Motion Approved.
Summary of New Issues
ISSUE section 2.5.3 in the document should be deleted.