Enterprise Integration Zone is brought to you in partnership with:

OpenSource has posted 2 posts at DZone. View Full User Profile

Pattern Based Development with ServiceMix

06.10.2008
| 83319 views |
  • submit to reddit

Case study: an insurance broker

A new insurance company, EasyInsurance, wants to provide potential customers with a web site which can be used to get quotes from various insurance companies based on the type of insurance you want. When the website will be put online only request for travel and car insurances are available, but in the future EasyInsurance intends to also provide the same functionality for home insurance.


When an insurance request is entered via the website, the request is forwarded to insurance providers depending on the type of insurance request. The number of insurance providers should also be easily expandable. The responses from the insurance provider are shown on the website and an insurance contract can be requested from the provider. Figure 5 shows an overview of the website’s functionality to send request to insurance providers and how the responses will be sent back to the website.

Figure 5 An overview of the insurance broker case study showing the messages sent to the insurance providers depending on the insurance request type.

An added problem that we need to solve in our integration solution is that the budgetCar insurance company requires the requests to be sent in CSV format over FTP (to keep it simple we’ll use a file connector here) and the LuxuryCar insurance wants an XML file over JMS. The Resort Travel Insurance company has the requirement that all calls are done using webservices.

Pattern based design approach

Most people who have worked in integration projects are probably familiar with the Enterprise Integration Patterns (EIP) book of Gregor Hohpe and Bobby Woolf. This book shows a number of design patterns that you can use to document, describe and solve your integration challenges. In the next couple of paragraphs we’ll show how you can use the patterns described in the EIP book to describe the insurance broker case study.

Let’s first look at figure 6, which describes the request part of the case we presented.

Figure 6 This figure shows the request flow of the insurance broker integration solution described using enterprise integration patterns from the EIP book.

Let’s first look at the various patterns shown here before we explain how they work together.

Table 1. Used patterns for the request flow of the insurance case study.

Pattern
Description
Message channel  A message channel allows applications to communicate with each other.
Channel Adapter  A channel adapter defines how you can connect to the messaging system (e.g. a JMS broker) so you can receive and send messages.
Content based router  As the name implies a content based router, routes messages based on the content of the message.

Recipient list

  Sometimes you want to send a message to multiple channels at the same time. A recipient list provides in this.

Transformer

  A transformer is used when the format of the message needs to be changed before it can be sent to a recipient or when a standard format is defined.
Message endpoint  A message endpoint defines a connection from an application to a messaging channel.

 

Now let’s see how these patterns work together to solve the request part of our insurance website. We won’t show all the front-end stuff, but we’ll start with a insurance request that is received from the EasyInsurance website.

  1. The first thing we see is that the website uses a “message endpoint” to send a message to a specific channel (a JMS queue in this case) which is managed by a broker.
  2. This queue is then read by the ESB using a JMS “channel adapter”.
  3. The message is now routed internally by the ESB. The first router is the “content based router” which picks up the message and based on the type of request, car or travel, routes it to the next component.
  4. If the message needs to be sent to multiple insurance companies a recipient list is used and before the message is actually sent it’s first transformed to the target message format using a “transformer”.
  5. The “transformer” has made sure that the message is in a format the recipient can work with, so now all that is left to do is use another “channel adaptor” to send the message to a “message channel”, and the insurance companies can use a “message endpoint” on their side to read the request from the “message channel”.

Besides the use of the Enterprise Integration Patterns, the request flow of figure 6 also shows a clear separation between the different logical boundaries of the integration solution. Of course the ESB is shown as a logical boundary, but also the message broker (the JMS provider), the website and the endpoints of the insurance companies are separated in different boundaries. Also notice that figure 6 only shows the request flow of the insurance case study solution. To keep the design clean and comprehensible it’s often better to separate the request and response flows in different design diagrams. Figure 7 shows the response of the insurance broker integration solution.

Figure 7 This figure shows the response flow of the insurance integration solution described using enterprise integration patterns from the EIP book.

The design diagram of the response flow shown in figure 7 contains a lot of the patterns that were already used in the design of the request flow, only the aggregator pattern is new here. The aggregator is used to combine the insurance response messages from the BudgetCar and LuxuryCar insurance companies into one response that can be shown on the EasyInsurance website. To be able to aggregate the response messages from the two car insurance companies, we need some kind of correlation identifier that relates that response messages to the original insurance request message. In this example we use a request identifier in the insurance request message that is also available in the insurance response message.

This introduces another important step in the design phase of an integration solution: the message design. Because Mule can also use Java objects as message payload type, we will use Java based messages to communicate between the EasyInsurance website and the JMS broker and Enterprise Service Bus. In listing 6 the elements of the 3 message types involved in this integration solution are shown.

Listing 6 An overview of the Java classes that represents the insurance requests and response messages used in the integration broker implementation.

public class CarInsuranceRequest implements Serializable {

private String requestID;
private String numberPlate;
private String carType;
private int buildYear;
private boolean companyCar;
private Date startDate;
}

public class TravelInsuranceRequest implements Serializable {

private String requestID;
private String destinationCountry;
private int numberOfPersons;
private Date startDate;
private Date endDate;
}

public class InsuranceResponse implements Serializable {
private String requestID;
private String responseID;
private String insuranceCompanyName;
private float price;
}

As can be seen in listing 6, the messages are kept really simple for this example. The important parts of the message design for the integration solution are the distinction between a CarInsuranceRequest and a TravelInsuranceRequest that’s used for content-based routing and the requestID attribute that will be used for aggregating the car insurance response messages.

Notice that so far we haven’t talked about specific tools yet. In the design we made we just described what needs to be done. We can now hand over the integration flow and message design to a developer or integration specialist who can implement it using a specific technology. In this article we’ll implement it ourselves and we’ll use ServiceMix 3.2.1 for this.

Published at DZone with permission of its author, OpenSource ESB.

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)