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 :
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:
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.
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 :
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
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 :
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
Repeat this procedure for the projects :
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.
Here is the definition of the incident class that you can create in the reportincident.model project directory
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
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
The pom.xml file of your reportincident.db project must be modified like this :
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.
First, we will create the interface declaring the methods that we would like to provide/expose. Create in the folder
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
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
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
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
and its implementation
The same remark as explained previously applies here concerning the DAO injection. So, you will create the following file
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
The code will be generated thanks to a maven plugin : cxf-codegen-plugin.
Add the following line in your
The code is generated using the maven command :
Remark : the code is generated in the directory
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.