2. Confirm scribe
3. Approve minute
4. Action Item Review
5. Informal reportage on the last face2face
• Technical harvesting track 2
. Harvesting the +ves and –ves from WSCI, BPEL, DAML-S, BPML, BPSS
• Technical harvesting track 3
. Harvesting the +ves and –ves from BurdettML, Event Calculus and the Pi-Calculus
• Issue tracking
6. Tracking items (a section designed to ensure that longer running items and issues raised are properly tracked)
• Mission Statement (progress)
• Requirements (progress)
• General technical issues
7. What is the value of a choreography language over and above WS-BPELabstract processes for users? (Discuss)
8. Threads (on the archive not covered elsewhere in the agenda)
. Choreography protocol
. Liason Statement
9. AOB.
|
Oracle | ||
|
Enigmatec | ||
|
|
| |
|
W3C Staff Contacts |
| |
|
|
| |
|
|
|
Members:
|
BEA Systems | |
|
Cisco Systems Inc | |
|
Commerce One | |
|
Computer Associates | |
|
EDS | |
|
Fujitsu Ltd | |
|
Hitachi, Ltd. | |
|
Hitachi, Ltd. | |
|
Novell | |
|
Oracle Corporation | |
|
SeeBeyond Technology Corporation | |
|
Software AG | |
|
Sun Microsystems, Inc. | |
|
Sun Microsystems, Inc. | |
|
TIBCO Software | |
|
W. W. Grainger, Inc. | |
|
W. W. Grainger, Inc. | |
|
webMethods, Inc. |
Raw IRC log at: http://www.w3.org/2003/06/24-ws-chor-irc
Jon Dart, TIbco, kindly volunteered to scribe for the meeting.
Previous scribes (in order): 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
10th June minutes: http://lists.w3.org/Archives/Member/member-wschor/2003Jun/att-0019/20030610-0.html
SRT: any objections to minutes from last cc?
minutes approved
[note actions need to be updated with new actions from F2F]
ACTION: Carol to look into WSCI summary.
SRT: WSCI Summary from Carol
Carol: have sent slides
ACTION: SRT to capture reqs from minutes.
SRT: action on me to capture requirements .. superceded by agenda item
ACTION: All: alternate formal models other than the pi-calculus. Agenda item for next F2F – proposal from FM Event Calculus)
SRT: alternate formal models .. done
SRT: Frank McCabe gave an intro to event calculus
ACTION: DA will do the wordsmith, summarize and put together revised mission statement. Once again it is not final.
DA: There has been a lot of back and forth. Want to reframe statement made to BPEL group. Suggest add to agenda for next week
DA: Need to incorporate text from statement made to BPEL group into mission statement
ACTION: SRT to extract summaries of harvested specs (wsci, bpel).
SRT: superceded by agenda item from F2F
ACTION: DA will own the privacy discussion thread and summarise the requirements that ensue.
http://lists.w3.org/Archives/Public/public-wschor/2003May/0167.html
DA: is in progress
ACTION: FMC to send in URL for WSA privacy document
Frank: sent URI during meeting
SRT: mark as done, will try to find it
need to check F2F minutes
ACTION: MC to add FMC to F2F agenda for event calculus presentation
SRT: MC, add Frank to agenda .. done
ACTION: SRT to write a straw man proposal on BPEL liaison.
SRT: action on SRT to create strawman for BPEL liaison .. done
SRT: informal report on F2F .. maybe those who were there can give impressions
SRT: There were 3 task forces set off at F2F
SRT: one is to look at req document
SRT: deadline to get out for public review asap
SRT: Then a task force to harvest + and - from existing inputs (BPEL, WSCI, BPSS, DAML-S)
SRT: Then task force #3 is to harvest from David Burdett's submission and at + and - in event calculus and pi calculus
SRT: those of you not currently involved in these task forces, look for leaders of the task forces to get involved
YG: BPSS not mentioned?
YG: (in track 3)
SRT: It is somewhat arbitrary.
SRT: BPSS nearly was in track #3. JJ did give a presentation on BPSS. Because it was already an input to the group, I put it in task force #2
SRT: Harvesting activity should be as thorough as possible. We should not look only slightly at things
SRT: any comments from participants at F2F?
JD: mission statement produced at meeting was a good first cut
YG: was a bit surprised at differences from what was discussed on the list
JD: need to reconcile
NEW ACTION: reconcile mission statements
MC: some items such as machine readable are implicit IMO
MC: seemed obvious at the meeting
YG: statement should tell what we do and what we don't do
YG: F2F version was more open-ended
MC: this was talked about. Somebody said we shouldn't include things we won't do.. the list is endless
DA: there is scope for creative ambiguity. We don't know what will happen in future. We may need room to manouver.
YG: mission statement can be changed
Frank: the most substantive difference between YG and co's version and F2F version is service composition and semantics. I see these as serious issues we need to address.
I agree with FM on this point
Frank: You can do choreography w/o composition or semantics (semantics doesn't mean doing WS semantics, but to relate semantics to services)
Frank: we did have some difficulty capturing that properly
Frank: Need to get hold of issue of WS composition
YG: need to get specific
YG: need to get agreement on terms
Frank: My $0.02: service composition means composing 2 or more services together to have a new service.
Frank: Does that new service require any programming? If it does, IMO it is not really WS composition
Frank: Yaron, you have wanted to exclude executable languages. I also think we don't want to do composition involving programming.
YG: I don't understand what WS composition outside programming code means
SRT: let's try to resolve this. Get next level down explanation of what we mean.
SRT: Need to keep mission statement as 1 para but also have definitions of what we mean, separate from the mission statement
MC: I think we could just work on shoring up the wording .. is good as is
Carol: could use glossary to clarify what we mean
SRT: good idea
Monica: service semantics may not be in there, but there are defns of compositions
Monica: there is >1 defn of composition.
Monica: Can start discussion on it
SRT: should have Jim Hendler in discussion. He certainly does transparent composition
SRT: Any other items?
JD: BPEL liaison?
SRT: I did see Diane's report on OASIS mailing list
Monica: I haven't read her comments.
Monica: They have formed a use case sub-committee. I'm not sure how this works, but it is a good point of discussion on how we might interact.
Monica: Should there be a liaison, we need to have it done formally, and soon
SRT: Diane sent to ws-bpel-liaisions
SRT: Diane said our WG could involve interactions at a higher level, may overlap BPEL process support. Avoiding overlap entirely may not be possible. Could possibly share use cases.
SRT: could identify common requirements, collaborate on presentations, joint meetings
SRT: WS-Chor focuses on WSDL 1.2, WS-BPEL on WSDL 1.1
SRT: working together may involve process issues
SRT: it seems there's no policy for this on either side
SRT: action for BPEL TC is to confirm liaison persons
SRT: We talked at the meeting about the need to cooperate. We set out the area we are in, and asked Diane to clarify what WS-BPEL is doing, in the same way we clarified our goals in the mission statement.
SRT: They are aware of what we're not likely to do - the execution stuff
SRT: We need to feel comfortable with the WS-BPEL group, by having same degree of information about them
Frank: the BPEL working group has spent 0 time considering WS-Choreography.
Frank: Diane said very clearly that their focus is working on current BPEL spec. They will not go beyond it, in any significant way.
Greg: today I asked Diane to take me off the liaision position, for various reasons.
SRT: Know who might replace you?
Greg: no
Martin C: have to go
SRT: apologies for not having F2F minutes yet.. will have out asap
SRT: one other item from F2F: YG asked for this: issue tracking
SRT: Martin gave demo on BugZilla. http://www.w3c.org/Bugs
SRT: This is where issues should be lodged (and bugs)
YG: but how?
YG: should discussions go in BugZilla?
DA: I would propose that conversation go on mailing list, referencing bugs by name or number.
DA: bug entries should contain minimal info needed to identify issue/bug
YG: do I need to add requirements to BugZilla?
SRT: it would be nice. The requirements editors would be happy.
SRT: we may get your requirements in before you do
DA: We need requirements by July 1, for july 8 heartbeat deadline.
JD: need dynamic participation use case
JD: will attempt to dig up or write one
MChapman: on the use of bugzilla, i think discussions should carry on in email.
MChapman: the issue owner is resonsible for summarising and referencing relevent emails in bugzilla
SRT: Ed Peters, DA, and myself are working on requirements
SRT: general technical issues on agenda .. not sure what this is.
SRT: item #7 was raised by at least 2 people: what is it all for? What is the value in doing choreography?
SRT: Came from Tom Carroll and Paul Lipton
PL: We need to codify business and technical benefits
SRT: I know Yaron's use cases discuss the benefits in narrative form
PL: This is more general: it is more like the 1-page executive summary value proposition
SRT: there was a discussion at the beginning of the call, saying people don't really know about WS-Chor and what it is for.
JD: This should fall out of the use cases
DA: IMO we have user scenarios, not use cases. We have higher-level objects called user scenarios, need to be broken down into use cases
PL: need to show how services are built
Frank: focus has been on how services interoperate. One of the focuses of WSA is to show how all the pieces fit together. Need to understand how messages are structured, security, etc.
Frank: we are focusing on interoperability at message sequence level, between services
PL: Will you show people the use cases, people outside the group
JD: We are building a next level of metadata, above WSDL.
YG: Every customer I have who has built a non-trivial workflow winds up drawing a graph. I want to make this easier.
YG: These are detailed message-exchange charts. With a complex exchange, you need s/w and tools to model this.
YG: Need to be able to use this for validation so you can verify that your s/w does what it claims
YG: BPEL takes a process-centric view. This is not how our customers work.
DA: isn't notation out of scope?
YG: Don't need UML, etc. Need the underlying meta-model. Our company has ideas about what UI should look like. Too early for a standard there. But if you go to the underlying concepts, it is just a directed graph. Need a standard for this model, this is the point of exchange.
DA: Agree but your idea about validation indicates that we need to spend time and effort ..
DA: .. developing a formalism to enable us to do that. If that is necessary need to put work into it now. May take us towards Turing completeness.
YG: The only validation I am looking for is wrt ordering of messages
YG: It is what we call a language acceptor
YG: I only want to define the allowable set of messages between participants, as an ordered set, but allowing parallelism. No need for Turning completeness
DA: Another issue is side effect issue, this is what led me to mention Turning completeness. May need to validate there are no side effects.
YG: Don't understand "side effect" in this context
DA: Choreographies could have effects different from individual web services
DA: I don't think we disagree. We agree but not totally on the scope.
SRT: validation was discussed at the F2F. We need to fully understand what we mean by validation - is static or dynamic, and how wide it can be.
SRT: Can't answer this right now
JD: YG, how close is DB's proposal?
YG: I had some issues re licensing.
YG: I am very concerned about reading spec when IP not clear
SRT: can someone summarize the situation?
LG: What we agreed to at the F2F was that all participants would abide by W3C's IP requirements.
LG: Anything brought into group, unless identified as someone's IP, is available for the group to use
SRT: An email was sent, Yves felt this was acceptable
YG: Are they asking for an exception or is it RF, under the policy?
YG: As long as there is no request for exceptions, then we're done
SRT: My understanding is that is now the case. The words being used were, if the group decides to accept it, then IP rights would not be asserted. Then we understood that if we agreed to consider it, then we "accepted" it and it was RF
NEW ACTION: action on DB to come back with definitive email re: IP position on burdettML
YG: As soon as that happens, I will be happy to review it
Frank: DB was saying he wanted to submit it to the group. There was an issue with formal submission taking a lot of effort
YG: It is not being submitted as a note
YG: Yves, is there a formal process for submission to the group?
Yves: If the spec submitted has no IP claims, then the WG can just use it, no problem.
Yves: We need to verify the intent behind it.
SRT: continue with value proposition discussion?
DA: wanted to talk about validation?
SRT: I wanted to go back to YG's comment about his customers. If all this stuff is done, and it does what you want, then presumably BEA as a vendor will be able to make better tools
YG: That is the goal
SRT: One of these tools would be a validator..
YG: Yes. Two tools at least: one is for design. People tend to start with the circles and lines, then they want to be able to import that into their programming tools.
YG: Want to be able to say "I am implementing this role within the defintion" and have tool fill in framework
YG: May want to put in front of their system a validator, so they can see if message sequence follows chor.
SRT: was discussed at F2F
JD: There are 2 possible ways to verify choreography message sequence. One is to have context travel with message - which role it comes from, what state it is in or expects to be in. Another method was to have a validating wrapper, as YG suggested.
SRT: Ed, does this interest WebMethods?
Ed: we think this will be ultimately be useful. Something that focuses on validation would be especially useful.
SRT: Carol?
Carol: +1
SRT: To summarize, one of the benefits at the IT level is that I can deliver applications faster and more accurately. It has a continuing benefit in increasing the real-time robustness of communication, through validation.
YG: it is faster and easier to design & get agreement with partners
DA: <rant> There is a distinction between making languages validatable, and having a means to perform the validation. I want to do the former, not develop a validation mechanism</rant>
DA: Getting into the validation business is a big deal
arkin_:+1 as well
YG: I want this group to build a structure I can build validation around
DA: There is a process in pi-calculus for validation
DA: bisimulation is one
SRT: There are other concepts
YG: bisimulation is undecidable, in the general case
SRT: it may be weak/open bisimulation, something like that
DA: Would this allow us to do what YG suggested, re validation?
SRT: it would do it statically
SRT: I am not sure about the computational complexity
YG: it is a fundamentally different model. Bisimulation matches executable codes - do they do the same thing? Not practical in real world. I am talking about observation of real-time behavior.
SRT: A bisimulation process is like an experiment. You observe what the sequences of messages are. But that assumes you can press any button, in any order, and do it statically.
SRT: Yes you can do this statically, but it is impossible in the general case.
SRT: If the model for execution is the same as that for choreography, can do this, but we as a group may not adopt that restriction
SRT: What YG suggests is done at runtime. Probably a good 80/20 solution.
DA: I don't want to see us coming up with a post-validation info set or something like that. Want to be constrained about what kind of validation we are doing.
SRT: We must be very sure about what kind of validation we want to do. If want to do something different from Yaron's suggestion, may need to get expert advice.
Frank: bisimulation is undecidable, it's obvious. Yaron's tool is a debugging tool. Very useful for that.
Frank: Another business case is documentation. When you do construct business systems, you need to document them.
YG: That's what I said, design comes first, debugging later.
YG: add to agenda, relation to BPSS
Frank: how will task forces operate?
SRT: add to agenda for next week
NEW ACTION: Task force operation on next weeks agenda
DA: reminder from editor: use cases/requirements by July 1
NEW ACTION: reconcile mission statements
NEW ACTION: action on DB to come back with definitive email re: IP position on burdettML
NEW ACTION: Task force operation on next weeks agenda