The top level diagram is a use case diagram that shows the actors and

identifies the use case(s) in which they participate. I also have

activity diagrams for the "Book Vacation", "Process Booking", and
"Select Hotel" use cases.

I found this exercise quite enlightening, and draw the following

implications from it:

1. There is more than one system involved. The large box in the use
case
diagram is the travel agency's system. Other systems belong to the
credit card processor and hotel, airline, and car rental providers. If
I'm looking at this from the standpoint of the travel agency, I don't
control the other systems and have limited visibility into their
internal processes. I may get a choreography definition from them that
helps me understand my role in their system. But I may not: I may just
get access to them at the lower level of individual services.

2. Participants are dynamic. A particular hotel can contact the travel

agency and ask to be added or removed as a participant. "Hotel" here is
a role that could be fulfilled by any individual hotel. (UML use cases
only have actors, they do not distinguish between roles and
participants
- but IMO this distinction is crucial for choreography).

3. Martin's original mail had a second use case, involving a callback

scenario. IMO that scenarion could also occur within the context of the
travel agency example. For example, when a hotel operator registers
with
the travel agency so that reservations can be placed with it,
presumably
it will have to include contact information so it can be informed of
reservation requests. In some cases this might be traditional methods
such as phone or fax. But it is also possible for the hotel to expose a
Web service interface, in which case this interface needs to be
invoked.
This could be considered a callback - the hotel has registered a
callback and then later we call it.

N.b. I don't think BPEL supports dynamic participation in any direct

fashion. It does handle callbacks in the sense of async interactions.
But this case is a little different, because the registration process
for the hotel (creating the callback) is really a whole different
choreography than the one that performs the callback.

4. The most natural way to model things is through a hierarchy, in

which
a complex of activities (a process) in one diagram may be represented
as
a single activity in another, higher-level diagram. An example is the
"Book Vacation" activity diagram, where "Select Hotel" is shown as one
activity, but it is really a sub-choregraphy, shown in a separate
activity diagram. N.b. I don't think BurdettML supports this kind of
nesting of choreographies, at present. (This is also a stretching of
the
UML notation).
5. There is another kind of link between sub-choreographies. I have
modelled the "Book Vacation" activity diagram from the point of view of
the travel agency's client. There is a point where the user confirms
their itinerary and presents payment information. This is the standard
"checkout" phase in a shopping application. At this point, the travel
agency needs to receive the information and execute the "Process
Booking" use case.

6. Point 5 is related to their earlier privacy discussion. IMO "Process

Booking" should not be directly visible to the client. It involves
interaction with a credit card processor. It may also involve further
interaction with a travel provider, e.g. a hotel may charge a deposit
against the client's credit card.

We've talked a lot about having a global view of the choreography.

However, as I've noted before, we may also need participant-centric
views that expose limited information. Suppose the travel agent wants
to
publish a choreography definition for the use of clients. Likely it
doesn't want to hand them the details of how the back-end processing
works, nor should this be necessary. "Select Hotel" is a visible
sub-choreography, "Process Booking" is a private sub-choreography, from
the standpoint of the client. All the client should get to know is if
it
succeeds or fails.

7. Activity transitions in the diagrams do not distiginish between

error
and normal transitions. We probably do need this distinction (DB has
proposed a way of handling this in BurdettML). Also there are likely
possible error conditions for which no explicit transition is given. We
need to consider what should happen in these cases.

--Jon
(image/gif attachment: BookVacationActivityDiagram1.gif)
(image/gif attachment: ProcessBookingActivityDiagram1.gif)

(image/gif attachment: SelectHotelActivityDiagram1.gif)