- From: Burdett, David <david.burdett@commerceone.com>
- Date: Fri, 1 Nov 2002 13:22:21 -0800
- To: "'David Orchard'" <dorchard@bea.com>, www-ws-arch@w3.org
- Message-ID: <C1E0143CD365A445A4417083BF6F42CC053D1443@C1plenaexm07.commerceone.com>
David I am not suggesting that we delete the travel example and I don't disagree with you when you say: "Travel was one of the first things that programmatic interfaces were put onto, it's been used in a whole bunch of different choreography specs, and it absolutely is being used for web services today." It is and will remain a good and valid use case. I'm suggesting that the eCommerce example I provided should be used as an addition use case. My reasons for this are as follows: 1. XML based web services will eventually displace EDI as the main way of doing electronic commerce 2. We should therefore include a use case that describes one of the typical ways in which EDI is used today I agree that EDI is not one of the main uses of web services today, but shouldn't an architecture plan for the future as well? David -----Original Message----- From: David Orchard [mailto:dorchard@bea.com] Sent: Tuesday, October 29, 2002 9:36 PM To: www-ws-arch@w3.org Subject: RE: Stop the ... -> Usage Cases I just posted another message on why I think travel is a good example, and why the generic scenario I came up with covers the main issues. At this point, if the travel example isn't working, then let's just delete the whole scenario from our documents and minds. I'm not seeing much or any support for what I've tried to do with adopting one scenario based upon the one we have. Though I'm baffled. Travel was one of the first things that programmatic interfaces were put onto, it's been used in a whole bunch of different choreography specs, and it absolutely is being used for web services today. Cheers, Dave -----Original Message----- From: Burdett, David [mailto:david.burdett@commerceone.com] Sent: Tuesday, October 29, 2002 8:50 PM To: Cutler, Roger (RogerCutler); 'David Orchard' Cc: 'www-ws-arch@w3.org' Subject: RE: Stop the ... -> Usage Cases Rogedr said ... 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. ... I agree completely David PS Zahid and I have been unable to make posts for the last few days which Hugo and Gerald at the W3C have now fixed. This is why we have been so quiet recently ;) -----Original Message----- From: Cutler, Roger (RogerCutler) [ mailto:RogerCutler@ChevronTexaco.com <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.html <http://lists.w3.org/Archives/Public/www-ws-arch/2002Oct/0240.html> -- 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 <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 Friday, 1 November 2002 16:22:11 UTC