W3C home > Mailing lists > Public > www-ws-arch@w3.org > October 2002

RE: Stop the ... -> Usage Cases

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>
Message-ID: <005e01c27fa9$9bcf4d50$4e0ba8c0@beasys.com>

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 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 3 July 2007 12:25:09 GMT