http://lists.w3.org/Archives/Member/member-ws-chor/2003Sep/att-0009/SEPT03_F2F_DRAFT_AGENDA.htm
The W3C Web Services Choreography working group met in Seattle, hosted
at Attachmate, between the 15th and 17th September. About 20 people
attended the meeting. Much was achieved at the meeting. We have come
out of a period of divergence and are into a period of convergence.
A divergent period in which use cases were gathered and many
discussions occurred has resulted in the publication of a Draft
Requirements Document. This same period has resulted in two
contribution to the working group, one from CommerceOne and one from
Oracle. Both contributions reflect the requirements to date and the
discussions to date.
The Draft Requirements Document was very much a heart beat publication
and a work in progress. The F2F meeting in Seattle took this document,
examined it with a fine tooth comb and issued a list of changes. Both
contributions were presented and work was delegated to a small group to
move the contributions further along the track with a view to combining
the best of both of them and ensuring that they meet the current
requirements.
The work at the F2F is clearly an indication that the working group is
moving to a convergent phase in it's life. We anticipate significant
progress in the coming months in which the Draft Requirements Document
is re-published and becomes a consensus publication in terms of it's
content. Furthermore we anticipate rapid movement to a single
contribution that becomes the strawman for the working group. We expect
the editors team and the contributors to meet regularly to this end and
we expect substantial results to have been achieved before the end of
the year.
We would like to thank the participants at the F2F for their
sterling efforts and we would like to thank the editors of the Draft
Requirements Document and the contributors, namely CommerceOne and
Oracle, for their valuable input.
Martin Chapman and Steve Ross-Talbot
|
Oracle | ||
|
Enigmatec | ||
|
|
| |
|
W3C Staff Contacts |
| |
|
|
| |
|
|
|
Members:
|
|
|
|
BEA Systems | |
|
Choreology Ltd | |
|
Cisco Systems Inc | |
|
Commerce One | |
|
Fujitsu Ltd | |
|
Hitachi, Ltd. | |
|
National Computerization Agency | |
|
Oracle Corporation | |
|
Oracle Corporation | |
|
SAP AG | |
|
Sun Microsystems, Inc. | |
|
TIBCO Software | |
|
|
|
Invited Experts:
|
Attachmate |
Guests:
|
Oracle |
Raw IRC logs at: http://www.w3.org/2003/09/15-ws-chor-irc
http://www.w3.org/2003/09/16-ws-chor-irc
http://www.w3.org/2003/09/17-ws-chor-irc
Meeting scribes were: Nick Kavantzas, Tony Fletcher, Mayilraj Krishnan, Francis McCabe, Jeff Mischkinsky, David Burdett
SRT: Welcome to the f2f hosted by Attchmate
SRT: will do role call, then have a brief intro from the hosts, then on to agenda review
http://lists.w3.org/Archives/Member/member-ws-chor/2003Sep/att-0009/SEPT03_F2F_DRAFT_AGENDA.htm
MC: role call (see above)
Attachmate was thanked for their very generous offer to host the meeting and they a brief company overview.
Since the last meeting, Jean-Jacques has joined Attachmate.
Martin. Summarized what we are doing, transitioning from identifying requirements to writing the actual language itself
Martin. This meeting as about how we make this transition.
Martin. Continued to summarize published agenda
Changes and additional topics:
Tony Fletcher to present is Transaction requirements during Tuesday’s requirements discussion.
Specification Contributed by Oracle will be discussed Tuesday afternoon.
Janet Daly will attend Wednesday morning and talk about liaison.
Minutes from 9th September still need to be published so need to be reviewed at next con call.
Steve: Actions from mtg on Sept 9th:
ACTION: David will deliver BurdettML proposal.
On agenda for this meeting. DONE
ACTION: We should start using bugzilla effectively. This will be on the agenda for the next meeting.
On agenda for this meeting. DONE
ACTION: Members of the group must read the requirements Document before the F2F.
On agenda for this meeting. DONE
Steve. Will walk through the requirements document between 1.30 and 3PM today. Objective is focus on errors, omissions and redundancy, as well as any urgent wordsmithing.
Steve. Will people who have made comments on the requirements document, please point out the emails to Steve so that they can be included.
ACTION:Address the requirements with respect to the taskforces at the Seattle F2F. Chairs to place on agenda. We need to reconcile the requirements with the taskforces at the f2f, since they are implementing the requirements.
On agenda for this meeting. DONE
ACTION:SRT to change the location from Belmont to Bellevue. DONE
ACTION: Members should send an email about dial-in requirements so that we can organize it ahead of time.
No emails received, so no dial in provided. DONE
ACTION:Directions to Attachmate MC/JJD
Sent to list. DONE
ACTION:SRT to send most recent requirements spreadsheet to the list. Ongoing
ACTION:Group will review Bugzilla issues list.
On agenda for this meeting. DONE
ACTION: Chairs, Oversee the organization of the task forces.
On agenda for this meeting. DONE
ACTION: David Burdett to provide a design collaboration use case. ONGOING
ACTION: Martin to propose text for call-back use case.
On agenda for this meeting. DONE
ACTION: DB to produce a commentary on how Burdett ML meets (or not) the current requirements.
On agenda for this meeting. DONE
ACTION: SRT to send mail to the Semantics tag as to what he is looking for to initiate the discussion on semantics in the WS-Choreography language.
LATEST (NEW ACTION): SRT Brought semantics question to the TAG. On chairs coordination call, he asked about semantics for/of choreography. A new Semantic Web Services Interest Group is being formed in about one month. Issue will be sent to that group when it is formed.
ONGOING
ACTION:Discuss F2F in Dec next meeting. On F
Need to fix next F2F - is it in Australia?
There will be more discussion later in the meeting, and need to make a firm decision.
On agenda for this meeting. DONE
Task Force 1: Harvesting
Monica. Updated Requirements Matrix.
Monica. Need to work out what we evaluate, e.g. BPSS
Monica. Analysis of the matrix and evaluation will help us identify gaps. Will try and complete the matrix for later on today and publish.
Martin. Who's been involved?
Monica. Mike Champion, Charles (ed: who is this?), Malraj. Haven't met since July although there have been discussions.
Martin. The task force was to look at existing specs rather than look at new proposals. Recognized you could have looked at the new specs (C1 & Oracle) using the same approach.
Monica. OK so I'm suggesting another activity.
Jon. These two proposals are core to the work of the group as a whole therefore should really be looked at by the group as a whole.
Monica. Can we use the categorization of requirements as a way to identify gaps as well as coverage.
SRT: URI for Oracle submission is: http://lists.w3.org/Archives/Public/www-archive/2003Sep/att-0018/wscdl_v1.zip
Jon. Thinks this is a good idea.
Monica displays requirements spreadsheet/matrix ( http://lists.w3.org/Archives/Public/www-archive/2003Oct/att-0000/AssessmentToReqtsCategories-mm1-091503_1.xls)
"Green column" is the list that the task force 2 categories identified. The Yellow column contains categories from the requirements.
The task force requirements were derived from a task force 2 brainstorming session.
Monica - let's start by looking at the gaps.
Composition. This maps to the TF idea of nested processes
Still need to include correlation - discussion still needed.
Steve. Computability - should refer to whether it is executable or not.
Jon. Should we go through this and measure against the requirements document.
Monica. Have we missed some of the topics? Do we map our study against requirements or do we map it against an area of functionality while recognizing that the requirements document is incomplete.
Steve. Two steps. This should feed into the requirements document anyway i.e. make sure we have captured everything.
Next step is map into BPEL, etc.
Jon. Good idea to include out of scope section - Steve agreed.
Frank. How do we get the CSFs from this?
Steve. They aren't here. There's a whole section in the agenda to look at CSFs
Task Force 2: Semantics Task Force
Frank. Both Frank and Jim Hendler have had zero time to work on this.
Frank. Thinks that the importance of this work will show up later.
Tony. If you had had more time could you have made more progress, or are you waiting for language features to be developed?
Steve. JeffM, Frank. Discussion around need for semantics and how important it is.
Yaron. This group does not need to solve the problem of discovering semantics.
Yaron. Currently all usages of web services are carefully negotiated. Doesn't think that anyone will be ready for automated discovery any time soon.
Yaron. Recognizes that discovery is needed, but is not required soon and that we should focus on other topics first.
Yaron. Key issue is how do we work with a partner what our expectations are for choreography and discovery later.
Steve. Thinks Frank's & Yaron's points are reconcilable.
Steve> FM and YG views are not really different. They are, as Yaron pointed out (prioritization) and Frank (might not be what we do in this group) different views of the same thing.
Steve> FM semantics are not salt. We cannot sprinkle it on after the meal has been cooked.
Steve> JD the dominant focus is inside the firewalls so discovery is not an issue yet.
Steve> YG Discovery is a big issue for many of my clients. They ameliorate their discovery issues inside the firewall. They do it as a fudge so they do not need standards to get there now.
Frank. There is no energy within WSA to do any work on discovery.
David. Suggested how you define semantics is within scope.
Frank & Yaron - disagreed
David. All I'm suggesting is that we include descriptions at some specific place in the spec.
JJ. Agreed with David.
Frank. Our job is where in the description of the pattern of exchange in a choreography you explain what is meant.
Steve> DB do not want a generalized way of describing semantics - outside our scope. But for it to be useful our specs should be readable and understandable.
Steve> FM> U need a lot more for interop
Steve> YG Do we have a contribution to make there? Clearly if a chor spec is not understandable then that’s not a good thing.
Steve> YG There are 1st and 2nd order effects.
Steve> DB We should be able to describe the chor in English
Steve> Thoughts from SRT: Phew they all agree ;-)) Adding comments to chor is a good idea
Steve. Putting comments in code is good practice. But there is the problem of ill disciplined programmers.
Yaron. Should have a semantics section in the spec.
Yves. Semantics is just meta data.
Steve (wrapping up) ...
Steve. Need to ground this (as Jeff said). At lowest end have need for comments (David).
Make the language easier to read (Yaron). Need Ontologies (JJ & JefM).
Steve. Seeing layers where semantics can add value.
Steve. Next steps should be to summarize where semantics can add value.
Frank. We're still thinking of semantics like salt - makes the spec taste better.
Frank. We need to identify the key relationships within and between the elements of the language.
Yaron. Need to get our extensibility right so that others can more easily add in more comprehensive semantics.
Frank. Quote "You can’t do semantics on your own. It's all about relationships " ;)
Jeff: for the record: I didn't go as far as saying we "need" ontologies. More precisely the use of ontology technology -- to the extent that it's syntax/semantics are well-defined -- MIGHT be something that's grounded enough to be useful
Jeff: I like the suggestion wrt extensibility points -- it provides the perfect mechanism for people to experiment without breaking interop
I view the use of ontologies, semantic web, rdf, etc. as not really being ripe for standardization
Steve reviewed the task forces: two taskforces set up:
harvesting existing specs & standards (BPSS, BPEL, BPML
task Force 2: formalisms :Pi-calculus & Event calculus
more progress in the harvesting task force
comments on where task forces are and what they should be doing are needed
What value are we looking for from task forces
Nick is concerned with progress
Need a formal meeting structure for the task forces
More progress needed on task forces in the next few weeks
What are the next steps, what are the priorities of the task forces
Yaron: Need to work on requirements
Steve: Aim to get clarity on results of task force wrt input to WS-CHOR
The task forces were further discussed later on in the meeting.
Steve: req doc produced by scanning email list for use-cases
Yaron: Requirements doc should be text based (i.e., should be explicative of the requirements)
Yaron: collect words for the glossary
Started reviewing each requirement looking at whether it is generally ok (maybe with word-smithing),
dubious, a duplicate or out of scope (deletion candidate). The requirements editors will take these as directions for another draft
Note 1. Specify the context of a requirement in terms of a CDL or its run-time instance
Note 2. Formatting/style: requirement should have an explanation as part of the description
Note 3. Should have been a CSF-based approach
Note 4. Glossary and glossary compliance
CR-14 needs word-smithing "Implementation"
CR-010: Wordsmithing needed (binding mechanism, diverse technology)
CR-023: more word-smithing needed
CR-004: contentious: What is meant by querying the state of a choreography
Choreography must be in an identifiable state
Must have state, must be describable, must be identifiable
Mutually visible states
Yaron: architectural principle? We are done when nothing left to cut. Will a given feature break applications if removed? Can it be added later without breaking anything?
CR-052 Unclear as to what it means
Tony: meaning needs unpacking
Should be requirements on the language, use of the language, instances of the language
John: Wordsmithing clarification needed
CR-053 wordsmithing
CR-056 wrong section. related to composition
Monica: is this to do with security?
Steve: Double quotes worry me
CR-013
is implementation suggestion, not a requirement
management requirement: we have to be able to observe events and states
CR-016 is in the charter
wordsmithing needed should be a constraint
CR-020 implementation feature not part of the language
not needed
implementation requirements are candidates for deletion from requirements doc
Wordsmithing: instance is unclear,
CR-005 wordsmithing
unclear
CR-009 Why pick on time?
May be other kinds of event
Not the same as reliable messaging
DaveB: three sorts of events: sending messages, receiving messages, time has passed.
contentious
time is part of the observable state
CR-018: because it's SHOULD, leave for later
CR-026: the crowd cries out - what does robust mean?
Yaron doesn't think exception handling belongs here, since that implies if/then/else logic and he doesn't think we should have any of that sort of thing
could be reconciled if there was another level of handling
steve: I have a WS, and I have a choreo -- what happens if ws dies a horrible death -- is that observable to me -- if so, then need to surface this untimely death in "the choreo"
CR-026: clarify in conjunction with CR-005
CR-027: really 2 parts - err/fault and compensation
yaron can't see a req to distinguish exceptional choreos from normal ones
discussion about whether there is anything special about "compensation"-related messages and non-
martin: if part of bus rules between partners is "if you do x, then y happens" is the fundamental issue
steve: is there a reason to distinguish compensation mess? -- KEY issue
[The following were discussed on a different day but are placed here for continuity.
Chronological order can be found in the raw irc logs]
CR-030- Clarification on unhandled exceptions
CR-031 Possible Duplication
CR-032
YG: one person is exception is another success.
DB: Talking about dependencies between chors.
FM: Does it amount to recursive state machine?
JD: sub chors error needs to be propagated to parent
YG: propagating the message. All internal implementation
JD: I am talking about message passing sense not java way
YG: that is ok
KL: Is there any use case related to this requirement?
MM: Does this relate to MM's use case?
Martin: Yes..
Clarification on propagation required
CR-033
YG: Is there in scope for chor def? Is it the product will handle internally?
YG: it is out of scope
KL: How do we assign the messages?
YG: garbage choreography. Collect all the expired orders. Do we need?
How can I assign an error/exception message to a choreography instance that is not instantiated yet?
MC: Any body to defend?
YG: Configuration issue for message handling system. Not a s/w group for chor
DB: I can come up with one use case. Describing the req..
Candidate for deletion
JD: Roll up all the error related reqs.
CR-043
YG: how we need to treat the message is not chor. business.
KL: Should not enumerate all the errors.
Steve: One partner cares and another partner need not care..
YG: WSDL does not have operations .. No url to receive all the messages.
Do we need to punt this issue?
JD: Do we need to application and system errors?
JD: If is not discussed sufficiently it will re-resurface
Further discussion, heading towards a deletion candidate
CR-61 Duplicate
CR-64
Steve: process monitoring this and detecting
YG: Conceptually possible to monitor everything going on the system
KL: Does this belong to exception?
Steve & JD: Management category
Reclassify to Management and word smith
CR-65 & 66
YG: I don't like these
JD: It must collide the existing web service.
Candidates for deletion
TF: I think we need to have some model for chor. Each activity running on separate node.
TF: Diff instances should run. Actual model of the language should capture
CR-67
JD: Drastic word smith needed
Major clarification ( the group doesn’t understand any of these)
CR-68
YG: Unknown errors in WSDL (interpretation?)
Steve: do we need to classify the types?
YG: It is my business to capture the exception and sent to the other side. text message or something else
FM: You can answer that question with more conviction .Get more core concept in the chor.
May be everything is in message. But that is not the essence. Notion of normal and erogenous chor.
It will make the diff when we compose.
Candidate for deletion
CR-69 Possible duplication
CR-070 Candidate for deletion
CR-002
JD: better to describe in some other way (relates to reuse)
Need wordsmith (Chor vs CDL)
CR-007 Wordsmith (Must, apparent state of the exchange)
CR-011 merge with 007
CR- 029
Martin: signals vs business messages
JD: Can we move this to error handing category?
Steve: I think we can move to semantics section
Group: No..
KL: suggest for deletion
Candidate for deletion
CR-35
YG: is it while loop?
TF & Martin: yes
YG: I agree with while loop and what about the termination?
Nick: Conditions may be public . Should be private (Question to YG) Why it should be ?
Martin: We need to have this debate… some time !
Further discussion required
CR-39
Martin: What is the meaning of among chor?
FM: Chors are not agents..
Nick: Chor can not talk to another Chor.
Clarification (among chor) and duplicate , deletion candidate
CR-51
JD: There was talk about minimal chor and would not put as a requirement
Candidate for deletion
CR- 55
YG: Assumption is correlation tied to chor.. But it really tied to WSDL
JD: This is about missing use case.
Martin: Ability to pass around ws end points
YG: I am ok with WSDL Expressible.
YG: Let us hope thru WSDL
Needs wordsmith ("Callback mechanism")
CR-060 Duplicate
CR-015 [ed: nothing record in log on this one]
CR-044
MM: Is it a security requirement?
JD: What is the information that we expose to one partner..
Wordsmith (Information hiding vs Segmentation)
CR-017
JD: We don't have any protocol for negotiation
DB: Might be useful to have some context information in the chor.
Steve: Candidate for deletion
TF: does not belong in transaction not as a requirement.
TF: Could be in specification. Use chor instance what we agree with business partners.
JD: How it is different from use case.
TF: Could be use case. For language specification
Steve: Need Use case
Deletion candidate
CR-037 Reclassify ("Composition")
CR-038 Reclassify ("Composition")
CR-037 Wordsmith (What not how)
CR-038 Further discussion
CR-17 Probably should not be in Transaction category. To me it is saying that it is a requirement on instances of use of the language that they should be usable in negotiations between partners.
CR-048 Duplicate
CR-057 Reclassify
CR-058 Deletion candidate
FM: Are we giving a chance for authors to review?
Steve & Martin: Yes
CR-59
TF: I am thinking of the way ebXML envisages partner negotiations which include agreement on technical aspects via a CPA.
A CPPA includes a pointer to the definition of the business process interchanges - currently a BPSS instance.
Could also in the future be a WS-Chor language instance. Should be something to this effect in the spec doc.
Martin: Multiple parties vs single party
JD: Do we have a use case to support this?
Martin: Def we need clarification
Martin: this is about sending same message type
TF: Can you do this at what price? Can you do it for 100 quantities? But same message type
TF: Then I can make the decision
Martin: Same party same message.
TF: I have some to add in the transaction
Clarification (of use case) needed.
CR-003 potential duplicate
CR-006 Duplication (KL: important requirement)
CR-024
Leave in - effects bindings - but folk unclear on meaning
Same as 3? Yes 24 is duplicate of 3
CR-034
OK but duplicate? About composition of Choreographies - clarify hierarchy in this requirement
Clarification of hierarchy needed and maybe a duplicate.
CR-036
Dynamic whereas 34 is static design time? But seem to be related.
Needs clarification.
CR-040
What is 'parallel composition?
David: a choreo can have two sub choreos that go on in parallel
Steve thinks maybe his requirement so he will clarify.
Clarification needed
CR-041
Does this mean able to express sequence of events and events that can happen in arbitrary time order (in parallel)
Major clarification needed.
CR-042
Not understood.
Major clarification required
CR-047
OK but put in 'Re-use' category or make a new category for this - ref use case 4
CR-054
Degenerate case if a choreo has a single entry point.
Probably OK if it said 'should'
Agreed it makes sense but not as a Req.
Candidate for deletion.
CR-062
Required but maybe a V2 feature - low priority
CR-008
Add 'from its viewpoint' Leave in here and remove / combine duplicate from elsewhere.
Wordsmith and potential duplicate.
CR-049
May rather and may be V2
A “MAY” not a “MUST”, and possible a V2 feature.
CR-050
Wording appears wrong way around.
Potential duplicate.
CR-012
Possibly re-classify under semantics?
As an aside need some ease of use reqs!!
Re-classify.
CR-025
Imposes terminology.
Need to distinguish types of things and instances of things
Implies requirement for a model!
Needs major clarification.
Completed pass through Requirements
Steve proposed a process for going forward. Anything marked as a deletion candidate needs another pass. We have to ask the group in the public mailing list..
Within the set period, if nobody if defending then it will be deleted.
Steve: My aim is to allow the wider group to defend.
Jeff: How many times we have to make the decisions?
Steve: I am quite happy for suggestions.
JD: Aim is to come with the refined draft.. It is up to people to go thru and tell us what they like or don't like.
Steve: Do one more time sanity check and then we get to go.
Steve: we need some process for clarification of these?
JD: we stopped doing word smithing because of the time
YG: Editor get to do it for unambiguous things.
JD: If we cannot the clarify then we can ask the wider audience
Steve: That is fine.
ACTION: Steve: Will put all the comments on draft requirements above into the requirements spreadsheet and send out.
In summary the group agreed that the editors should address the comments/suggestions listed above and propose a new draft. People should keep an eye out for their favorite reqs being deleted and defend them. Changes will be clearly marked so nothing should slip through.
Frank to give us tutorial on CSF - Critical Success Factors
top down - identify goals -> CSFs -> requirements (must be measurable)
jeffm: requirements must be SMART : Specific, Measurable, Achievable, Realistic, Time-bounded
Goal brainstorm:
- capture the interaction of set of web service providers and requesters from a global perspective
- peer to peer ws relationships
- composability
- reusability
- segmentation
- not preclude interoperating with a number of emerging standards: e.g. bpel, reliability, transactional protocols
- language be usable by normal human beings
- interoperatibility and multiple protocol bindings
- declarative global model
- state alignment
- simple for simple things, complex for complex things
- verifiability
- implementability - spec should be usable immediately when finished without being dependent upon other specs
- extensibility
- simplicity
- CDL should be distinguishable from implementation languages
- facilititate use of tools to manage and generate descriptions
- machine readable
- mappable to graphical notation
- CDL should provide design-time and run-time validation
- enable recovery from exceptional conditions
- must be able to capture interactions in a mixed security environment
- we will be successful when we can describe a clear business case for the adoption of a choreography language
- should be possible to be do third-party software validation at runtime
- must be able to express conditional paths
- not restricted to b2b applications
- must have ability to express conditional start and completion
- should be helpful for generating skeleton for implementation and test cases
- sufficiently abstract to be robust
- must support wsdl 1.2
- must fit with the WSA
- low cost of entry for existing web services
- enable performance of one choreography to be dependent upon completion of another
- when exceptions occur, they must be propagated to different levels
- must not have any business semantics
- completion should be guaranteed, livelock and deadlock free
- concurrent execution of process
- reusability - write once, use many
- be able to express business processes
- correlate message exchanges
- important for CDL to be consistent with semantic web
- ability to specify various levels of qos
- expressible in terms of external observable behavior
- to enable the description of the semantics of the choreography definition to be easily specified
- computable
- scalable
- interactions should be atomic
A sub group met after the end on the days main business, to condense, and refactor the above list.
The results are captured in:
http://lists.w3.org/Archives/Public/public-ws-chor/2003Sep/att-047/CSF_Analysis.pdf
The following discussion took place on Tuesday morning.
Now Frank is reviewing the CSF activity -- yesterday's continuation
Frank: I did some analysis and the number drop down.. is not final
Frank: Talking about main goals
Frank: Interoperability, S/W Engineering, Business Scope, Community responsibility
Frank: Main CSFs are Support for independence - technical environment (Peer to Peer, not tied to B2B and B2C, Security)
Frank: Another one Semantics (Global model, verifiable at run-time and statically, state alignment, composable)
DB: What does state alignment means?
Needs clarification from Nick.
Jeff: It is not 100% or atomic.. State has to be aligned with infrastructure
DB: It is about role to role communication?
Jeff: We need not read that much into these bullet points
Frank: S/W Engineering (Reusable, scalable, secure (foundations)
JD: It is not really S/w Engineering.. It is architectural things.
Frank: CSFs has to be scalable.
Martin: What has to be scalable?
Frank: whatever we propose
Frank: Tooling (easy tool) and graphical presentation
Frank: Time to market (Not dependent on Future specs, support on WSDL 1.2, Zero cost of entry for existing web services)
Frank: Fit in the WS landscape
Frank: Based on XML tech, clear relationship with BPEL, Semantic etc
Frank: Distinct from programming languages, machine readable/processable, expressable as externally observable behavior
Frank: Support for Qos, not attempt business semantics
JD: I am ok with not building business vocabulary
JD: We should be able to capture actual generic business use case
JJ: Nothing should prevent us doing by exchanging the documents
JJ: Enables Business semantics to be built on top of it.
Martin: I think we agreed to stick with technical level and not address business contractual level
Frank: should support testing external observers, test case generation
Frank: enable recovery, express conditional paths, conditional start, end points
Frank: Chain choreographies (kind of composition space)
Frank: Support concurrent execution (parallel activity
Frank: support message correlation
Martin: Did we capture everything that we discussed yesterday
Frank: Yes.. I did ..
JD: Explicit reference on XML
Martin: When we do know we are in a shape (where we capture all the reqs)?
Martin: Do we feel that we are all on the same frequency?
YG: I think that we do need initial sketch .. Go thru the requirements document
FM: Everybody has to make sure their favourite things are in the requirements
Martin: We have the whole day to review the use cases, reqs and we can come back
JD: Yesterday there was a feeling that we have too many CSFs and Goals
FM: we don't have that many. We have 6 main CSFs
JD: First pass is review, and second is word smithing..
Steve: Relationship between mission and goal (what way we derive. Mission from goal, Goal from mission)
Steve: Reading the mission statement from the last F2F
JD: If you go thru the list (requirements) that some of it may not be attainable.. I am quite concerned about it
Steve: We can go to use cases, come back to CSF (requirements session is in after noon)
Martin: requirements and CSFs are intertwined.
Requirements editors to insert cfs into the requirements document and suggest wording sympathetic to the discussion above.
Frank McCabe presented an overview of the WSA WG draft output:
http://lists.w3.org/Archives/Public/www-archive/2003Sep/0087.html
Five models: Message Oriented Model, service oriented model, policy model, Resource Oriented model, Management Oriented Model
mm: in the policy section, do obligations cover business level
fmc: intended more for things like security, reliability, etc
fmc: tho not excluded
Steve: Use cases review, 11 in the document, do high level view of the use cases
Steve: What is the relevance to our requirements
YG: Better to go thru the requirements rather than use cases. But is my 2 cents. Not statement
Martin: Use cases demonstrating the features of chor.
Martin: If we can describe 3 or 4 illustrative use cases could be useful to the group. Not fragmented use cases
YG: David Orchard told me that we should start from the WSA use cases.
JD: Why should we expect WSA will describe the chor use cases
YG: They might have some. Clearly traveler use case.
Martin: They have use cases very much at the message level
Martin: We should take Travel use case.. But it may not detail all what we need.
Martin: We should tell WSA that use case 60% fit
YG: Yeah. That is ok.
Martin: Let us identify top level, variation etc
JD: WSA is actually looking for feedback from us -- when chor. has come up in their discussion, they have frequently said they are looking for material from WS-Chor to add to or modify the architecture document.
Monica: There are some use cases & discussion in email.
Martin: Everybody should have reviewed use cases. Any comments
MM: Let us detail the requirements from use cases and start drawing the complete elephant that Frank is talking about
JD: Actually I think lot of good material is in the use cases. It is presented sometimes without the context. I want something really easy to follow and comprehend
JD: We need to clearly present use cases retaining in a understandable way
Martin listed down 11 Use cases from the req document
Missing is callback, Multicast (Alistair’s) use case
Martin: we have to classify these use cases
Travel Agent, Quote Request, Really Big Corp all business type of problems
Martin: rest of them describing the features/variations of a use case
MM: Look at the two that I described, we can integrate into any of the business use case
JD: Monica's or some of the use cases may not describe the business scenario
DB: Do we have any for Multiparty? (Buyer, seller, shipper). Roles are fixed.
MM: You can probably use Multicast use case to what David is talking about..
Martin: How do we go forward?
Martin: I kind of volunteer to lead this activity for classification
TF: Clarifying.. Concentrate on the business use cases (three or four) and see the requirements how fit into this.
JD: I don't think all the reqs will be traceable to use cases but most of them will be. Non-functional requirements
will fall into this category
Kevin noted Ivana's mail with comments on Requirements
http://lists.w3.org/Archives/Public/public-ws-chor/2003Sep/0049.html
New Requirement from David:
It must be possible to have multiple participants with the same role in a choreography instance. E.g. you could have multiple suppliers all responding to a "request for quote". The number participating may be bounded or unbounded.
There was no objection to this new requirement, and the editors are directed to place it into the appropriate category.
Presentation from Tony Fletcher on business transaction requirements
YG: are these requirements part of the 80 side of 80/20
YG: no as should be able to do this explicitly
YG: reserve the complex stuff for v2
YG: TX not the same as reliability
JD: if no mechanism in language then how can emerging protocols be used
NK: need a way to demarcate
MC: most languages have scopes
JJ: simple control flows in first version
JJ: need these types of control flows
Comments on proposed requirements (treating the same way as our previous comment processing)
Req T1: describe Business Tx Creation
JJ: suggestion split into control flow requirements, demarcation requirements and TX requirements
major clarification - more emphasis on what not how is required
Req T2: describe business TX reception and transmission
JD: says need transmission of TX contexts
NK: should propagation show up in a language?
TF: choreo can describe several different participants which may involve passing on contexts
MM: need to discuss what other sorts of contexts
TF: contexts are mechanisms under the covers
major clarification - more emphasis on what not how
Req-t3: describe involvement in buss TX as participants…
JD: how different is this from t1
NK: more of a role view
major clarification - more emphasis on what not how
t4: describe two-phase termination of buss Txs
major clarification - more emphasis on what not how
ACTION: Tony to rephrase his requirements and bring back to group.
Martin demonstrated the W3C Bugzilla pages
Use the public bugzilla pages rather than the member one
http://www.w3.org/Bugs/Public/
Click on Query existing bug report link then go to product = WS Choreography
Have to use notes and comments fields to add link to people / emails
Steve mentioned that there is a bug writing guide (only 22 pages!)
ACTION: Editors of the requirements are directed to look at the issues list and filter each issue in a similar way to the filtering method used at the F2F.
Martin still concerned that we have not agreed the total overall shape
ACTION: Steve to facilitate calling an Requirements / Use Case editors meeting
Nick Kavantzas and Goran Ollson presents the Oracle WS-Choreography Language proposal
Proposal at: http://lists.w3.org/Archives/Public/www-archive/2003Sep/att-0018/wscdl_v1.zip
Presentation at: http://lists.w3.org/Archives/Public/www-archive/2003Sep/0051.html
[note scribe wasn’t paying attention and missed a lot of the discussion]
ISSUE: Synchronisation on slide 14 of Oracle presentation - add straightforward support for asynch as well?
SRT: The react construct might be expressable in terms of some modified ECA language. At least the declarative nature of these might prove useful. A uri in support of this would be: http://www.haifa.il.ibm.com/projects/software/amit/ and a further one might be the work in the reaction rules subgroup of RuleML http://www.dfki.uni-kl.de/ruleml/
MM: It is important to note that for choreography, we
should recognize the interaction between applications within an enterprise where the most pain is felt by customers today. This would change the focus from the PO scenario in B2B that many discuss to the actual focus of the interaction between an ERP,CRM and SCM.
Jon Dart indicated the message request-response may not be that different.
Martin said the distribution, variability and some requirements may be different, such as for reliability, security and non-repudiation.
Further to Monica's point, it would be a good idea if we had a major EAI problem as a use case. Furthermore it might help in establishing the business case for using a CDL within and across the firewall.
ACTION: Requirements editors to consider an EAI use case and think about within and across firewalls.
Need to compare and contrast the Oracle proposal with BurdettML - will address that tomorrow
Guards currently use XPath but could be anything else
Yaron recommends not having in at all!
Presentation represents current thinking - need to see the extent it meets the reqs
David Burdett re-presented his slides on BurdettML:
http://lists.w3.org/Archives/Public/www-archive/2003Jun/att-0037/WS_Choreography_v.0-1_Overview.ppt
Nick: What import does?
David: Import only collaboration types, not WSDL types
Steve: The underlying format is in a MessageFamily?
Nick: How do we do WS binding?
Yaron: We may use WSDL 1.1 operation for binding; point from MessageFamily to an operation
Nick: What about types; like state in David’s proposal; does it have a type?
Yaron: I don’t think we need state type at all
Frank: Dave you said: “Existence of a state can trigger an event”; what does this mean?
Steve: A new order has been magically created at the buyer, and as a result the state order sent is created that causes an event to occur. This is can be easily depicted by a labeled transition diagram.
Nick: synchronization is an important concept.
Yaron: Is this just a synchronization issue? Or is something more?
Nick: I am not sure if there is something more but I believe that state alignment is quite a fundamental issue. In Dave’s proposal, state transition can happens only at the endpoints. And there are no synchronization points, really.
JJ: can you compose interactions?
Dave: not yet
JJ: can we associate a response with a request?
Dave: yes
Nick: can we capture documents that are exchanged as states and use conditional logic on the content?
Dave: yes, using a binding but binding in not defined yet.
Yaron: it can be defined but not necessarily needed.
Frank: can two choreographies be triggered from the same start state?
Dave: yes
Frank: how do you know, which one you are using?
Dave: using identifiers in the message associated with the message instance
Frank: if there more instances?
Jon: what is the mechanism?
Dave: use payload, header
Frank: is this correlation problem?
Yaron: not exactly
Frank: correlation is bigger a bigger problem: associates a message to a context
Yaron: the question is in a choreography, does one role know what the other role does?
Jon: the difference is that Oracle Corporation proposal tries to also align state
Yaron: I only care about what happens at one role
Frank: what are the preconditions of sending and receiving messages
Yaron: I understand the utility of synchronization, but is this the ONLY thing required?
Nick: What I am saying is that both models, the role-view and the shared-view with synchronization are important to be treated as first class citizens. Not just one or the other.
Frank: Buyer is only concerned for making a decision, why the seller needs to know this in choreography?
Yaron: It is important to show in choreography only if it is important for both roles
Frank: so, you don’t need this precondition but the seller does not need. This cannot be validated at runtime.
Jon: don’t you need precondition to validate invalid message sequences?
Frank: what are the cases we need precondition we need to investigate more. How this works for a third participant?
Nick: in interaction the fromRole-state transition and the toRole-state make transitions. Does this need to be atomic?
Dave: no, because of failures
David says: BurdettML could live without processes (see slides)
Nick asks what can be imported? Can I import WSDL types?
David answers: No only roles, message families (which are a collection of concrete message types)
Yaron suggests that today BurdettML is best serves by pointing at a specific WSDL message as opposed to a Message Family
Yaron: Would like to get rid of pre-conditions/post-condition (probably see Yaron's email about BurdetML from one/two weeks ago)
Various questions seeking clarification about BurdettML. In brief it was all around the notion of two state machines that work harmoniously in some what. This is at the heart of what BurdettML is all about.
David made the point that *this* version has no composition features.
One of the problems with the FSM approach (I think and correct me if I am wrong) is that much of the static analysis that is targeted for V2 of a CDL would not be possible. So one of my concerns is that we lock ourselves out down stream. Given that David has already made it clear what he feels are "the things yet to do" it may be the case that this is a solution that lies somewhere between the two current submissions. This would be consistent with Nick's view.
ACTION: SRT send revised requirements spreadsheet to David
It was agreed that the authors plus other volunteers meet to discuss the possibility of merging the two proposals into and single baseline.
ACTION: Dave will call a meeting, to discuss how to take the two CDL contributions and come up with a baseline document and match it with the revised requirements document.
Someone asked why we didn’t start with WSCI as the base language.
Martin replied that no one had proposed it as a baseline. They are free to put such a proposal top the group if they want.
Dart: WSCI is difficult to use because it is primarily a participant model and uses the global model secondarily.
Tony: Input TF should look at existing specs rather than evaluating these new proposals to us. This meeting should be watershed - complete Reqs / use case even if not perfect, start work on actual spec.
Janet Daly W3C Communications Spokesperson was invited to talk at the meeting.
Janet: The message is that the work from W3C Choreography group and the BPEL group should be complementary.
Yaron: I agree.
Jon: WS-Choreography WG has a long-term schedule. We have a requirements document now. What is the best way to communicate intermediate results?
Janet: your mailing-list, summaries of issues, background papers on issues.
Also, individual companies can do more to promote progress, success.
Steve: It is tricky to get a group of people of this size to focus. One way to make this is understand what is in the horizon. What should we look for the next 6 months?
Janet:
1) The 17-19th November is the next W3C publication moratorium. Publication requests cannot be received after 12th of November 2003. This group should try to meet this date.
2) Philadelphia, XML 2003, December second week.
UN/CEFACT
Tony Fletcher presented an overview of the UN/CEFACT Business Collaboration Framework (BCF):
http://lists.w3.org/Archives/Public/www-archive/2003Sep/0058.html
http://lists.w3.org/Archives/Public/www-archive/2003Sep/0059.html
http://lists.w3.org/Archives/Public/www-archive/2003Sep/0060.html
http://lists.w3.org/Archives/Public/www-archive/2003Sep/0061.html
(Originals at http://webster.disa.org/cefact-groups/tmg/bcf-tour/agenda.html)
Jon: Are there any business applications on this?
Monica: no
Ran out of time so no discussion as to whether we should form a liaison with UN/CEFACT.
ACTION: Chairs to put liaison with UN/CEFACT on next con call agenda.
Steve: Goals
1) Task Forces
a. Objectives
b. Roadmap
c. What is their function?
There should be 2 task forces:
A) Harvesting against requirements and
Inputs (WSCI, BPEL, BPML, BPSS, DAML/S)
The group felt that now we have a clear mission and a good understanding of requirements that this harvesting work will not result in useful input.
Motion to close this task force. Passed.
B) Formalism task force.
Motion to close this task force. Passed.
2) Requirements
a. Roadmap
b. Participation
Requirements editors will meet and take into account the discussion made at the meeting in coming up with a new draft.
Aiming for a publication date on November 3, 2003 for public consumption. Internal drafts will be made available.
3) Choreography Language Contributions
Authors have a agreed to meet and hammer out a baseline.
We would like a baseline language for the next F2F in December
4) F2F December 2003
a. Motion to accept the offer F2F December at Australia. Passed. Results are: 5 yes, 4 no, 1 abstained.
5) Motion to accept the contribution from Oracle. Passed.
6) Will skip next Tuesday’s meeting. Next con call meeting on 30 September 2003 1pm pdt
ACTION: Steve: Will put all the comments on draft requirements above into the requirements spreadsheet and send out.
ACTION: Tony to rephrase his requirements and bring back to group.
ACTION: Editors of the requirements are directed to look at the issues list and filter each issue in a similar way to the filtering method used at the F2F.
ACTION: Steve to facilitate calling an Requirements / Use Case editors meeting.
ACTION: Dave will call a meeting, to discuss how to take the two CDL contributions and come up with a baseline document and match it with the revised requirements document.
ACTION: Requirements editors to consider an EAI use case and think about within and across firewalls.
ACTION: Chairs to put liaison with UN/CEFACT on next con call agenda.