- From: David Orchard <dorchard@bea.com>
- Date: Tue, 29 Oct 2002 16:16:27 -0800
- To: "'Cutler, Roger \(RogerCutler\)'" <RogerCutler@ChevronTexaco.com>
- Cc: <www-ws-arch@w3.org>
What do you think of the generic use case that I posted? I think this illustrates nested multi-party ordered choreography in as few messages as possible. Cheers, Dave > -----Original Message----- > From: Cutler, Roger (RogerCutler) > [mailto:RogerCutler@ChevronTexaco.com] > Sent: Monday, October 28, 2002 9:33 AM > To: 'David Orchard' > Cc: 'www-ws-arch@w3.org' > Subject: RE: Stop the ... -> Usage Cases > > > Although I mostly agree with what you are saying, I think it > is unfortunate > if we are totally focussing for choreography on the Travel > Agency Use Case > because I think that the business drivers for standardizing > choreography in > that one are rather weak. It seemed to me that some > discussion WAY, WAY > back in the torrent of email was surfacing some usaqe cases where the > business drivers are much clearer. For example, > http://lists.w3.org/Archives/Public/www-ws-arch/2002Oct/0240.h > tml -- which I > happen to be able to find easily, but there were also several > others. It > seems to me that if you can see the business drivers clearly > that helps to > winnow the higher value portions of the problem. For > example, I believe > that the comparisons of public/private, choreography/orchestration and > message definition/executable (that one is not quite right, I > know) were > moving usefully in that direction. > > I have no desire to debate whether the choreography task > needs to be done, I > am just suggesting a business driver approach to high-grading > aspects of it. > I'm almost certainly oversimplifying, but it seemed to me > that the picture > emrging was one where the public, message driven parts were > carrying most of > the business value of standardization, and the much more complex, > process-involved aspects, particularly of BPEL, were shaking > out as more > relevant to implementation, not standardization. > > -----Original Message----- > From: David Orchard [mailto:dorchard@bea.com] > Sent: Monday, October 21, 2002 2:29 PM > To: www-ws-arch@w3.org > Subject: Stop the Choreography Definition insanity! > > > > I've been buried in the gajillion emails about choregraphy; > heard proponents > of bpss, wscl, wsci, bpel4ws, and the expected "we don't need > no stinking > yet another ws-* spec" speak up. This is impossible for a > reasonable person > to follow, and certainly for our soon to be bewildered AC > reps. I have a # > of proposals to help refine the process. > > 1. No more "imagine application x. Message flows blah blah > blah" messages. > I simply can't keep up with the restaurant ordering, POs, travel > reservations, etc. Purposefully or accidentally, the myriad > of proposals > prevents us from getting closure. Let us use ONLY the travel > agent usage > scenario as defined in the *gasp* W3C Web Services Usage > Scenarios and Use > Cases document. And if it needs additional steps/conditions > added, then > suggest specific changes to the scenario. > > 2. We need actual discussion of REQUIREMENTS, with proposed > suggestions. > For example, I might have requirements: 1. Order of operations MUST be > expressible. 2. Dependent Operations MAY be shown in public > choreography. > 3. Conditions MAY be exposable. Therefore, I get something > like .. foo .. > > 3. Use reasonable subject lines. I suggest using the > requirement (s). For > example, if you don't believe in ordering of operations, then > the subject > should reflect such. Or dependent operations. Or whatever, just not > "choreography definition". > > 4. Get real. To be blunt, if this group decides that it > wants to re-invent > choregraphy languages from ground up with n inputs, it will > be a total waste > of time. Simply put, a number of companies are not prepared > to go through > the reinvent the wheel exercise again. I can state for the > record that BEA > Systems isn't interested in that. Perhaps it's too much to ask of a > standards body, in such a short time, but we need to get to > closure pretty > darned fast, and political realities have to reflect that. > And we're going > to have to find some way of dealing with the fact that some > companies and > people - some of whom aren't w3c member companies - don't > want choreography > done at the w3c at all, so not getting timely closure is a > victory. I have > every confidence that if choreography isn't standardized at > the W3C, it will > happen somewhere else, with commensurately different IPR > conditions, process > and influence over the result. And BEA Systems also believes > that only 1 > choreography standard will survive. > > Cheers, > Dave > > >
Received on Tuesday, 29 October 2002 19:16:31 UTC