|
Chairs: |
|
|
Oracle Corporation | |
|
Enigmatec Corporation | |
|
|
|
|
W3C Staff Contacts |
|
|
| |
|
|
|
Arjuna Technologies Ltd | |
|
BEA Systems | |
|
Choreology Ltd | |
|
Cisco Systems Inc | |
|
Commerce One | |
|
Computer Associates | |
|
Enigmatec Corporation | |
|
Fujitsu Ltd | |
|
Intalio Inc. | |
|
IONA | |
|
National Computerization Agency | |
|
Novell | |
|
Oracle Corporation | |
|
Oracle Corporation | |
|
SAP AG | |
|
SAP AG | |
|
SeeBeyond Technology Corporation | |
|
Software AG | |
|
Sonic Software | |
|
Sun Microsystems, Inc. | |
|
TIBCO Software | |
|
Uniform Code Council | |
|
University of Maryland (Mind Lab) | |
|
W. W. Grainger, Inc. | |
|
webMethods, Inc. |
Abbie Barbir, David Burdett,John Dart, Carol MacDonald, Yaron Goland, Daniel Austin, Jim Hendler, Peter Furniss, EdPeters, Greg Ritzinger, Leonard Greski
MikeChampion confirmed as scribe
No issues raised.
ACTION: MartinChapman will fix minor typos.
ACTION: SRT will monitor use cases -- He spent 5 hours going through emails andsummarized to list.
ACTION: ALL,feedback on usecase summary to SRT.
Daniel Austin: expresses gratitude for use case summarylist.
ACTION: Someonesend SRT the URL to the tidy program so that HTML can be readable on allbrowsers DONE (see below)
Yves Lafon: tidy: http://tidy.sourceforge.net/
ACTION: Hugowill create editors mailing lists by the end of the week (note that means forthis meeting)
DONE
ACTION: F2Fplanning.
IN PROGRESS
ACTION: Harvestingof use cases by Steve
IN PROGRESS
ACTION: Chairsasked to compose list of tasks.
Struck from actions dueto lack of context
ACTION: Everyoneshould review requirements doc and provide feedback to editors. Editorsconsider response satisfactory.
IN PROGRESS
ACTION: Everyoneshould read CSF part of WSA spec. Daniel sent list of CSF references.
IN PROGRESS
Toprovide more directed reading Daniel suggested that WSA Req doc is the highest priority; other stuff is backgroundreading.
SRT: What can we do inparallel with requirements doc?
JohnD: There has been good progress on requirements, glossary, etc., but there is still uncertainty about how
this work will relate to BPEL, and we should try to address that..
MikeC +1 to thatcomment
Yaron: Isn't that a bigbackwards? Shouldn't we figure out what we think we want to do and then figureout if that requires us to mess with BPEL?
MartinC: Poll group on whether we want tocompete with BPEL or not.
JeffM: The only thing we can do isstate our intent. We can't control what other group does ... can just say thatwith good faith overlaps can be handled via liason
DanielA: Need to figure out division oflabor before we can progress, askd for formal W3C liason
DavidB: OASIS charter suggests that theymay include external side as well
Yaron: Would be concerned with"we shall not compete" policy. That hands over control toothers. We should put out whatwe're trying to accomplish, then investigate relationship to other activitiesand try to minimize redundancy.
SAWhite: The WSBPEL charter says it willspecify "Bilateral Web service based relationships between process rolesSAP rep:
Ivana: Had same discussioninternally, thinks that a roadmap of overall area is needed, distinguish whatthis group wants to achieve. Global model, external behavior, internal behavior. Try to assign
Yaron: The goal for BPEL is to takethe current spec, clean it up and shove it out. BPEL is committed to being RF
MartinC: Clarifies that he is asking whetheranyone wants to not worry about OASIS. Possibly take a straw poll at end ofdiscussion.
JeffM: We're negotiating withsomeone who hasn't met yet! Doesn't see value in discussing meta-issues at thispoint; we should make positive statement as to what we are going to do, andidentify who we need to interact with, then liason with them.
JohnD: Agrees with Jeff. Can acceptresolution that we're not ready to attack this. But uncertainty is bad for industry and consumers, but maybe closure is not possible. Someof our requirements point to areas BPEL does not address.
AsafA: Would like to see lessoverlap between specifications
MartinC: Ivana said there are three areasglobal, external and internal and that we need to decide which ones to do
Yaron: I wish someone wouldexplain to me what the difference is between external and internal.
ISSUE: What is external andwhat is internal behaviour as it relates to the choreographing of web services?
Monica: Agrees with previous speakers.Being afraid is not the right tack. We need to be forward looking and flexible.
Yaron: The charter for BPEL isvery restrictive and that is intentional. The goal is to get the BPEL speccleaned up and released ASAP.
MartinC: Me to, but i was just recordingwhat Ivana said
DanielA: Yaron: the BPEL spec definesinternal, external, I think
Yaron: It does? I don'tremember putting that in there. :)
SRT: So theconsensus is that we don't want to be driven by BPEL. Since we've invitedchairs of WSBPEL to our next F2F, we should defer this discussion until thenand seek clarification from them at that point. At the same time we shouldconcentrate on understanding our own boundaries.
MikeC: Disagrees, personally.BPEL is a reality because they have a concrete spec on the table and we areonly discussing requirements
KevinL: Bpel defines a core processdefinition language, then defines extensions for exectuable(internal) processand abstract(external) process
Yaron: External are abstractprocesses? That doesn't seem consistent with what people have called external.
AsafA: Abstract process is oneway to fulfill description requirement of external
ACTION: Suggest that chairs/wg sketch outroadmap. We should look at globalmodel, interaction between systems. We should state this as minimum requirementon us.
KevinL: At least that's close: bpelabstract process deal with "business protocol"
JohnDart: We've had that discussion ...
SRT: This agendaitem is about focus not about other standards initiatives.
KevinL: I agree that a overallroadmap or you can call it a big picture of the choreography area is a goodstarting point
Several: Let's just get on with what we weredoing in the first place.
DanielA: Take "roadmap" moreseriously -- global model, big picture, lay of land with respec ttochoreography.
MartinC: How can we do that until we knowour requirements?
MikeC: (speaking forhimself) BPEL is a reality becausethey have a concrete spec on the table and we are only discussing requirements
MartinC: It all comes down to use cases andrequirements.
FrankM: The usecases and requirementsthus far are pretty random.
AsafA: Agrees that they arerandom in the sense that we do not cover all use cases but only selective ones
FrankM: Betweenrock and hard place. Coming up with random set of use cases is not conducive togood focus. Need idea of whatwe're trying to do. We are in anuncomfortable position ... ebXML, BPEL ... it's hard to give an elevator speechon what WS-CHOR does that others don't, because we're squeezed form alldirections.
MartinC: WeÕre not being squeezed by ebXML.
FrankM: At infrastructure level, it is hardto differentiate from BPEL
DavidB: ebXML is doing lots of differentthings. combination of many of the WS-* specs BPSS overlaps the most with us
Yaron: I take a lot ofinspiration from BPSS
PaulL: One of the big issues vis avis BPEL is time to market, it's on second iteration. Given that, is itreasonable and practical to start over, or should we live with what we have?There is a clear market reality here. BPEL will move quickly.
MartinC: Are you suggesting closing the WG?
PaulL: No, IÕm more interested inexploring other concrete inputs to group to address time to market issue byexploiting previous contributions.
SRT: Charter has alist of inputs ... WSCI is one, but BPSS and DAML-S also.
PaulL: Simplicity has its merits,let's not munge together lots of inputs.
Steve:Seems sensible that we go harvest from inputs mentioned in charter.
ACTION: (clarifying)SRT will harvest use cases, URIs, and publish them
ACTION: Collectlist of technologies we should harvest from (Open)
PaulL: summarizes approaches todealing with inputs -- abstract, increment, or subset. Group needs to consider time to marketissue explicitly.
GregR: Time to market, a CSF?
JohnD: Inputs need to be sorted bysome criterion, classify them as in scope or not. Need to define scoping criteria, and which we might defer toother specs. We can go forward now, but will have to winowlater.
(http://www.ceruleanstudios.com)"at 09:55PM (trillian for messaging)
Frank: Goals, CSF analysis will helpwith these things. This is auseful discipline, however we describe "success"
DavidB: Recapitulates ... a reusablechoreography is independent of the details of implementations.
DavidB: Actual format of what is in orderdoesn't affect sequence of messagess exchanged, so choreographies can bestandardized independently of message formats.
DavidB: Illustrated by "smallmanufacturer in Korea interacting with UPS" scenario.
Yaron: Concerned about somewhatunrealistic suggestions about interaction with EDI and ebXML ... thinks we aretalking only about WSDL-based "web services". Let's not become the "universalchoreography working group" This may be paranoia :-)
Monica: To chairs: Can we ask forprof etiquette please?
DavidB: What we do must scale, and mustnot be too tightly coupled to anyparticular technology.
MartinC: Reuse is good, abstraction is fine,but ultimately parties must agree on wire format. Goal of this WG is about specific choreographies, notabstractions.
MartinC: We could accomplish what Davidwants and stay grounded in WSDL.
DavidB: Agrees
Yaron: We need to talk to WSDL groupabout various limitations, but let's not worry too much about ebXML or RosettaNet.
MartinB: Key here is WSDL -- what featuresare not in WSDL for doing what we need for choreography?
JohnD: [interjects] WSDL might beused for "exotic" message formats.
DavidB: Shares Yaron's concern, butreiterates need for flexibility. We have to limit scope.
DanielA: While it's true that there arethousands of message types, they can be broken down into primitives, and thatÕswhere we should focus.
DavidB: There are not all that manyabstract choreographies.
Martin: Let's make sure this is captured inrequirements doc!
ACTION: SRTwill capture requirements from this discussion
DanielA: Editor notes this
JohnD: Side discussion summaryof WSDL vs WSDL:
http://lists.w3.org/Archives/Public/public-ws-chor/2003Apr/0002.html
DanielA: 6-8 Òprimitive elements" fromwhich most choroegraphies could be built. That should be our focus, not what ebXML did.
Daniel: Let's look for this in use cases.
TonyF: Assuming that we get to goalof having a language specifying choreographies, it should be possible to namethem so they can be stored in a registry/repository and located by name. Thiswould allow re-use rather thanreinvention. Do we need to thinkabout this now?
DavidB: Whatever we do will be in XML, witha URI, so it could be stored in a regular web server.
MikeC: Need to think about queryingin requirements stage. May affect structure of language
DavidB: Take leaf out of UDDI book andthink about how choreographies are categorized.
DavidB: Families of choroegraphies may beuseful concept.
JohnD: Query was an area GregMeredith (Microsoft) borught up, but was puzzled -- don't see use case. Most scenarios involve [early bound]choreographies. If it is a usecase, has it really been implemented, and what requirements are there?
SRT: Financialservices company may have multiple execution venues; not done with APIconsolidator. Consolidatingcompanies take a cut, but add little value. Big trading guy wants to place prices at venues based onchooreog aspects, e.g. when can price be changed?
Mayneed to query for choreography attributes to find partner.
MikeC: Hmm, sounds like theUDDI / "late binding" controversy in a nutshell
ChairNote: MikeC couldyou elaborate on the comment above, perhaps a URI?
DavidB: Use Case -- businesses agree to dobusiness and on terms, but want to automate setting up of technology. "What choreographies do yousupport" needed to find one that both support.
DavidB: If you can't query for this, itwon't scale.
DanielA: MChampion is right
ACTION: SRTlet's capture these use cases in our documents
ACTION: DavidBshould send these use cases in to the list
KevinL: Name of choreog definition may notbe the same as location. WSDL may be identified by namespace, but stored indifferent locations.
TonyF: Agrees. Let's not confusename and storage address.
JimH: "harangue"about 'Web" -- URIs are the basis of the Web, and we get a lot of technologyfor free. Semantic Web is organized around URIs.Right thing to do is postpone naming issue, then leverage Web technology.
Monica: Sent glossary
ACTION: ALLshould review glossary and get back to Monica with comments.
NOTE: Monicaneed to consider glossary with respect to our requireements.
ACTION: Hugowill create editors mailing lists by the end of the week (note that means forthis meeting)
DONE
ACTION: F2Fplanning.
IN PROGRESS
ACTION: Harvestingof use cases by Steve
IN PROGRESS
ACTION: Chairsasked to compose list of tasks.
Struck from actions dueto lack of context
ACTION: Everyoneshould review requirements doc and provide feedback to editors. Editorsconsider response satisfactory.
IN PROGRESS
ACTION: Everyoneshould read CSF part of WSA spec. Daniel sent list of CSF references.
IN PROGRESS
ACTION: (clarifying)SRT will harvest use cases, URIs, and publish them Ð NO PROGRESS
ACTION: SRT will continue to monitor use cases -- He spent 5 hours goingthrough emails and summarized to list.
ACTION: ALL,feedback on usecase summary to SRT.
ACTION: Someonesend SRT the URL to the tidy program so that HTML can be readable on allbrowsers - DONE
ACTION: Collectlist of technologies we should harvest from (Open)
ACTION: SRTwill capture requirements from this discussion
ACTION: SRTlet's capture these use cases in our documents
ACTION: DavidBshould send these use cases in to the list