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
| 81857 views |
  • submit to reddit

Implement the insurance broker with ServiceMix: the response part

As said, we already defined most of the insurance broker example configuration. Let’s first look at the remaining pieces of the response part as part of a SA diagram in figure 9.

Figure 9 An overview of the SA and SUs for the response part of the insurance broker example.

We already defined the CXF provider and pipeline configuration of the travel webservice invocation. So the only part we have to discuss for the response part is the aggregator implementation. Let’s look at the aggregator configuration in listing 15.

Listing 15 The definition of the aggregator, which aggregates two car insurance response messages in one result message.

<beans xmlns:eip="http://servicemix.apache.org/eip/1.0"
xmlns:esb="http://esbinaction.com/insurance"
xmlns:tri="http://dzone.com/travelInsurance">

<eip:split-aggregator service="esb:insuranceAggregator" endpoint="routingEndpoint">
<eip:target>
<eip:exchange-target service="esb:insuranceSender" />
</eip:target>
</eip:split-aggregator>
</beans>

This is not too difficult, isn’t it? We define the aggregator JBI service endpoint name and the target service where the aggregated message is sent. To be able to use the out-of-the-box aggregation functionality of the EIP aggregator we do have to define some message properties, such as a correlation identifier and the number of messages to be aggregated. In the JMS and file marshalers we discussed in listing 8 and 11 we can add these message properties. In listing 16 the implementation of the file marshaler is shown.

Listing 16. Overview of the file marshaler read method which adds aggregation message properties.

public class InsuranceFileMarshaler extends DefaultFileMarshaler {

public static final String FILE_NAME_PROPERTY = "org.apache.servicemix.file.name";
public static final String FILE_PATH_PROPERTY = "org.apache.servicemix.file.path";

public void readMessage(MessageExchange exchange, NormalizedMessage message,
InputStream in, String path) throws IOException, JBIException {

BufferedReader br = new BufferedReader(new InputStreamReader(in));
StringBuilder sb = new StringBuilder();
String line = null;
while ((line = br.readLine()) != null) {
sb.append(line);
}
br.close();
String csvString = sb.toString();
String[] elements = csvString.split(",");
InsuranceResponse insuranceResponse = new InsuranceResponse();
insuranceResponse.setResponseID(elements[0]);
insuranceResponse.setRequestID(elements[1]);
insuranceResponse.setInsuranceCompanyName(elements[2]);
insuranceResponse.setPrice(Float.parseFloat(elements[3]));
Source source = null;
try {
source = JiBXUtil.marshalDocument(insuranceResponse, "UTF-8");
} catch(Exception e) {
throw new JBIException(e);
}
message.setContent(source);
message.setProperty(FILE_NAME_PROPERTY, new File(path).getName());
message.setProperty(FILE_PATH_PROPERTY, path);
message.setProperty("org.apache.servicemix.eip.splitter.corrid",
insuranceResponse.getRequestID());
message.setProperty("org.apache.servicemix.eip.splitter.index", 0);
message.setProperty("org.apache.servicemix.eip.splitter.count", new Integer(2));
}
}

As shown in listing 16, the file poller first transforms the CSV message to an InsuranceResponse Java object. Then the InsuranceResponse object is transformed to an XML message with JiBX. Before the XML message is sent further on in the ServiceMix container, we add the EIP aggregator message properties. The first property is the correlation identifier, then the message index number and the number of messages to be aggregated. In the JMS marshaler we implemented similar functionality, but the index message property is set to 1.

And that’s it for the response part!

Test the insurance broker with ServiceMix

To really grasp the ServiceMix configurations shown in the insurance broker example, you can use the source code to get the example to run. We provided an Ant build script, build.xml, to make it a little bit easier for you. With the start target you can start the ServiceMix container and with the deploy-insurance target you can deploy the complete insurance broker service assembly to the ServiceMix container.

Then you can use the InsuranceTest JUnit test to send a JMS message to trigger the insurance broker message flow. With the LuxuryCarTest JUnit test you can sent the luxury car response message and there is a response.csv file available in the file SU directory to send a response for the budget car insurance company. The InsuranceTest also includes code to simulate the travel web service.

Conclusion

In this article we’ve shown how you can implement an integration case study with ServiceMix. There are quite a bit of differences between the Mule and ServiceMix insurance broker case study implementations as you can see, but the configuration also has some similarities. Both Mule and ServiceMix use Spring extensively to configure the integration logic and both ESBs use an XML based configuration style.

The main differences are related to JBI foundation of ServiceMix and the Mule specific architecture of Mule. JBI uses SUs and SAs and Mule defines everything as part of a mule-config.xml file. Another difference is the use of XML messages or normalized messages within ServiceMix (according to the JBI specification) and Java objects within Mule. Mule accepts Java objects as message payload, but ServiceMix requires the use of an XML payload. A third difference is the hotdeploy feature of ServiceMix that’s lacking in the Mule implementation. With ServiceMix you can easily deploy new versions of a SA, while ServiceMix keeps running. With Mule you will have to restart the container, before a new Mule configuration can be loaded.

We hope you enjoyed this introduction into ServiceMix 3.2.1 and the pattern based integration development approach. We hope we were able to show the functionality of Mule and ServiceMix with a small case study.

Additional resources

1. ServiceMix – http://servicemix.apache.org
2. ServiceMix 4 – http://servicemix.apache.org/SMX4/index.html
3. Enterprise Integration Patterns – http://www.enterpriseintegrationpatterns.com
4. Apache Camel – http://activemq.apache.org/camel
5. Download article source code – http://www.esbinaction.com/files/dzoneservicemix.zip


Jos Dirksen

Jos is a software architect working for Atos Origin and specializing in enterprise integration. Jos is the co-author of the upcoming Manning book “Open Source ESBs in Action” (http://www.manning.com/rademakers). He speaks frequently at Java conferences like JavaPolis, JavaZone, JavaOne and NL-JUG about Open Source enterprise integration projects like Mule, ServiceMix, jBPM and Axis2.

Tijs Rademakers

Tijs is a software architect working for Atos Origin and specializing in enterprise integration. Tijs is the co-author of the upcoming Manning book “Open Source ESBs in Action” (http://www.manning.com/rademakers). He speaks frequently at Java conferences like JavaPolis, JavaZone, JavaOne and NL-JUG about Open Source enterprise integration projects like Mule, ServiceMix, Apache Synapse and Apache Tuscany.

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.)