In Step 3 of our integration method, we address the new requirements of the railroad operator by specifying the service PIM of TIP (cf. Figure 8-151).
To address the requirements, TIP should provide additional services to the SelfService application. First, it should integrate a new system called DRC and provide a service to determine the possible routes from A to B. Second, it should integrate a new system called CRIS and functionality for managing customer profiles. Finally, TIP behavior should provide support for
Figure 8-150
“provisional booking”. The integrated behavior of TIP is presented in Figure 8-152.
The behavior of TIP starts with either a new travel request made from the SelfService or a request to login an existing customer. In case of a new travel request, TIP first provides the possible routes from A to B. Then, it provides the possible tariffs and availability for the selected route.
When a route is planned and the customer has logged in successfully a new provisional booking can be created. Following this step, different payment and delivery options are presented to the customer. At this point, he can arrange the payment. If the payment is not arranged within a certain period, the booking will be automatically cancelled. If the payment succeeds, the booking will be either fulfilled or confirmed. Fulfilled booking means that no further action on behalf of the railway companies is required.
E.g., customers print their own ticket (home print). Confirmed booking means that the booking is paid for and reserved, but not yet finalised. It will be finalised when the ticket is printed and mailed to the customer.
provideTariffs
provideAvailability
createProvisionalBooking setNewPassword
paymentTimeout
succeed?
planRoute loginCustomer
getDeliveryMethods getPaymentMethods
arrangePayment
cancelBooking fail?
confirmBooking fullfilBooking
printTicket
deliverTicket
Similar to DirectMode, we refine the integrated choreography of TIP by assigning responsibilities to TIP and SelfService. That is, we refine the model presented in Figure 8-152 and derive the distributed choreography model of TIP. Again, for the sake of simplicity, we only present the refinement of a part of TIP. The resulting distributed choreography model of the TIP services is presented in Figure 8-153.
Figure 8-152 The integrated choreography model of TIP
createProvisionalBooking arrangePayment cancelBooking
fail?
loginCustomer succeed?
SelfService
provideRouote fulfillBooking
TIP
In the second refinement step, we model the internal actions performed by TIP in order to provide its services. This step is analogous to the second refinement step performed on the DirectMode model. For that reason, we skip the presentation of the integrated orchestration model of TIP and continue with presenting the distributed orchestration.
To make a booking, a customer first has to login. If the customer has logged in successfully, the SelfService application will be provided with customer information. Otherwise, an error message will be shown to the customer. When logged in customers may also change their passwords (cf.
Figure 8-154).
loginCustomer
setNewPassword
Customer CRIS Management
checkLogin
getCustomerInfo
updatePassword login fail?
login failed
login succeeded login fail?
To make a booking a customer also has to plan a trip. TIP provides this functionality by integrating a new system called DRC (cf. Figure 8-155).
Figure 8-153 The distributed choreography model of TIP
Figure 8-154 Customer Management sub-behavior
DRC
provideRoute getRoute
accept: TravelAdviceRequest reply: TravelAdvice
Only when the customer has logged in and a certain travel option is selected a booking can be made. This is done by executing the behavior presented in Figure 8-156.
ITTI createBooking ITTI
getPaymentMethods
invoke: PaymentMethodsRequest return: PaymentMethods
invoke: PaymentMethod return: PaymentScreen
OMA getPaymentScreen
invoke: BookingRequest return: ProvisionalBooking
fail?
success?
invoke: DeliveryMethodRequest return: DeliveryMehods
getPaymentMethods
arrangePayment
fulfillBooking
getDeliveryMethods getDeliveryMethods
cancelBooking
Besides specifying the behavior of TIP, we also needed to specify the mappings between the information models of the systems that TIP integrates and the information model of SelfService application. However, in this case, most of the SelfService operation invocations have been defined to match the operation executions of the systems that TIP integrates. This resulted in a very few mapping definitions. For example, SelfService expects a TravelOption that aggregates tariffs and availability information. In this case,
Figure 8-155 Route planning sub-behavior
Figure 8-156 Booking sub-behavior
we defined a mapping to combine data from provideTariffGroups, provideTacos and getAvailability operations.
To define the mappings we re-used the mapping DSL presented in Chapter 7.
8.2.3 Step 4. Verification of the integration solution
In Step 4 (cf. Figure 7-129) of our integration method, we verify the service PIM of TIP.
PIM PIM
1 1
3
2 4 2
3 PIM
PSM PSM PSM
5
To do this, we first abstract from the participation of each system and construct the integrated behavior of TIP. In fact, we already have the integrated model of TIP (cf. Figure 8-152). Next, we transform the integrated behavior of TIP to a Petri Net and construct the respective occurrence graph. Then, we use the occurrence graph to check whether the integrated systems are pragmatically interoperable (see Chapter 5, Section 5.3.3). Finally, we analyse the occurrence graph to check whether TIP meets the new requirements.
This step is identical to Step 4 presented in Chapter 7. In fact, we reuse the COSMO to Petri Net transformation, which we developed for the SWS Challenge case study. Figure 8-158 presents the resulting Petri net.
Figure 8-157 Step 4. Verification of the integration solution
A1
The table below presents the correspondence between the actions from the integrated model and the transitions in the resulting Petri nets.
A1 planRoute
Next, we construct the occurrence graph of the net (cf. Figure 8-159)
Figure 8-158
1
Similar to Step 4 in the previous chapter, we analyse the occurrence graph to check whether the integrated system supports all desired execution traces. For example, we check whether a booking can be fulfilled (cf. Figure 7-133)
The answer is “yes” because there is an execution trace from A1 (planRoute) and A4 (loginCustomer) that leads to A18 (fulfillBooking).
Another interesting query is to check whether a ticket can be printed before it is paid (cf. Figure 8-161).
1
The answer is “no”, because the only execution path that leads to A11 (printTicket) is via A9 (arrangePayment).
Figure 8-159, Figure 8-160 and Figure 8-161 only serve for illustration purpose. In real life, we do not need to visualise the net and occurrence
Figure 8-159
graph. In fact, we only need to compute the occurrence graph, represent it in some format (e.g., as a relational database), and query it.