The top level diagram is a use case diagram that shows the actors andidentifies 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 travelagency and ask to be added or removed as a participant. "Hotel" here isa 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)