RE: Stop the ... -> Usage Cases

David

A nested multi-party choreography is not, in my opinion, the main issue. The
real issue is that internal business processes sometimes HAVE to be
constrained by choreograhpies that are not within the control your control.
I don't think your example includes this scenario, but the eCommerce
scenario does.

If you wanted to include this in the travel agency use case, then the
customer would NEED to know all about the interactions with the hotel and
airline web servics which somewhat defeates the benefit of using a travel
agent in the first place. Including this type of message flow would make the
Travel Agency use case unrealistic. On the other hand, the Travel Agency use
case provides some good examples of how ontologies can be used.

Regards

David

-----Original Message-----
From: David Orchard [mailto:dorchard@bea.com]
Sent: Tuesday, October 29, 2002 4:16 PM
To: 'Cutler, Roger (RogerCutler)'
Cc: www-ws-arch@w3.org
Subject: RE: Stop the ... -> Usage Cases



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
>
>
>