RE: Stop the ... -> Usage Cases

MessageJust my $.02

I also believe that the business value of the travel example is debatable.
There are use cases that are much more appealing. Unfortunately, some of the
best ones are very specific to an industry or even a limited group of
companies. Understanding these use cases might require an understanding of
the industry practices, or how particular organizations perform business.

I think the travel example, just like the mythical banking ATM example, is
one that everyone can understand, whether they are dealing with product
acquisition in the automotive industry, or integrating HR services, or are
new to this space and are learning the spec ahead of using it for any real
life scenario.

A generic choreography that is not rooted in any real life scenario is just
as valid, but one that has some story to tell, even if that story is not
about saving millions of dollars, makes for a more interesting reading
material. I would rather see a generic example with some story behind it,
then the choreography of activities A, B, C and D.

arkin

  -----Original Message-----
  From: www-ws-arch-request@w3.org [mailto:www-ws-arch-request@w3.org]On
Behalf Of Cutler, Roger (RogerCutler)
  Sent: Wednesday, October 30, 2002 2:20 PM
  To: 'David Orchard'; www-ws-arch@w3.org
  Subject: RE: Stop the ... -> Usage Cases


  I don't think scuttling the travel case is a good idea.  I'm not trying to
subtract content but to add, or at least to ask for addition.  The travel
use case obviously illustrates sequences of messages.

  What I am pointing out is the lack of a use case where the business value
of transmitting the choreography from one player to another is made clear.
I'm beginning to think that there might be some business value hidden in the
travel case, but I have not seen it described clearly.  If it were, I think
it would help focus what is important in the spec.  For example, are there
cost savings to the travel agent involved with communicating an expected
sequence of messages with, say, a hotel in a standardized way?  Not the
whole logic ot the thing, just the part that involves the hotel.  If there
is I don't quite see it, but I think there might be.

  It seems to me, however, that there are probably other use cases that show
this kind of thing better, perhaps involving companies that sell the same
thing to a lot of other companies.  The travel use case suffers here, I
think, because it sells the same thing to a lot of people, and the thrust of
web services is machine<->machine, not machine<->person.  Unfortunately I am
not in the kind of business setting that gives me personal knowledge of this
sort of interaction.

  I think to some extent we are talking at cross purposes here.  If the
generic example you mention is the one I think it is, it certainly
illustrates the primary message patterns but is utterly silent about the
business value of standardization.

  -----Original Message-----
  From: David Orchard [mailto:dorchard@bea.com]
  Sent: Tuesday, October 29, 2002 11: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]
    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 --
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