Dial in information (members only): http://www.w3.org/2002/ws/chor/admin#meetings
1. Role Call
2. Confirm scribe
The following is a list of recent scribes (in order): Carol MacDonald, Yaron Goland, Daniel Austin, Jim Hendler, Peter Furniss, Ed Peters, Greg Ritzinger, Leonard Greski
3. Additions to the agenda
a. MC: Harvesting activity
b. Needs for RosettaNet – covered by item 7.
c. F2F meeting
1. WW Grainger will host the next F2F. Dates 25th – 27th June Wed/Thr/Fri
4. Approve minutes
5. Action Item Review
1. ACTION: ALL actions required re-submit use cases with business context
2. ACTION: HH/YL Check connection of mailing (public-ws-chor-comments) lists to bugzilla – no (bring up as agenda item)
3. ACTION: Hugo to ask for XML Spy licences - done
4. ACTION: Yves/Hugo setup an editors ML - to be checked
5. ACTION: DC to send details to private list – in progress
6. ACTION: MM to post glossary document on public list for review - done
7. ACTION: HH will take a look at Monica’s glossary document – done (track)
8. ACTION: CM will check with Sun about F2F - open
9. ACTION DC can check with sonic for F2F - open
6. Discussion on submitted Use Cases (led by authors)
a. Please email the chairs to indicate your willingness to lead a use case discussion prior to the call. (David Burdett)
7. The needs of vertical industry groups (RosettaNet etc) – issue item relating to harvesting
8. Classification of general requirements
9. Reusable choreographies and data formats
AOB.
Summary of Actions
Chairs: |
| |
Oracle | ||
Enigmatec | ||
|
| |
W3C Staff Contacts |
| |
|
| |
|
|
Members:
Apple | |
Choreology Ltd | |
Cisco Systems Inc | |
Commerce One | |
Computer Associates | |
Fujitsu Ltd | |
Hewlett-Packard | |
Hitachi, Ltd. | |
Intalio Inc. | |
Intalio Inc. | |
IONA | |
IONA | |
National Computerization Agency | |
Nortel Networks | |
Novell | |
Novell | |
Oracle Corporation | |
SAP AG | |
SeeBeyond Technology Corporation | |
Sonic Software | |
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/04/08-ws-chor-irc
John Dart, Tibco, kindly volunteered to scribe for the meeting.
SRT: one volunteer to lead a use case, David, based on multi-party case
SRT: stick URL in IRC http://lists.w3.org/Archives/Public/public-ws-chor/2003Mar/0216.html
SRT: RosettaNet is on the list
MC: Want to talk about harvesting of existing choreography like languages
DA: I wanted to talk about the same things as Martin, in terms of harvesting
DA: I wanted to talk about the F2F
Draft minutes at http://lists.w3.org/Archives/Public/public-ws-chor/2003Apr/att-0093/Minutes_1Apr03.htm
SRT: Any issues with minutes?
Some names are missing from the Role call.
SRT: Can anyone not on attendee list send email?
Mike: was 10 minutes late, not on line
DC: can please use name "Sonic Software" not Progress?
SRT: will circulate minutes again once attendee list is updated
Action items to review:
1. ACTION: ALL actions required re-submit use cases with business context
2. ACTION: HH/YL Check connection of mailing (public-ws-chor-comments) lists to bugzilla – no (bring up as agenda item)
3. ACTION: Hugo to ask for XML Spy licences - done
4. ACTION: Yves/Hugo setup an editors ML - to be checked
5. ACTION: DC to send details to private list – in progress
6. ACTION: MM to post glossary document on publlic list for review - done
7. ACTION: HH will take a look at Monica’s glossary document – done (track)
8. ACTION: CM will check with Sun about F2F - open
9. ACTION DC can check with sonic for F2F - open
SRT: 9 actions from last meeting
SRT: one was re-submit use cases with bus context
SRT: will update mine
SRT: sent out a summary of use cases. Very difficult to find out use case stuff if subject line not prefixed. Please do this.
SRT: Please add "use case" to subject line even if that wasn't the original subject
SRT: checking the condition of the comments list from bugzilla
Hugo: not possible yet it seems
DA: need to bring this up as an agenda item if bugzillza will not work for us
SRT: XML-Spy issue is done
SRT: Yves, and Hugo, you were going to set up editors' list
YV: Will check it out
SRT: DC was going to send details of Stylus XML Editor
DC: Sent it today but it was hung up, should appear momentarily
DC: I sent it to member-ws-chor
SRT: Glossary terms published, thanks to Monica
SRT: Action #7, why was Hugo going to look at glossary?
MC: Hugo is editor of glossary
LG: this was to look for overlap
Hugo: this is what I found. Defn of web service is different. Defn. of interface seems different, also discrepancy. re service & operation
SRT: We'll have to bring this back as another agenda item
Monica: received a couple of comments from ??
Hugo: will send Monica written comments.
SRT: Re F2F. DA, any report?
DA: Grainger has kindly offered to host F2F in June
DA: Proposed dates are Wed/Thurs/Fri, last week in June - 25, 26, 27
DA: 2 1/2 days of meeting, Wed Thurs + 1/2 of Fri
DA: Will be held at Grainger HQ in Lake Forrest, IL
SRT: Carol & DC, we needed you as backup
SRT: Re dates, can't do earlier because of Java One
??: dates conflict with WS-I plenary
CMcD: you want us to still check out Burlington?
DA: We can move date if we need
SRT: If anyone has issues with date, please let Martin, SRT, & DA know
?? I have to be at WS-I as well
SRT: Might have to be a week later
LG: A week later is 4th of July in the States
?? How about week before?
?? Or Tues-Wed-Thurs of July 4?
CMcD: JavaOne is June 10-13
DA: Please pursue Sun as host - we may need for other meetings
SRT: May need extra meeting this year. Plus there is next year
SRT: Carol & Dave, F2F status?
DC: I didn't get too far
KL: SAP is on for hosting
CMcD: no response from Sun so far
Greg R: I looked into Novell hosting in Waltham, Mass. Could do in June.
Greg R: 1st week in June, 3rd week in June are open. Is booked week of 9th & 23rd-27th
Martin: best is probably 3rd week
SRT: Harvesting. MC, tell us about harvesting
MC: Coming from a different angle, one thing we did in ws-arch was a harvesting exercise
looked at ebXML, CORBA, DCOM, etc harvested useful stuff
we can start matching use cases to features, this feature is used in this kind of language
CMcD: Harvesting sounds like a good idea
MC: could put on agenda for another time
MC: could start accumulating lists of things to harvest
?? A good idea
DA: I was going to talk about harvesting. Could talk about harvesting use cases themselves from other groups. Architecture scenarios, WSDL scenarios, from which we could gather use cases
SRT: I agree
SRT: I don't know who looked at summary, but until I saw & went thru it I didn't realize how much we had
DA: from the point of view of being a user & trying to understand, if we can leverage use cases from W3C & use our doc to illuminate choreography. aspects, we could achieve a better level of standardization.
DA: good to have set of shared use cases
DA: maybe should correlate our list with other groups
jdart: may not get sharing of use cases given we have diff charter
SRT: maybe take existing use cases and have good understanding & summary
SRT: will soon find out if we have enough info or not
LenGreski: adding on to MC's point, review of other groups' use cases could help us define boundaries where our use cases shouldn't go.
Carol: how about harvesting use cases to make sure we have those from previous specs
LG: reviewing others use cases could define boundary of where we shouldn't go with our stuff
MC: from my observations of WSA may not go into enough detail
LG: if our work is to be an independent contributions should not have great overlap
DA: we are trying to build an overall set of standards, one group might look at use case from one point of view
LG: maybe we are using the word overlapping differently
MC: need people to drag in these use cases
SRT: there is some harvesting we ought to do per the charter. Some inputs in charter are mandatory inputs. DAML-S, BPML. There are areas we need to look at anyway
SRT: are 2 buckets. Technical concept harvesting & use case harvesting
SRT: we ought to be able to classify things we harvest into approp. buckets
SRT: we already have a list of things to harvest from
DA: I see 3 diff buckets. Could define someone as subject matter expert, go out & report back to group
DA: could assign so to harvest from use cases, W3C specs, other proposed specs, BPML, DAML-S
SRT: fine idea
MC: need concrete actions: list of places to harvest from: WSA, WSD, Jim's use case stuff
SRT: takes action to issue list
SRT: will send out list
SRT: will take volunteers
jdart: what were 3 buckets
DA: 3 places are use cases, W3C specs, other specs
ACTION: SRT/MC will prepare list of places for harvesting use cases and specs and send list to WG list
SRT: vertical industry groups. Who suggested this?
SRT: person not on call perhaps
SRT: came out of abstract WSDL discussion
DB: may come out of my use case
[the following occurred later in the meeting but has been here as its is part of this topic. Full chronological order is in the IRC log]
?? Who could be the potential users of the choreography definitions? RosettaNet, etc. are one class of users. Would be good to have outreach to these groups
SRT: could this occur as part of harvesting
MC: Need to encourage user organizations to participate
SRT: add to minutes: identify groups to outreach to as part of harvesting
Tony: I didn't request vertical industry groups to be added to agenda. But what we're really specifying is a language to specify choreographies. Vertical industry groups could be asked for use cases
Tony: when we have a language or at least an embryonic language, could ask user groups if they could use it to define choreography for their particular groups
SRT: DB to lead use case
DB: will go thru use case & why is valuable
DB: will look at requirements from use case
DB: use case is a large manufacturer (auto) in us buying from Korean co
DB: buyer has contract with air freight co
DB: typical of just in time delivery in industry
DB: want to minimize stuff to keep costs down
DB: GM wants to control delivery of goods, particularly from smaller suppliers
DB: they can negotiate lower costs by going to a few suppliers
DB: the buyer -- GM or Ford -- placed an order to manufacturer a certain amount of goods based on pre-existing contract
DB: say, we now want you to deliver 5000 units for pickup by air freight co
DB: 3 companies need to co-ordinate pickup and delivery
DB: I describe the sequence
DB: very similar to EDI documents
DB: Korean & air freight co follow same standard as companies in US
DB: This is not restricted to what GM does. If a small co had to do things differently for every customer, may not have IT resources for that. That is one of the problems with EDI
DB: EDI specifies document contents but not choreography. GM says you have to talk to me this way - big suppliers do this because they have to. But smaller guys didn't take part
jdart: how are smaller suppliers integrated?
DB: manually (fax/phone)
MC: do we need to take account of this in ws-chor? We need to be careful not to confuse web service choreography with more generic B2B issues.
DB: If you can't get the small guys integrated, your ordering times go up, so you need to keep more inventory, so profits go down. So you want to automate as much of supply chain as possible
DB: there are other flows to meet a particular need. Doesn't need to be only one flow, just a small finite number
SP (iona): is the point we want to standardize subset of reusable processes, or process for building processes?
DB: the latter - ability to build processes people need
DB: we can't say to bus guys how to do choreography
MC: agrees
DB: we need to make it cheaper & easier for people to automate, do what they want
MC: this is related to reusable choreography & data formats
MC: what use case highlights is requirement that languages we come up with allow us to define choreography. flexible wrt the things that are being sent
DA: implies is independent of message format
MC: I didn't exactly say that
MC: we need to get to next level of detail to work out exact language
DA: need to have clear MUST & SHOULD
MC: need to turn bus into technical requirements
DA: trying to understand your exact requirement
MC/DA: think we're agreeing
SRT: do we need to represent manual interactions?
SRT: could be just another implementation, just a bit slow
SRT: if you can't tell it's manual and just see message exchange ..
SRT: one of the use cases (from Greg?) was the issue of monitoring
SRT: if we enforce a contract at an endpoint, do we need to monitor endpoint
DA: is it part of choreography to enforce these things, or some other mechanism?
MC: how does one enforce the choreography?
MC: should one enforce a choreography and who would do it
DB: you could imagine talking to someone in Korea using fax & phone. Does this mean you need a variation of the choreography. that excludes interaction w Korea because it uses fax & phone?
MC: we don't want to describe bus process
MC: (versus chor)
DB: this choreography or workflow has been simplified. Could have variations
DB: Between placing order & goods being shipped, buyer changes mind
DB: Could have placed order with multiple suppliers. One can't deliver so increases order with other suppliers
DB: Manufacturer. could be planning to make delivery but there's a breakdown, can't deliver - needs to notify buyer
DB: air freight co may need to change delivery agreement after it's made
DB: nothing's fixed until it's executed. But this is not shown in use case
MC: need state mgmt query on state, change state. Some kind of compensating & consequential actions - recovery
DA: 2 requirements: one is capability for runtime changes to choreography.
DA: one is requirement for conditional logic at runtime
MC: agree
DA: there are two specific requirements in addition to the ones Martin listed
?? was intention to point out that changes were r/t only or can change definition of choreography to use w another buyer
DB: in financial services industry (ATM) - 80% is error checking/recovery
DB: need to handle all failure modes
DA: so requirement for exception handling
MC: exceptions & compensating actions
MC: are we talking about changing participants or choreography on the fly
DB: we are assuming choreographies have dumb, stupid computers behind them and they just follow it. No AI
DA: we managed to route packets, do optimization
DB: one doesn't document the routes, one documents the algorithm. You can't write down potential paths.
<music> la la la, tra la lee </music>
Sanjay: By the way, do we want to capture our understanding of the requirements as we discuss the use cases?
MC: yes Sanjay that would be a good idea, I will harvest from the minutes
DA: Hugo muted me thinking I was the music
DA: when the music came on I was going on a rant about dynamic change in choreography. I do believe there is a requirement for this
DA: this is not just the path you go down when an error occurs, but response to changes in environ. E.g. at 5pm you switch to a new choreography. May at that point store an order till tomorrow. This is very common
??: This is not a dynamically changed choreography, but a higher-level choreography that selects sub-choreographies based on time
DA: I'm quite happy with idea of a master choreography, it solves the problem
??: Good point that it's not just an error condition. But don't want dynamically modified code
DB: does this imply we need a hierarchy of choreographies?
DB: This is a possible requirement
SRT: in the world of composition of choreographies, can you dynamically compose a new choreography and add it to the mix that are currently running
DA: if you have rules to make a deterministic decision
DB: there could be multiple choreographies for placing an order and for paying for it (e.g. credit card, debit, payment terms)
DB: want to be able to compose these
DA: variations on a theme
DB: I agree. Something to think about
DB: 2 last points. Each of 3 businesses - auto, Korea, air freight, wants to manage own IT systems. Are autonomous.
DB: But need to agree on exchange of messages
DB: Last point is that the detailed content of the message can change. If the order is international, need to include customs info. IF it is by air, need air bill describing flight info
DB: But basic sequence of messages does not change
DB: If it comes from Chicago it goes by truck, but the sequence is the same
DB: The documents themselves change. May need line item for customs duties if international, otherwise you don't
ACTION: Martin to extract requirements and issues from the minutes
SRT: who asked for classification of general requirements
DA: I asked for this
close agendum 6
DA: I see 2 kinds of requirements. I am working on outline for requirements. doc. The first ones are use case specific and are derived from use cases. The 2nd class are non-functional requirements --- a terrible name -- dependency on existing standards, technical requirements
DA: Can we classify general requirements?
DA: Scalability, interop, security
DA: There is some overlap to other WGs and other standards bodies. They can't be ignored
MC: Can't we use main categories in WSA as a starting pt?
DA: That was what I was heading towards
DA: I wasn't necessary. thinking about that particular set, but that's a fine place to start
DA: I have this outline
SRT: action to DA to extract classifications. in WSA
DA: will take action
ACTION: Daniel to extract classifications. in WSA
DA: I don't necessarily think can take WSA stuff unmodified
SRT: if you wanted to embellish it, that's fine too
DA: what I plan to do is to publish boilerplate from a standard document, publish that & an outline
DA: how does choreography fit in with other stds
DA: may want to create a dependency map for our group, how we fit in with other stds.
DA: what is the relation between WS-Chor & WSDL, WS-Reliablity, and so on
SRT: I have one item left: reusable choreographies. and data formats
SRT: will need to revisit this next week anyway
MC: this might be one of the cases where we get a technical solution and everyone agrees with it
MC: we have a requirement that the flow is the same but the payload varies. But to have communication at some point you do need to buy into a particular payload format
MC: want to change payload w/o changing flow
?? Are you saying we need to use the XML canonical form
MC: I am thinking more about being able to define choreographies using notion of template types, when you concretize it you fill it what the A's & B's & C's are, or you use an "any" type
SRT: you are talking about patterns of interaction
MC: exactly
DA: the notion of certified or signed choreographies is interesting
DB: I have a preference. One way to do it is to write sequence of messages and define in that message content.
DB: Or can specify a pattern not specify message, extend it and fill in detail (messages)
DB: Or can define flow and then a separate binding document
DA: 2nd one is what we call in C++ a virtual constructor
MC: do people think requirement is a useful thing - abstract messages from flow
SRT: how would name such a thing? The naming becomes an important part of what it is. The pattern of interaction needs to be described ontologically in some sense. So people can find relevant choreographies
SRT: it is a higher-level problem - we may have diff names for same thing
?? Payload can vary based on context
SRT: It's 10:29 now. This topic could be a conf call on its own
DB: the whole idea of name resolution - e.g. schema ns to schema resolution -- needs to be done, hasn't been addressed
DA: That's a political issue. Don't want to go into the namespace thing right now
SRT: logging this as an issue
SRT: Ran out of time, thanks very much everyone
ACTION: SRT will prepare list of places for harvesting use cases and send list to WG list [1]
recorded in http://www.w3.org/2003/04/08-ws-chor-irc#T20-41-43
ACTION: chairs to compose list of tasks for a call for SME volunteers in next week's call [2]
recorded in http://www.w3.org/2003/04/08-ws-chor-irc#T20-42-02
ACTION: Martin to extract requirements and issues from the minutes [3]
recorded in http://www.w3.org/2003/04/08-ws-chor-irc#T21-18-59
ACTION: Daniel to extract classifications. in WSA [4]
recorded in http://www.w3.org/2003/04/08-ws-chor-irc#T21-22-00