Knowledge of the individual Mule elements means that you can start thinking in terms of services, routers, endpoints, and transformers. When you prepare to develop an application, however, it may not be obvious what should be a service or a router or a transformer. In this chapter we are going to explore a case study and model it using Mule. By the end of this chapter you will be able to model applications using Mule.
Ricston Airways is an airline that operates daily flights from a single airport. The procedure to check in a passenger at this airport is as follows:
The airline's back-end system is queried to ensure that the passenger who wants to check in actually has a ticket.
If one was not already reserved, a seat is allocated to the passenger. While preferences like aisle or window seats are taken into consideration, an expert system tries to balance the aircraft and then allocates a seat.
The weight of the passenger's luggage is calculated through the integrated scale at the check-in counter. Luggage information is sent to the luggage tag printer hooked up at the counter. These tags are placed on the bags and a receipt is given to the passenger.
The airport is then queried for information about the flight—usually just the gate number.
All necessary boarding information is then printed on a boarding card that may vary from one airport to another, but that will always contain the passenger's name, flight details, seat number, gate number, and boarding time.
The information collected is then stored with the original passenger record and used by the airline later.
Every check-in counter needs suitable software to manage the entire check-in process. This software must be able to interact with various other systems and access the correct information to complete the process. This airport is replacing its aging system to use new Java-based software that can integrate with the existing framework.
A passenger checks in by producing proof of identity and proof that he holds a valid ticket. Proof of identity allows check-in staff to verify the person's name (which should be on the ticket). Proof of a ticket is a valid Passenger Name Record (PNR). The airline's database back end is queried with these two pieces of information and, if verified, returns the details about this passenger and his booking. The database is stored remotely at the airline's headquarters, so this would be a web service call. If the PNR is not found, or if the PNR and passenger name do not match, check-in cannot be completed.
When all information about the booking is available, check-in staff can see if a seat was preselected or not. If one was preselected this step is complete, but if not, the airline's expert system will select a seat for the passenger. The passenger may have seat preferences (window or aisle); however, if the preferred seat is not available, the passenger will have to accept whatever the expert system allocates.
The expert system is also remote, and therefore communication at this stage also occurs via web services.
Once a seat is allocated, check-in staff can focus on the passenger's luggage. Each check-in counter is equipped with a scale that, when queried, sends its current reading over a TCP connection. This is done for each piece of luggage. An existing Java service—the BoardingCard service—knows how to interact with the scale.
These luggage details are collected by the check-in software and returned to the counter's onboard electronics; the appropriate luggage tags are then printed. It is the check-in staff's responsibility to manually affix these tags to the luggage. Receipts are given to the passenger so they can claim the luggage at their destination.
The airport is the only entity that knows which gate a flight is going to board from; this information can change at any time. Consequently, the gate number for a flight cannot be cached, but must be requeried every time. Gate number requests are made using web service calls. The existing BoardingCard service can also interact with the airport to retrieve the gate details.
All of this information is put together to produce the boarding card required by the passenger to board his flight. This information is also sent back to the airline to be stored for later use.
Our task for this session is to model the given example using Mule and the various Mule elements to demonstrate how all of these system requirements can be integrated.
Confirming Passenger Details
The first step is to verify passenger details. We know that a web service call will be made to the airline, but we also know that without the passenger details the check-in process cannot continue. Initially, the PNR and passenger name are obtained and entered manually by the check-in staff. The system should send this information to the airline via the appropriate web service. The airline will respond with the passenger's details, as shown in Figure 3-1.
Note
The scenario represented in Figure 3-1 is a request-response; we need to wait for the web service to finish processing and return a result.
Allocating a Seat
Figure 3-2 illustrates how, once we have the passenger details, we can see if a seat is allocated and, if not, the expert system can be queried for a seat.
Weighing the Luggage
Once the seat is allocated we pass the full passenger details to the BoardingCard service, which is designed to interact with the scale built in to the check-in counter. As you can see in Figure 3-3, this connection is made from within the BoardingCard service.
Retrieving the Gate Number
The BoardingCard service also knows how to communicate with the airport and retrieve the gate number for a given flight. The BoardingCard service is still in control of the message flow at this stage; note in Figure 3-4 how it has yet to produce an output.
Producing a Boarding Card
The last step is to produce a boarding card (see Figure 3-5). This information is sent to the check-in counter staff, who knows how to print a valid boarding card for the passenger. Additionally, the completed passenger details are passed back to the airline to maintain records.
We can see from this modeled example that Mule can interact directly with external applications, provided it can use an endpoint that the third-party application understands. While modeling the application, we can consider any third-party items as services that Mule will use. Other services will be Mule-hosted components that form part of the entire integration project.
As you may have noticed, the individual steps that make up the entire process are represented by services. The routing and transformation of data, if any, was not shown in this example. The best practice is to let Mule handle the routing and transformation of data rather than the services; the identification of the routing patterns and transformation requirements has been ignored up to this point.
Implementing this modeled example will involve the following activities:
Coding the services and any other required classes. All of these items should be tested properly before being used inside Mule.
Identifying the correct routing patterns needed.
Identifying any locations where transformations are required.
Building the Mule configuration using these services. The best practice is to test the routing logic first, and independently of the transports that will be used. You can achieve this by using virtual channels (the VM transport) to connect the services to one another, which frees you to focus on the correct choice of routing pattern and transformation without the overhead or potential problems that live transports may introduce.
The Mule configuration needs to be thoroughly tested to ensure that the routing logic does what it is supposed to do. This can be achieved using Mule-oriented Junit tests—a topic that is covered in the next chapter.
When all tests pass successfully, you can start introducing the live transports.
Modeling applications in Mule involves thinking about the different steps that need to be taken for the individual services Mule will host or interact with. Routers govern how the data will flow from one service to another, and transformers are needed to convert data from one format to another.
The Mule application can be built from such a model by using VM channels initially, to let you focus on the routing logic; you can replace these endpoints with the live transports when you are satisfied that the routing has been implemented properly.