Since we're on a major migration process of this website, some component documents here are out of sync right now. In the meantime you may want to look at the asciidoc in the repository:


The purpose of this tutorial is not at all to teach you on SOA but to draw your attention on points that the developer(s)/deployer(s) will be confronted during the design/development and release management phases.

Designing a Service Oriented Architecture seems very obvious for most of us but implies that different parameters are taken into account :

  • Identification of the layers of the application,
  • Definition of the services,
  • Granularity (what are the boundaries of a service, ...),
  • Dependency with libraries,
  • Testing and debugging strategies,
  • Deployment procedure,
  • Infrastructure

Some of the points mentioned are particular to SOA world like granularity and definition of service boundaries but others are mostly found in all IT projects. This is really important to keep them in your head because they will impact the project life cycle, quality of the deliverable, efficiency of the team and project duration/cost.

In this second part of the tutorial we will investigate some of the points mentioned and applied them to a real application. The application will be designed around different components (= bundles in the OSGI jargon) and deployed into Apache Felix Karaf (now part of Apache ServiceMix 4).

Apache Karaf is a small OSGi based runtime which provides a lightweight container onto which various components and applications can be deployed.

Here is a short list of features supported by the Karaf:

  • Hot deployment: Karaf supports hot deployment of OSGi bundles by monitoring jar files inside the home/deploy directory. Each time a jar is copied in this folder, it will be installed inside the runtime. You can then update or delete it and changes will be handled automatically. In addition, the Karaf also supports exploded bundles and custom deployers (blueprint and spring ones are included by default).
  • Dynamic configuration: Services are usually configured through the ConfigurationAdmin OSGi service. Such configuration can be defined in Karaf using property files inside the home/etc directory. These configurations are monitored and changes on the properties files will be propagated to the services.
  • Logging System: using a centralized logging back end supported by Log4J, Karaf supports a number of different APIs (JDK 1.4, JCL, SLF4J, Avalon, Tomcat, OSGi)
  • Provisioning: Provisioning of libraries or applications can be done through a number of different ways, by which they will be downloaded locally, installed and started.
  • Native OS integration: Karaf can be integrated into your own Operating System as a service so that the lifecycle will be bound to your Operating System.
  • Extensible Shell console: Karaf features a nice text console where you can manage the services, install new applications or libraries and manage their state. This shell is easily extensible by deploying new commands dynamically along with new features or applications.
  • Remote access: use any SSH client to connect to Karaf and issue commands in the console
  • Security framework based on JAAS
  • Managing instances: Karaf provides simple commands for managing multiple instances. You can easily create, delete, start and stop instances of Karaf through the console.
  • Supports the latest OSGi 4.2 containers: Apache Felix Framework 2.0.0 and Eclipse Equinox 3.5

Here is a picture of the report incident application that this tutorial will cover :

To summarize, the application is listening for incidents coming from web service or files. According to the origin, the content (= incidents) are transformed into their corresponding objects using for the CSV file, a new camel component : camel-bindy and for the Web Service camel-cxf component. Each message transformed is placed in a queue handled by ActiveMQ engine. All the messages (containing the objects) are next processed by a Bean service who will (with the help of injection of dependency provided by Spring) save the incidents in a DB using Spring and Hibernate frameworks.
A small Apache Wicket web application running in Jetty Web server provide to the users a screen to consult the incidents created.

Remark : A bundle in the OSGI world represents component made by developer. For more info about OSGI, I recommend to have a look on OSGI web site

The project has been cut into the following components :

Maven project name = artifactId


Is it a bundle ?


configuration file of the ActiveMQ engine



configuration file of the camel-activemq component



generator of the script DB



features provisioning file containing our bundles dependencies



model layer



hibernate persistence layer; bundle



camel routing



spring service layer



apache wicket module



CXF web service generator


As you can see, some are considered as OSGI bundles and others no. An important point to mention here concerns the granularity : each layer of our application will be deployed as separate bundle. This will facilitate the maintenance and release management. Of course, you can argue that the granularity is too small. SOA is not an exact science and depending of the size of the application, the team in charge to develop, release management procedure this cutting will be redefined. You can imagine that the parameters used to configure Hibernate and Spring are bundles together instead inside the persistence project. Service bundle could be split into several bundles; one by service type, ... There are no rules of thumb except that the project must be manageable and maintainable.


This tutorial uses:

Note: The sample project can be downloaded, see the resources section.

Step 1 : Initial Project Setup

Different way exist to create maven project. For the basic project like db, we have used the archetype 'simple' with the command followed by mvn eclipse:eclipse in the folder created :

For the OSGI bundles, different approaches are available depending on the tools that you prefer to use :

But for the purpose of this tutorial, we have used the PAX maven plugin. Why this choice, simply because PAX maven plugin offers a lot of advantages regarding to the one of Spring :

  • pom.xml file generated is very simple to use and to understand,
  • project can be designed with several modules,
  • project can be tested with PAX Exam and launched using PAX runner
  • generate all the folders required including also the META-INF,
  • manifest file is generated automatically,
  • can be imported easily in Eclipse

To create the tutorial projects, you can follow the procedure described here

1) Execute maven command in your Unix/Dos console :

2) Move to the folder created and execute the following command :

2) Import the generated eclipse project in Eclipse workspace
3) Delete non required files like readme.txt and the folders internal + java class created
4) Enable dependency management (see sonatype site).

Repeat this procedure for the projects :

  • reportincident.activemq
  • reportincident.camelqueueservice
  • reportincident.persistence
  • reportincident.routing
  • reportincident.service
  • reportincident.web
  • reportincident.webservice

otherwise import the content of the unzipped file in your workspace. You will gain time.

Step 2 : Develop model layer

It is time now to begin serious things. One of the most important part of a project (if not the most important) concerns the design of the model.
The reportincident model is really simple because it only contains one class that we will use :

  • to map information with the database, CSV file,
  • to transport information to web screens.

Here is the definition of the incident class that you can create in the reportincident.model project directory src/main/java/org/apache/camel/example/reportincident/model or use the code imported

Step 3 : Map model layer with CSV file (camel-bindy)

To facilitate the work of the modeler, we will use the incident class not only to persist the information in the database but also to read or generate Comma Separate Value file (CSV). To map the content of the class with a CSV file, we have used a new Camel component : camel-bindy. Like its name suggests, camel-bindy is a binding framework (similar to JAXB2) to map non structured information with Java class using annotations. The current version supports CSV fields and key-value pairs (e.g. Financial FIX messages) but will be extended in the future to support Fixed Length format, ....

So, we will modify our existing class to add @Annotations required to map its content. This is very trivial to do and will be done in two steps :

1) Add CSVRecord annotation

This annotation will help camel-bindy to discover what is the parent class of the model and which separator is used to separate the fields. If required, you can also use the property 'skipFirstLine' to skip the first line of your CSV file

2) Add DataFields annotations

For each of the CSV field that you want to bind with your model, you must add the @DataField annotation with its position. This is not the only property available and you can also add 'pattern' property to by example define the pattern of your Date field.

To build the project, simply execute the following maven command in the reportincident.model project

Step 4 : Map model layer with DB (Hibernate)

To map our model with the database, we will use the ORM framework Hibernate. Annotation can also be used since the last version of Hibernate but to avoid to overload our class and reduce its readability, we will use the old way using a XML file describing the mapping between the model and the database.

Remark : The ORM uses to persist the information is Hibernate but it can be changed to another existing like iBatis, Apache OpenJPA, ...

Remark : This file Incident.hbm.xml must be created in the directory src\main\resources\META-INF\org\apache\camel\example\reportincident\model\Incident.hbm.xml of the project reportincident.model.

Step 6 : Database creation

To create the database, we will use hibernate maven plugin file. The plugin will use the following configuration file to generate the SQL script and create table T_Incident.

Remark : MySQL has been used for the purpose of the tutorial

Here is the content of the hibernate.cfg.xml that you must create in the folder src/config of hibernate.db

The pom.xml file of your reportincident.db project must be modified like this :

Remarks :
(1) - Dependency with reportincident.model project must be added because the plugin requires the file Incident.hbm.xml to generate the script/db
(2) - If you prefer to use another DB instead of MySql, change the dependency in the pom.xml and hibernate.connection.driver_class and hibernate.connection.url in the cfg file

To create the table + SQL script, simply launch

command in the folder of reportincident.db

Step 7 : Add persistence layer and Spring service

Now that the model/db exist, we will create the persistence and layer services. The projects have been designed using the pattern Data Access Object because it allows to change the implementation from a database type to another, between ORM very easily. Moreover interfaces are used as 'contract' between the services and the DAO. This offers the advantage to decouple objects in the application and as you will see later on it will allow us to deploy services, persistence as separate bundles in the OSGI server.

Persistence project

First, we will create the interface declaring the methods that we would like to provide/expose. Create in the folder src/main/java/org/apache/camel/example/reportincident/dao, the java class "IncidentDAO" with the following code :

There is nothing particular to mention here as this class is a simple case of Create Read Update Delete implementation. The next class who implements the interface will provide the necessary code to connect to the database using Hibernate framework.

So, create the class IncidentDAOImpl in the directory src/main/java/org/apache/camel/example/reportincident/dao/impl

The most important point to mention here is that this class to connect to our database and to work with Hibernate needs to have a SessionFactory object. This object is not instantiated by a constructor's class but only declared as a property/field. This is where Spring will help us through its dependency injection.

The injection is defined in the file called spring-dao-beans.xml that you will create in the folder src/main/resources/META-INF/spring :

The sessionFactory object will be created with the help of Spring framework but in order to communicate with the database, information about the data source must be provided.

So realize this goal, you will create the file spring-datasource-beans.xml in the same folder directory with the following information :

This file is not complete but we will review later in the tutorial when we will cover specific OSGI stuffs and Spring transaction management. Now, we will design the Spring service part

Spring Service project

In term of design, the service project is very similar to the persistence because we will create an interface and its implementation. Why repeating the interface. The answer is evident; it is for decoupling the service from the DAO implentation to allow you to switch easily from one ORM to another, ...

Create the following interface IncidentService in the folder src/main/java/org/apache/camel/example/reportincident/service with the code :

and its implementation IncidentServiceImpl in the folder src/main/java/org/apache/camel/example/reportincident/service

The same remark as explained previously applies here concerning the DAO injection. So, you will create the following file spring-service-beans-dao.xml in the folder src/main/resources/META-INF/spring to inject the dependency of the DAO to our service.

Obviously, this file is not complete because the reference of the DAO class is not mentioned except the property name. Don't panic, we will come back later on when we will discuss Spring Blueprint services.

Step 8 : Webservice

This part has already been discussed in detail in the excellent tutorial : Report Incident - This tutorial introduces Camel steadily and is based on a real life integration problem. So we will only explain what we have done specifically for our project.

Compare to the other tutorial, we have packaged the code generated by the CXF framework in a project/bundle separated from the routing/mediation engine. This approach allows you to extend your web services (I mean the methods exposed) without impacting the rest of your application. The question concerning the model is mush more delicate because we have a dependency on the model created to persist information. In our case, we have separated the webservice model (where the fields available are all declared as string) from ours but you can considered to have the same when Types are compatible (e.g. Can I map the Date Time object of my webservice field to my model without any transformation ?).

To generate the code that our application will use, we will work with following WSDL contract report_incident.wsdl that you create in the directory src/main/resources/META-INF/wsdl:

The code will be generated thanks to a maven plugin : cxf-codegen-plugin.

Add the following line in your pom.xml of the project reportincident.webservice

The code is generated using the maven command :

Remark : the code is generated in the directory target/src/main/java


Everything is in place to integrate the services together except the routing and OSGI stuffs. This is what we will cover in the following sections.

It is time now to have a break, to make some sport exercices, to drink a cup of good 'Java' coffee or to go outside of the building to take a walk with your favorite pets.


© 2004-2015 The Apache Software Foundation.
Apache Camel, Camel, Apache, the Apache feather logo, and the Apache Camel project logo are trademarks of The Apache Software Foundation. All other marks mentioned may be trademarks or registered trademarks of their respective owners.
Graphic Design By Hiram