RE: Stop the ... -> Usage Cases

RE: Stop the ... -> Usage CasesDavid,

I disagree that the customer wouldn't need to know about interactions with
the hotel and airline.  That's why I think this is such a great example.  I
DO know that a travel agent service is going to talk to a hotel, air, car
reserveration service.  Heck, I fly on the airline and go to the hotel.  I
typically even check out an air reserveration service myself, such as
expedia (which front-ends onto sabre).  Once a travel agent gives me an
itinerary, I often call up the relevent airline or hotel and change a
reservation afterwards.  The benefit of using a travel agent is the
consolidation, the asynchrony, the algorithm for choosing best fares and
route combinations, bulk rates for billing, etc.  And btw, it works the
other way too.  A hotel/air knows that it is a customer being involved.  For
example, a fare quote or hotel quote is often based upon the company that
the employee works for, and whatever negotiated rate applies.  Now that my
mind is remembering things, a change in the air reservation will typically
ask me for the PNR, which is the key into my particular air reservation.  So
even the primary key to the air service is passed through to me, so I can
contact them directly.  Though the systems are gradually getting smarter
with using names or profile keys (frequent flyer programs).

Further, the choreographies are often constrained.  The sabre reservation
services has a very particular flow through flight availability, fare quote,
ticket issuance mechanism.  That process flow has been 3270 screens for a
gajillion years.  So the web service interfaces to it are very well
constrained as they are basically doing 3270 screen scraping.

I guess my work in 1998 building XML/HTTP interfaces to sabre, galileo and
starwood is coming through :-)

There are constraints on the flows within the organizations, typically
because of existing sytems.  This is modelled in the generic scenario. And
the initiating service knows about nested choreographies.  I think these two
points, constraints and global model, are covered in this abstract scenario.

And remember, the scenario that I offered is an ABSTRACT scenario.

Cheers,
Dave
  -----Original Message-----
  From: Burdett, David [mailto:david.burdett@commerceone.com]
  Sent: Tuesday, October 29, 2002 8:50 PM
  To: David Orchard; 'Cutler, Roger (RogerCutler)'
  Cc: www-ws-arch@w3.org
  Subject: 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
  >
  >
  >