1. Role Call
2. Confirm scribe
3. Approve minutes
Minutes 29th July 2003
4.Action Item Review
Organisational
ACTION : Chairs, Oversee the organisation of the task forces. ONGOING
ACTION : Martin to track back through past minutes for issues and put into Bugzilla. ONGOING
ACTION* : SRT to contact Alastair Barros with a vew to DTSC hosting the W3C Choreography F2F meeting in Melbourne Australia in December 2003. DONE – they will host.
ACTION* : Chairs (SRT/Chapman) to put on the agenda for 2nd September the following item:
Burdett ML, the extent to which it meets the requirements and the extent to which the requirements are reasonable.
Usecases/requirements
ACTION : Alistair (Barros) will develop a use case / scenario for this broadcast use case. ONGOING
ACTION : David Burdett to provide a design collaboration use case PENDING
ACTION : Martin to propose text for call-back use case. ONGOING
BurdettML
ACTION : David Burdett action on verifying and reporting on the legal aspects of Burdett ML. ONGOING
ACTION: David Burdett reported that he should have a resolution by next week - cover next week. ONGOING
LATEST: Burdett - IPR copies provided to chairs; Burdett will post to the mailing list.
ACTION* : DB to produce a commentary on how Burdett ML meets (or not) the current requirements.
LATEST: Ongoing to determine if this meets our requirements and identify gaps. Analysis paper will be finished by David Burdett prior to the September meeting and he will try to post beforehand.
Issues
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.
ACTION* : SRT to put semantics on to the issues list.
5. Standing tracking items (a section designed to ensure that longer running items are properly tracked)
§ Requirements – next steps (progress/review)
§ Mission Statement
§ CSF Analysis
§ Use cases
§ Requirements listing
§ Issue tracking (progress/review)
§ Major issues to report
§ Task forces – next steps (progress/review)
§ Task list
§ Membership
6. Face2Face in Seattle (agenda items)
7. Burdett ML, the extent to which it meets the requirements and the extent to which the requirements are reasonable.
8. Threads (on the archive not covered elsewhere in the agenda
· Correlation requirements
First in thread, latest
· Simultaneous execution
First in thread, latest
· Off topic (catch all)
First in thread, latest
9. AOB.
|
Chairs |
| |
|
Enigmatec | ||
|
Oracle | ||
|
W3C Staff Contacts
|
| |
|
|
| |
|
|
|
Attendees:
|
BEA Systems | |
|
Choreology Ltd | |
|
Cisco Systems Inc | |
|
Commerce One | |
|
Fujitsu Ltd | |
|
Hitachi, Ltd. | |
|
Nortel Networks | |
|
Novell | |
|
Oracle Corporation | |
|
SAP AG | |
|
SeeBeyond Technology Corporation | |
|
Software AG | |
|
Sun Microsystems, Inc. | |
|
TIBCO Software | |
|
W. W. Grainger, Inc. |
Raw IRC log at: http://www.w3.org/2003/09/02-ws-chor-irc
John Dart (Tibco), kindly volunteered to scribe for the meeting.
The following is a list of recent scribes (in order): Monica Martin, Tony, Fletcher, Jim Hendler, Kevin Liu, Tony Fletcher, Jon Dart, David Burdett, Ed Peters, Greg Ritzinger, Monica Martin, Len Greski, Jean-Jacques Dubray, Monica Martin, Mayilraj Krishnan, Francis McCabe, Michael Champion, Abbie Barbir, David Burdett, Jon Dart, Carol McDonald, Yaron Goland, Leonard Greski, Ed Peters, Greg Ritzinger, Daniel Austin, Peter Furniss, Jim Hendler
Minutes from 29th July 2003.
SRT: SDL should be WSDL
SRT: last minutes had unattributed comment
SRT: does anyone claim comment in minutes?
MC: can leave as is
SRT: minutes approved
20:20:05 [scribe]
Organisational
ACTION : Chairs, Oversee the organisation of the task forces.
SRT: action to oversee task forces - any update from task forces? no, action is ongoing
ACTION : Martin to track back through past minutes for issues and put into Bugzilla.
SRT: MC - bugzilla status
MC: have gone thru previous minutes and put in links to where issues raised
MC: need to do duplicate elimination
SRT: updated up to 7/22>
MC: yes, will do 7/29 too. [Subsequently done]
DONE
ACTION : SRT to contact Alastair Barros with a vew to DTSC hosting the W3C Choreography F2F meeting in Brisbane, Australia in December 2003.
SRT: confirm hosting of F2F in Australia by DSTC - confirmed.
SRT: MC, any further update?
SRT: will come back to it
DONE. They have offered to host a meeting week of 15th December.
ACTION : Chairs (SRT/Chapman) to put on the agenda for 2nd September the following item:
Burdett ML, the extent to which it meets the requirements and the extent to which the requirements are reasonable.
DONE on the agenda for this meeting.
DB: not really prepared for this yet so not discussed at theis meeting. Will save for the F2F.
Usecases/requirements
ACTION : Alistair (Barros) will develop a use case / scenario for this broadcast use case.
SRT: Alastair's use case action - mark as done
SRT: On agenda.
SRT: Use case candidate for req doc
DONE see http://lists.w3.org/Archives/Public/public-ws-chor/2003Aug/att-0016/mpi-use-case-ab.html.
ACTION : David Burdett to provide a design collaboration use case
Ongoing
ACTION : Martin to propose text for call-back use case.
Ongoing
BurdettML
ACTION : David Burdett action on verifying and reporting on the legal aspects of Burdett ML.
SRT: Burdett ML - legal aspects
20:24:45 [scribe]
DB: done completely
20:24:54 [scribe]
SRT: mark as done
20:25:13 [scribe]
DONE
ACTION : DB to produce a commentary on how Burdett ML meets (or not) the current requirements.
Ongoing. Was put on this agenda, will now be on F2F agenda.
Issues
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.
SRT: issues - was going to mail TAG. Is now a semantics web interest group. Have been in contact w. Eric Miller about having a dialog. Action is mis-worded: issue will not be lodged with interest group, but will start dialog.
DA: my note to you (and to group) was not intended to be private.
SRT: I still have action to start dialog
SRT: some standing items
DA: point as that semantics is too important to leave to the semantics IG
SRT:
thanks, noted
Hugo: SWS IG not formed yet, proposal has been made to form it
ACTION : SRT to put semantics on to the issues list.
DONE
SRT: F2F in Seattle. 2.5 days, what needs to be on agenda?
DA: reserve time to go over requirements
JD: deeper BurdettML discussion
DB: what do you want to cover
DB: how do we structure it
JD: want requirements gap/fit (see action point above)
TF: report from each of task forces
TF: start to draft out specification
SRT: one goal of meeting would be to draft skeleton for spec
YG: come to solid agreement on requirements - this is a pre-requisite for progress in other areas
DA: critical success factors
DA: re requirements: YG wanted a walk-through, good idea. But we may not come to consensus, will continue to iterate. But getting 1st pass agreement would be good
YG: Agree, but we need at least rough consensus or we can't make progress. The requirements and specification will iterate on each other, we can expect the requirements to continue to change until we are at least 1/2 way finished with the spec.
DA: agree
MM: reports from sub-groups?
SRT: yes
SRT: MM, Mike and Frank on tap for this
DA: formalism issue - still not resolved
SRT: is one of the task forces
DA: I realize, would like to see motion on this
SRT: enough items for F2F?
MC: yes, will send out draft agenda
ACTION: MC to send draft F2F agenda
MC: members should fill out registration page
JD: deadline is Monday the 8th
MC: correct
SRT: re requirements, any input from editor?
DA: still some places where there is overlap. Some of the language is imperfect. Please overlook minor details & concentrate on main issues. Try to come to agreement on scope.
SRT: issue tracking: anything from Greg?
Greg: email to get volunteers - no responses yet
SRT: should raise at F2F
DA: might help to get s who is responsible for original use case or issue to step forward and deal with issue. Better than just asking for volunteers.
Greg: maybe some issues have no one interested in them
DA: we don't have choices, if issues come in, we are required by W3C to address them
DA: We could reject it as not an issue, or say is resolved but can't ignore
Greg: need to identify who raised some issues
DA: need this in the database
MC: we haven't had this for formal issues from external parties
MC: if we do have such issues come in will need to track their origin
MC: was going to create a separate category for external items
DA: don't want to lose the email that sources external issues
Tony: it is odd to have issues at all at this stage
Tony: resolving issue doesn't have visible impact, unless it changes text in the req doc
Tony: once we have a spec, then there is more point in resolving issues - will affect document.
MC: disagree. Many of our discussions have resulted in issues being logged - is valuable, documents discussion
MC: Not a waste of time
DA: agree
SRT: sense of urgency is not there
SRT: will increase when we have deliverables assoc. with issues
MC: urgency here is: need to reflect issues back into requirements
MC: we owe it to ourselves to review all issues and reflect on whether or not they are requirements
SRT: do this at F2F.
SRT: need concrete list of issues.
MC: are in Bugzilla
SRT: But we need to do a collective look at them.
MC: look at WS Chroegraphy product underhttp://www.w3c.org/bugs
SRT: need to relate them to requirements and use cases
DA: is this an action item to the group?
ACTION: group will review Bugzilla issues list
SRT: task forces, next steps
SRT: any updates?
Frank: I was waiting for JH to get a little more free time
Frank: I was also off in August
MM: not much progress. Did have an assessment matrix done in 3rd week of July
MM: would help to have updated spreadsheet
DA: MC has updated copy
MM: I only had one from July 20 or so
MM: req doc came out end of July
ACTION: SRT to send most recent requirements spreadsheet to the list
MC: best to send to list unless there is overload
SRT: David, BurdettML?
DB: I was busy but will find time by Fri before F2F to review requirements and compare with BurdettML
DB: know composition is missing
DB: have some ideas on how to do this
More at F2F
SRT: re threads, pickup out 3: correlation requirements, simultaneous execution and "off topic"
JD: need to capture discussion in requirements
SRT: Frank had the last email about it, 8/27
Frank: can't recapture context
SRT: was a mail listing requirements - from DB?
DB: yes, I did write that.
DB: consensus was that we needed 2 specs or 1 spec in two parts: one is abstract, and is separate from the 2nd, which is a binding to a concreate implementation
DB: could agree that all messages would be of a particular form, and use reliability, security, etc. Or could have a 2nd level of binding, where you bind to actual service instances
DB: if you do this you can reuse choreographies across multiple vertical industries.
MC: relation to correlation topic?
DB: part of concrete defn is that when you send a message, you need to know which choreography defn and which message exchange within the choreography defn is the message part of - also which choreography instance it is assoc. with
DB: could put in document itself or use other mechanisms
DA: wanted to make suggestion related to Tony's discussion re abstract description vs. binding
DA: charter prevents us from making specific bindings to programming languages
DA: so we need to be a bit careful
DB: agree
DB: binding is not to a programming language
DA: we should not make decisions about dividing up document editorially.
DA: we should not decide now how to put document together - should it be one document or two
DA: we may have four documents
DB: agree
Frank: comment I made in email was related to DB's comments plus another issue (possible CSF): there may be Web services w/o knowledge of choreography definition language
Frank: we want to be able to have a choreography using such Web services
Frank: IMO this is a CSF
Frank: this will put strong limitations on what we can assume is in the message
DB: Frank, I agree. If you have a WS that causes another message to come back, or an error, then service using it need not be aware of choreography.
DB: But if you need multiple messages in a prescribed sequence, then messages are following a choreography and requirements may be different.
DB: need to conform to WSDL or WSDL + extensions
DB: these could include security, etc. Also choreography
Frank: we are likely in agreement.
Frank: don't like having a distinction in the chor. language between services that are aware and services that are not
Frank: reason you have chor in the 1st place is to define how services interact so need some way to identify messages
JD: do need correlation but work is going on in other groups to address this.
JD: We can't specify a mechanism now
DB: we can't go on faith that someone will come up with a mechanism. Need to be more pro-active
DB: need to do liaision or start a separate group. Needs more discussion.
DB: we need to pick a way of doing it
TF: agree.
Tony: when you are in the middle of a choreography, when you send a message you need a way of identify which instance it is for.
Tony: what instances do you need to identify?
Tony: If you envision you are directly implementing the choreography, then you may think it is the instance of the choreography you need to identify
Tony: But another possibility is you are using the choreography language to specify more abstract view of interaction
Tony: then each party implements their view of the interaction. So actual implementation is something like BPEL and you would use whatever instance recognition mechanism is built into the implementation
Tony: so this could be resolved when we agree how we will use the language
MC: requirement is to be able to identify/match an actual message against a defined message in a choreography.
MC: Then there is also the issue of integrating our language with BPEL
YG: basic principles: 1st is that WS-Chor does not have the ability in many interesting and compelling circumstances to specify what correlation mechanisms are used
YG: one is where there are existing mechanisms in place - we can't mandate a different one
YG: we need to deal with arbitrary correlation mechanisms
YG: Then question is, would it be productive to come up with a standard correlation mechanism?
YG: There are already a number of contenders for WS correlation
YG: BPEL does not have a correlation protocol, instead it provides a completely generic XPATH driven mechanism that can support any SOAP based correlation mechanism.
YG: Our charter doesn't include coming up with such a mechanism.
YG: Maybe we can sidestep this and adhere to basic principle that we need to be independent of correlation mechanism
SRT: +1
DB: agree in principle, but interoperability requires a correlation solution.
DA: "minimally constrained correlation solution"
YG: what is "this" you to solve?
DB: there are multiple specs, e.g. for reliability
YG: There exist today multiple correlation protocols, they are being deployed and will continue to be deployed for the next few years. Even if we did come up with the single universal correlation protocol we cannot ignore all the deployed protocols. WS-Chor won't be very useful if it only works with our single chosen solution. Existing solutions are being deployed. To be relevant we need to support them."
DA: don't agree. Divergence in this area causes pain points for people using this technology.
DA: Hope convergence is sooner.
DA: Standards bodies are supposed to look at multiple solutions and pick one or create an amalgam. We should not just treat every solution as equally good
DA: we should give users something to rely on.
DB: agree we need solution that could work with multiple solutions. But agree with DA we need to address this problem.
DB: should solicit authors of various specs to facilitate convergence
DB: we should not tie language to one way of doing correlation
YG: it is not within the scope of the group to decide on the Web service architecture
YG: if other areas are in disarray, we should not solve it ourselves, we should go to WSA and put issue before them and if we believe we cannot make forward progress until this issue is resolved, which I don't believe, then we should suspend work until they give us a consistent architecture. But should not duplicate work.
YG: Either we say we can handle the various proposals -- which nobody really likes, and situation is screwed up -- but we should not turn ourselves into WSA
YG: we should refer back to WSA
MChamp: I want to hear the other side, YG makes sense, but what is the counter-argument?
MChamp: Wearing my WSA hat, I wonder if there is a real WSA issue here.
DB: YG, I don't think this is an architectural issue. Choreography is not really dependent on reliable messaging, etc. but does require correlation.
DB: So how do we define this? Maybe we do go to WSA and say, there is this dependency and need a solution.
DB: Maybe we ask for a single preferred solution.
DB: But correlation is a prerequisite for choreography IMO
MC: I sort of agree with YG, just as WSDL allows bindings. etc. we should be able to select varieties of reliability, etc. But DB is saying some means of correlation is requirement - but could be a different one for different choreographies.
DB: Yes, this could be part of binding.
DB: But can't just leave it totally open. Want to have 1 we can recommend.
SRT: YG, is this far off from where you are?
YG: Does anyone disagree with basic principle of supporting multiple different kinds of correlation?
YG: Just for an example, one mechanism is SOAP headers, another is more REST-like and uses transport-level mechanisms
YG: these are very different philosophies for how to do correlations. And they will not converge.
YG: Does anyone disagree we need to support multiple types, even if we recommend one?
MC: these are radically different .. one is client-side correlation, one is server-side. Need to pick one or the other
DB: Yes you can if you abstract it
YG: Yes, correlation could be treated much like reliable messaging - a lower-level construct
SRT: may continue next week
DB: is this appropriate to take to WSA?
MChamp: maybe
MChamp: if solution is abstract binding layer, maybe this should be in WSA document.
MChamp: Or if solution is W3C needs to charter a group, that's another course of action.
MChamp: Either way, it is within WSA's charter to think about it.
MC: next week need decision about December F2F. Australia has been offered, so unless there are other offers….
ACTION: Discuss F2F in Dec at next meeting
ACTION: MC to send draft F2F agenda [1] :recorded in http://www.w3.org/2003/09/02-ws-chor-irc#T20-35-23
ACTION: Group will review Bugzilla issues list [2]: recorded in http://www.w3.org/2003/09/02-ws-chor-irc#T20-46-35
ACTION: SRT to send most recent requirements spreadsheet to the list [3]: recorded in http://www.w3.org/2003/09/02-ws-chor-irc#T20-49-50
ACTION: Discuss F2F in Dec next meeting [4]: (don’t know why rrsagent left out the recorded link!)