Posted on by & filed under Content - Highlights and Reviews, Programming & Development.

Camel provides a powerful framework for enterprise application integration. Databases are a vital part of any enterprise application, and therefore it’s mandatory for any integration framework to offer first-class database support, which includes connecting with various data sources and accessing data. There are several ways you can achieve this in Camel, and in this post you will see how the JDBC component – one of the most commonly used components for database access in Camel – may be used.

JDBC is nothing new. It’s part of standard Java and provides an abstraction over the actual database being used. In this way, it enables any database to be plugged into your enterprise application without the need to take care of appropriate connection drivers. Read Chapter 7.6. Working with databases (JDBC and JPA components) in Camel in Action for more details on JDBC with Camel.

You will first need to add the camel-jdbc module in your project:

In order to use the component, you must specify the URI that has the following options to configure the JDBC component:

  • Readsize – The maximum number of rows you want to be returned. The default is 0, which will cause Readsize to be unbounded.
  • Statement.propertyname – Set property with the name propertyname in the underlying java.sql.statement. The default is null.
  • useJDBC4ColumnNameAndLabelSemantics – Configure the column and table semantics to use; it defaults to JDBC 4 style.

Once the JDBC component is configured, you will be able to specify SQL statements to execute. Before going into that, however, we need to specify the data source in the endpoint URI: jdbc:dataSourceName[?options].

Instead of simply sending off the message, the JDBC component treats the message as a command. In our case, this would be an SQL query to fetch records matching the criteria specified in the query. In the Enterprise Integration Pattern (EIP) language, this sort of message is called a command message. This means that you can’t use the JDBC endpoint as a consumer because it is expecting a command, not a message. The result of the SQL query would be packaged as an outgoing message on the exchange.

Let’s consider an example of a small ordering system. Whenever an order is placed, the accounting department can’t directly access the data within the order, it can only fetch this data from the database. Once the order is placed on the JMS queue, a bean will convert the order into an SQL command message and then pass it along to the JDBC component, which will then fetch the data from the configured data source and return with the results. The following figure illustrates this scenario:

camel

In the second stage, we’re using a bean to convert an incoming order into an SQL command message. You can achieve the same result by using DSL directly, but writing a custom bean gives you a lot more control. The route for the above illustrated scenario would be:

First, you specify the source, then the bean that does the conversion to an SQL command message, and finally the data source. Let’s consider that the SQL conversion bean received the following message body:

Once this goes through the bean, it will come out as the following SQL query:

JDBC components provide raw access to the database, which is invaluable for any enterprise integration scenario. You can learn more about Camel and enterprise integration patterns in books found in Safari Books Online below.

Safari Books Online has the content you need

Camel in Action is a Camel tutorial full of small examples showing how to work with the integration patterns. It starts with core concepts like sending, receiving, routing, and transforming data. It then shows you the entire lifecycle and goes into depth on how to test, deal with errors, scale, deploy, and even monitor your app — details you can find only in the Camel code itself.
Enterprise Integration Patterns: Designing, Building, and Deploying Messaging Solutions provides a consistent vocabulary and visual notation framework to describe large-scale integration solutions across many technologies. It also explores in detail the advantages and limitations of asynchronous messaging architectures. The authors present practical advice on designing code that connects an application to a messaging system, and provide extensive information to help you determine when to send a message, how to route it to the proper destination, and how to monitor the health of a messaging system.
In Service-Oriented Architecture: An Integration Blueprint begins by covering fundamental integration for those less familiar with the concepts and terminology, and then dives deep into explaining the different architecture variants and the future of integration technologies. Base technologies like JCA and SCA will be explored along the way, and the structure of the Trivadis Integration Architecture Blueprint will be described in detail, as will the intricacies of each component and layer. Other content includes discovering and comparing traditional and modern SOA driven integration solutions, implementing transaction strategies and process modeling, and getting to grips with EDA developments in SOA.

About the author

Salman Ul Haq is a techpreneur, co-founder and CEO of TunaCode, Inc., a startup that delivers GPU-accelerated computing solutions to time-critical application domains. He holds a degree is Computer Systems Engineering. His current focus is on delivering the right solution for cloud security. He can be reached at salman@tunacode.com.

Tags: Abstraction, Camel, databases, enterprise integration patterns, java, JDBC, SQL command, URI,

Comments are closed.