|
Chairs |
| ||
|
Oracle | |||
|
Enigmatec | |||
|
W3C Staff Contacts
|
| ||
|
|
| ||
|
|
|
|
Name |
Company | |||
|
Choreology Ltd |
||||
|
Intalio Inc. |
||||
|
W. W. Grainger, Inc. |
||||
|
Novell |
||||
|
SAP AG |
||||
|
SAP AG |
||||
|
Cisco Systems Inc |
||||
|
Sun Microsystems, Inc. |
||||
|
Oracle Corporation |
||||
|
Intalio Inc. |
||||
|
SeeBeyond Technology Corporation |
||||
|
BEA Systems |
||||
|
Hitachi, Ltd. |
||||
|
Attachmate |
||||
Assaf Arkin volunteered to scribe for the meeting.
The following is a list of recent scribes (in order): Assaf Arkin, Monica Martin, Carol McDonald, Nick Kavantzas, Tony Fletcher, Mayilraj Krishnan, Francis McCabe, Jeff Mischkinsky, David Burdett ,John Dart, 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 7th October 2003
Actions from previous meeting marked with *
Organisational
ACTION : chairs look at WSA issues process and recommend whether it should be adopted by this group. recorded in http://www.w3.org/2003/09/30-ws-chor-irc#T20-22-01 IN PROGRESS
ACTION: Steve to facilitate calling a Requirements / Use Case editors meeting.
SRT: single objective of editors meeting to take stuff created during F2F and consolidate it, and get a consensus about the contents before getting consensus to publish.
Venue to be announced prior to next meeting. IN PROGRESS
*ACTION: The transaction requirement to be placed back on the agenda for next week assuming a succinct definition of transaction (see action above). DONE
Usecases/requirements
ACTION: Use Case proposers to highlight/extract any EAI specific aspects from their use cases.
Monica Martin expects to deliver something next week. IN PROGRESS
ACTION: Chairs to reply to Marco requesting clarification of his use case recorded in http://www.w3.org/2003/09/30-ws-chor-irc#T20-50-10 IN PROGRESS
ACTION: Steve: Will put all the comments on draft requirements above into the requirements spreadsheet and send out - Awaiting latest spreadsheet from Daniel Austin. NO PROGRESS
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. DONE Ð See editors F2F
ACTION: Tony Fletcher will provide a good definition of transaction Ð DONE(add URI)
BurdettML
Nothing to report
OracleML
*ACTION: Nick to provide spreadsheet matching OracleML to requirements IN PROGRESS Ð for next week
SRT: Suggested that all members review the Oracle contribution placing questions, issues and comments to the list.
Issues
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: Steve RT will send a one-page summary of his thoughts.
NO PROGRESS
Liaison activities
ACTION : Tony to keep group updated on un/cefact recorded in http://www.w3.org/2003/09/30-ws-chor-irc#T20-32-44 - IN PROGRESS
ACTION: Tony Fletcher will mail to list for new site: www.unbcf.org/ DONE
ACTION : chairs to explore with UN/CEFECT whether a liaison is of mutual interest recorded in http://www.w3.org/2003/09/30-ws-chor-irc#T20-33-04 IN PROGRESS (offline discussion between chairs)
*NEW ACTION: Place Liaison into normal agenda for next time.
Martin: The pre-registration for Australia results are that only 3 people registered, 7 said can't make it, 1 person can't make decision therefore the chairs decided to regretfully decline AlastairÕs kind invitation.
SRT: Enigmatec has offered to host, possibly London or Cambridge, Cambridge further from airport but a pretty place with access to interesting people.
Martin: F2F planned for week of Dec 15th
NEW ACTION: SRT will formalized in e-mail the offer.
Martin: Next W3C plennary session in France in March, plan to include W3C Chor F2F during that meeting (Q12003)
Martin: The planned dates are either 1st and 2nd, or 4th and 5th March 2003.
-Requirements Ð next steps (progress/review)
See action items above on Editors F2F
- Issue tracking (progress/review)
Nothing to report
Liaison
WS-BPEL Ð any major issues being reported?
Martin: BPEL next F2F in Florida 1st or 2nd week of December, week/two before W3C Chor F2F.
BPSS Ð any developments on TC?
Monica: BPSS TC doesn't open until Monday.
Ton'y requirements from week previous
tony: not exactly a use case, but a submission to have a requirement added for transactions that should be included in requirements document, based on several use cases
tony: those use cases require a coordinated outcome and knowing what that outcome is
tony: doesn't want to get into too much details, but take a step by step approach, recommend first looking at the basic requirements and if that accepted, look at how to implement requirements in choreography language, need to know how language is shaped up, need basis for language before deciding how it would fit in, so we'll need to revisit that later on
tony: don't need to get into technical details regarding protocols, this can be abstracted and dealt with by the bindings, we are fairly insulated from the details
yaron: assumption that cannot be taken at face value, doesn't buy that we can insulate from the coordination protocol in use
MC: agrees with that
daniel: not acceptable that it's technology specific, need to find a way to abstract form the specific technology
detail
yaron: this requirement to come up with abstract solution may not be achieveable
MC: requirement: there must be some way to abstract activities into some unit for rollback/recovery/compensation
Martin: I think the transaction word is a bit misleading. I think what we need to say at the requirements level is the need to be able to group a set of activities into a "unit" of work for the purposes of failure, compensation recovery etc
tony: if you look at actual requirement it deals with being able to demarcate transaction, determine where it starts
tony: declarative language would indicate where it starts, propagated from one role to another if people do not disagree, let's add requirement and in the next step determine how to meet the requirement
MC: what's the difference between transaction and choreography? they are both collections of activities that need to be rolledback at once
SRT: supposed we have choreography and we have way to include units of activities, if one uses choreography in case of non/failure and in case of failure, what does it give us? if we can't define the benefit then we can't justify a requirement
SRT: one of the benefits of choreography is to guide the generation of Web services, and possibly to guide the generation of handling of units of work, which is one possible use
SRT: in the case of choreography monitored, e.g. for conformance, the point where business transaction occurs might be demarced in the real service by some service being sent that the choreography service picks up and matches
SRT: if you got those two as use cases, it supports the need for demarcation that tony is talking about
tony: there is a difference between a web service that is transactional and one that isn't
tony: you make use of the Web service, look at the result you get, (one or more), make up your mind (application decision) as to whether the results are acceptable or not, all or some of them, and then decide which to cancel and which to confirm, gives you more control, and you get to know that they all done what you've asked them to do, and which haven't, gives you a level of control and a knowledge of the outcome
tony: you can design an application to do the transaction protocol and factor out the protocol bits
jj: the transaction requirements brings a control flow requirement, chor language might support notion of defining a block and transfer of control.
jj: when we talk about rollback and execution space and how to rollback transaction, not sure this will be part of WS chor
MC: if you try to do something and it goes wrong, e.g. many B2B scenarios, you need to rollback or compensate, but lock to block, etc. those features need to be in the requirements
daniel: what is the difference between transaction and non-transaction? does transaction have constraints based on a contract? in that case, what is an example for non-transactional WS or non-transactional chor?
tony: bank account: if non transactional and you ask if there's a debit and message gets through then application may succeed or failed and you may or not know, but when you get response bank account has been debited and you may not know about it; in transaction, you get confirmation that it can be done and then you send a message to confirm/cancel
MC: this can be modeled using the language
tony: we can have detailed argument about good and bad ways to do transactions, but we should focus on high level requirements to driving transaction, not on how it's actually done
SRT: back to my previous comment, it can be used to monitor and verify but not used to enforce
daniel: there is design time and run-time component, but not sure how they relate to transactions
tony: if you consider a business activity that includes order, delivery, ack of delivery, request for payment, payment made, that's the overall choreography and you have a decision to make at the business level. you could make a transaction from the beginning to end if you're not dealing with physical goods. right at the very end if the payment fails, the whole thing disappears, including the electronic goods, as if nothing ever happened
tony: more likely that you have three transactions in sequence, if one works then you go on to the next one, if order works you go to delivery, if delivery works you get to payment.
MC: choreography is about message exchange, so this is already an inherit thing in choreography
tony: this might be thinking ahead into how to meet the requirements
SRT: this has odd semantics. when you design chor from ground up with no ws, there is benefit to decide what is positive outcome and what is negative outcome within any interaction that may occur. this is what we call business transaction or in case of failure compensation. so when building from ground up it makes sense to put some markers that let you talk in those terms. might be useful in design time as hint to whatever generates WS in back-end, and also su
SRT: it allows you to send back monitoring information to someone who's watching in terms of success and failure.
if you can imagine a world with no segmentation between business success and failure, then there's no value in that. essentially you are really monitoring but the implementation may be very simple to bind into a transaction message coming in & out of a WS. or it may be more complicated and need to consolidate because there is more than one message,
daniel: are we talking at the right level of abstraction?
MC: what are the actual language features we need? scope things. what happens when things inside the scope fail. recovery.
daniel: the detection of failure/success would probably occur, and this is a business case, need to detect when something fails and report about it.
daniel: we talked before about trying to identify transaction primitives, and start building on those.
nick: if you look at Oracle's proposal it has some marking for backward and forward recovery. let's look at that and comment on what needs to be done. there's already a lot of primitives and designes on how to deal with handling faults, compensation, semantic rollback. in the distributed case it makes more sense to have this and other stuff, like cancel handlers that are not in the proposal. I would like to see a more concrete contribution.
tony: you may well have met the requirements in your proposals. I am trying to establish the basic requirements so anything that can be put in and meets the requirement could be justified and acceptable. it's difficult to be specific about what we need in the language until the nature of the language becomes clear.
tony: i hope this would be a fairly light touch [adding these semantics to the language]. in BPEL it has to be more specific, but in chor language it could be less specific, so we might not need a lot in the language to meet those requirements.
SRT: suggest two actions. action 1: to tony, take a look at the Oracle submission and see if there's a need based on your requirements, action 2: myself or Daniel, go back through the requirements document and annotations from last F2F and pick up all items from documents and see how it relates to transactions, make sure we're not spending time spinning our wheels
NEW ACTION: Daniel to look though document and see which requirements we captured so far regarding transactions [1]
http://www.w3.org/2003/10/14-ws-chor-irc - T21-05-54
NEW ACTION: Tony to take a look at Oracle submission and see if it meets base requirements [2]
http://www.w3.org/2003/10/14-ws-chor-irc - T21-06-11
SRT: elevator pitch. I'm getting asked more and more by reporters and watchers, what's the use of chor? what's the business benefit?
daniel: made the point before that given a chor there are two possible uses: at design time use it as template to help implement chor, and at run-time use it to manage and monitor. the business benefit: what's the business benefit to be able to build a business process? the value is to be able to build and implement that using WS seems very straight forward.
SRT: anyone else has ideas how to take it on the road and sell it? I could always use BPEL.
MC: BPEL doesn't scale well. you can use it if you want. for 2 party interaction it works, as soon as you start scaling there is no one central place to see the flow, gets ad hoc, gets hard to manage.
jj: we should try and put SOA in the elevator pitch, WS chor is a fundamental component of SOA, without that SOA could not scale or even be started. we need to create a strong link between SOA and WS chor.
SRT: what is that link, what chor does that is so fundamental to make SOA work?
Daniel 1) BPEL doesn't scale to multiple services or complex transactions
MC: instead of trying to bring abstract together, you come up with picture of how things work together. simplicity that reduces cost.
Daniel:2) we need a way to encode the business rules that define the contracts among multiple actors
Nick: going back to first F2F, if you don't have chor lang, you can't define rules of how you do business together. it gives you the rules how to play soccer so two teams know how to play. it's all about how to make compatibility that two processes work together. it's fundamental design for one entity to engage in business with another.
jj: the notion of API in SOA is disappearing, the replacement of API in SOA is precisely WS chor.
Daniel: 3) we need to have choreography in order to manage and monitor the execution of business process
SRT: one of the biggest issues to date with WS is the lack of interoperability. maybe the advantage is that chor can absolutely promote interoperability. does that sound reasonable?
MC: absolutely. instead of having companies come up with their processes, in one central place you can define all the rules, all in one place. having one place to define those things promotes interoperability.
Daniel: 4) a declarative choreography enforces compatibility amongs services, by requiring interoperability
SRT: interested in co-authoring article looking at business benefits, and perhaps technology, but much more about the business space. I have a host or publications. any takers?
MC: we can leverage W3C resources. sounds like what a product manager would do. not sure if this is a group responsibility.
Yves: it should be left to the comm team and we should focus on the core issues.
MC: we need summary of business benefits and push it to analysts, etc.
SRT: need business benefits down to success factors, use cases and eventually the technology. that's a way to get people engaged. it's a CSF that we fully understand and elaborate what those business benefits are. if we can't do that, I don't see anyone else doing that.
MC: also relates to drumming up interest in chor, getting more members, more organizations involved. BPEL has a huge momentum and we need to keep the pressure on.
SRT: if anyone wants to do that article, just send me an e-mail.
Submissions/contributions (what is going on?)
Kevin: what is the working group going to do with submissions on the table?
SRT: we've asked oracle and david to go back and match against requirements. we asked group to look at Orcale's submission. the ball is in the group's court.
SRT: The process when contribution comes in: put it on table, talk about it, look at technical aspects. that requires a discussion. can't be done just in conf call, must be done between conf calls.
MC: I expect feedback for both submissions from the group.
Kevin: any plans to establish some sub-group to focus on that?
MC: individuals can review materials and provide feedback on mailing list. don't see purpose for sub group.
Kevin: sub group for people interested in creating a baseline document for the whole working group. discussion is now not going anywhere regarding baseline documents.
SRT: because there is no discussion. have not seen any comments from anyone but myself about submission. only people showing interest so far as me and nick.
MC: and yaron sent comments about burdettML
MC: unless there are comments I don't see the point in having a task force
Kevin: if there are no comments, what are we going to do?
MC: just means the group is in apathy
daniel: I want to see us set up a goal to have a baseline document by some date.
MC: we already have a plan for that for the next F2F
SRT: when we got nick's list of how contribution matches requirements, we can proceed. this is a new action item only from last week.
Daniel: what is the intended audience for the document? what is the scope of the document we intend, who is the person we intend that document to be used by? who is the person intended to build choreography widgets?
Daniel: I'm looking for something more specific. is this for business users? who is the intended end-reader? we should put that out and make it more explicit as guideline for people who put out the baseline document.
SRT: just ask nick questions. if something doesn't make sense in the document, just ask nick for clarification.
SRT: we have one contribution that has been talked about a lot, and one that has not been talked about at all.
Tony: I agree with kevin. if the message is to wait a few weeks, I'm fine with that. I think people get fatigued when we get a submission put a lot of effort into that, and then again, but it's not a baseline document. people are voting with their feet. put effort into one document but if it's not going to be a baseline submission, why put any effort into that?
Tony: once we get a baseline document people would be more interested because they know their feedback would have more effect on the group. we don't know if comments on nick's document would have any effect on the group.
Kevin: I was confused at F2F. we have two submissions on table, but I'm not sure what action we are going to take. we know they are working on another proposal to combine the two submissions. is this part of working group work, or not related to this working group. are we waiting for Oracle to bring another submission, or is this a task force working in parallel to create a baseline document. better if we assign a small group to work on that.
NEW ACTION: Co-chairs try to provide clarity to the group and make sure clarity prevails to next meeting [3]
http://www.w3.org/2003/10/14-ws-chor-irc - T21-33-26