Travel agency sceneario - details & comments

I have taken a closer look at the first user scenario in the 
requirements doc. This is the travel agency scenario submitted by Martin 
Chapman 
(http://lists.w3.org/Archives/Public/public-ws-chor/2003Apr/0004.html).

I have made the experiment of trying to take this user scenario to the 
next level of detail, down into individual use cases. I haven't done 
this completely, but I've done it for a subset of the flows and states. 
My original goal was to see if this use case could serve as an example 
of dynamic participation (since hotel providers, for example, can enter 
and leave as participants). I think it does illustrate this, but I also 
find that going to this next level of detail exposes and illuminates a 
lot of other issues, too.

See attached UML use case and activity diagrams. Note: these types of
diagram are not ideal for modelling WS choreography, but they're
standard and it's a start. I will mention some specific limitations 
below. It is also quite likely these don't model what a real online 
travel agency does.

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