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: https://github.com/apache/camel/blob/master/README.md https://github.com/apache/camel/blob/master/components/readme.adoc
The focus of this Tutorial is to introduce you how you can create, design a simple SOA solution using Camel and OSGI. Most of the current and commercial SOA solutions rely on standards XML/WSDL/BPMN/BPEL and Business Processes (designed through WYSIWYG editor like Eclipse or propriatary product) which are deployed and orchestrated into a Business Process Expression Language engine.
Such a solution can be envisaged for big companies because the skills/time to market are important or when different development standards exist inside the company like (Java, .NET).
In the 90's, such developments have been made using CORBA or COM+/DCOM Microsoft technology. But both approaches had (and still have) significant problems and limitations. Complexity is a big issue. Any of the data that is passed requires very specific formatting, and many of the rules for programming are simply too difficult to follow without encountering errors. Even at the height of their popularity, CORBA was used primarily in large system development staffed by legions of programmers, while COM was used, often reluctantly, by teams of Microsoft developers.
Open Standards Gateway Initiative provides a Java-based platform for integrating both Java and non-Java application components. This technology provides the standardized functions for constructing applications from small, individual components and deploying them as a single application. The core component of OSGi is the OSGi Framework. The OSGi Framework is a very specific class-loading model. In addition to its normal Java execution environment, this framework incorporates an OSGi modules layer that adds private classes for modules and allows for controlled linking between modules. The OSGi Framework also includes life-cycle management for starting, stopping, adding and removing modules, as well as a service registry for sharing objects between modules.
Coupling the OSGI framework with a lightweight Enterprise Service Bus will allow you easily to design the routing between your different modules. A module can be a Plain Old Java Object (POJO), a Web Service designed with Apache CXF framework, a component like an ordering system. In fact, the module or bundle which is the term used by OSGI represent the level of granularity that you identify for your application.
In this first part of the OSGI tutorial, we will show you how to:
Tutorial is not up-to-date
This tutorial was written when Camel 2.0 was just released and uses the frameworks and libraries of that time.
This tutorial uses:
Note: The sample project can be downloaded, see the resources section.
Step 1 : Initial Project Setup
First, we create two eclipse projects using the maven archetype 'pax:create-bundle'. This archetype is helpful because it generates a pom.xml file that we will use with maven goal(s) to create the:
More info about the PAX maven plugin can be found here. PAX project does not include only maven but also tools to run, debug and deploy web application. We will address them in the second part of the tutorial and particularly the web integration
To create the simple service project, execute the following command in your Unix/Dos console.
To allow your project to be imported in Eclipse, execute the following command in the directory demo.service-bundle.
To create the Camel project, execute the following command
Two folders are created with the following name:
Next, you import these projects into your favorite workspace of Eclipse.
Step 2 : Develop the interface
Developing an OSGI project could be 'potentially' time consuming regarding to:
You could figure out that developing OSGI is similar to develop EJB components using EJB 1.0 specification. Remember that time when the only way to design an enterprise solution was to use EJB with its proxy, stub-skeleton classes, the protocol RMI/IIOP (blocked by most of the firewall) for the communication between the client and the server, ... and so on and so on
Luckily, this is not the case because the specification has tried to avoid such pitfalls and interesting projects exist today to simplify our life:
The goals of these frameworks are to:
Although this tutorial is based on Spring Dynamic Modules.
Remark : The OSGI specification v4R2 has been published recently and contain the Blueprint Container specification - RFC 124.
So now, it is time to create the interface that we will use in this project. Open Eclipse environment if not already done and create a new folder "service" in
Step 3 : Create the class implementing the interface
Next, we will create the class
Step 4 : Create the spring configuration files
The next step concerns the creation of the configuration files who will allow to inject dependency and later the deployment of the bundle into the OSGI server and its registration as a 'service'.
a) Dependency Injection
Create the file
b) OSGI 'Injection'
Create the file
The xml tag osgi:service will help to register our OSGI service top of the OSGI server and will publish the interfaces as available for another bundles who would like to use them.
Spring configuration files
Two XML files have been created to work with Spring beans and Spring OSGI beans separately (as proposed by spring - section D.1 Generated Project Features at-a-glance) but you can also merge the content in one file.
Step 5 : Generate the jar of the bundle
Now, that the code and the configuration files are ready, we will use maven to generate the
Remark : We use maven to avoid to create manually the MANIFEST file.
Before to execute the command, the pom.xml file must be modified like this :
This command can be launched from Eclipse (if you have integrated maven within Eclipse (eclipse maven plugin)) or a Unix/Dos prompt in the folder where your pom.xml file is located:
If this command does not report any error, then a 'MANIFEST.MF' file containing the following information is created in the folder 'META-INF' and
Step 6 : Create the Camel context file and OSGI dependency
The next step is quite simple for Camel users because we will create two configurations files, one containing the routing and the other with a reference to our TransformationService deployed in a OSGI bundle.
The routing defined here is a timer which will trigger every 10th second and call the POJO 'MyTransform' and send the result to the 'camel:log' component. As, you can see, this is a pure Camel configuration file without any reference to an OSGI bundle
Step 7 : Generate the manifest and jar file
Prior to run/launch the command generating the MANIFEST file, you must modify the pom.xml file in order to allow the OSGI bundle to import/use the services classes : demo.service
Run the command
and check that the MANIFEST file created looks like the following :
The most important point that we see in this file is that we will import the package demo.service allowing Camel mediation router to have access to the service Transform exposed as an OSGI service by the bundle demo.service.
Step 8 : Deploy the bundles
We will show you now that we can easily deploy our bundles in two OSGI servers running a different OSGI kernel:
Apache Felix Karaf
As mentioned in the documentation, Apache Felix Karaf is a small OSGi based runtime which provides a lightweight container onto which various components and applications can be deployed. Moreover, the server provides administration, security, logging and provisioning features who will help you during the deployment and administration steps.
Here is the list of features provided by the osgi server :
If this is not yet done, download Apache Felix Karaf 1.0.0 server and install it. Launch the server by executing the command in the
If this is the first time that Karaf is started, then you will see that a new data folder is created under the root folder. This folder will contain the bundles installed at the startup of the server
In order to allow our bundles (demo.service and demo.camel) to work with Apache Camel framework, execute the following commands to download and install the 'Camel and Spring bundles':
1. Add camel feature file
This new feature file contains the list of camel bundles to be installed. This will avoid that you install each required bundle (= jar) separately though the command osgi:install
2. Install bundles using feature command
Verify that your list of bundles is complete using command osgi:list
Next, copy the our two jar into the
install them using the command :
After a few seconds, you should see on the Karaf log console the following text:
Spring DM server
Spring DM server compare to ServiceMix Kernel, Eclipse Equinox or Apache Felix is much more than a OSGI server. This is a completely module-based Java application server that is designed to run enterprise Java applications and Spring-powered applications with a new degree of flexibility and reliability. It offers a simple yet comprehensive platform to develop, deploy, and service enterprise Java applications.
We have decided to it inside this tutorial not only because we have designed spring-based applications but because we are convince that OSGI platform will become the next standard for the Web Application Server. Existing Commercial and open-source are gradually migrating their servers to support OSGI.
Like ServiceMix Kernel, start the Spring DM server by launching the following command in your Unix/Dos environement :
When the server is started, open your favorite browser and point to the following url
When the bundles are uploaded, the screen is refreshed and shows a list of the deployed applications like this :
To verify that the Camel service bundle works perfectly, open the trace.log file located in the folder :
and you should see the following text
Well, we have finished the first part of the tutorial. Even if the example is simple, we have introduced very important concepts and show you how to design a small SOA solution, package it and deploy it under two different OSGI servers. I'm really sure that in a near future a maven plugin will be created to facilitate this task and will automate the deployment within your favorite OSGI servers.