You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 20 Next »

Introduction

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 ServiceMix Kernel. ServiceMix Kernel or SMXKNL is an OSGI platform created top of Apache Felix OSGI server, integrating Spring Dynamic Modules to facilitate the build of Spring application and PAX components who provide tools managing deployment of component and web support.

For more information about the projects/frameworks mentioned, I recommend that you have a look on their respective web site.

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 an 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

Description

Is it a bundle ?

reportincident.activemq

configuration file of the ActiveMQ engine

yes

reportincident.camelqueueservice

configuration file of the camel-activemq component

yes

reportincident.db

generator of the script DB

no

reportincident.features

features provisioning file containing our bundles dependencies

no

reportincident.model

model layer

yes

reportincident.persistence

hibernate persistence layer; bundle

yes

reportincident.routing

camel routing

yes

reportincident.service

spring service layer

yes

reportincident.web

apache wicket module

yes

reportincident.webservice

CXF web service generator

yes

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

Prerequisites

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 : mvn archetype:create -DartifactId=simple ...

Remark :

  • don't forget to run the command mvn eclipse:eclipse inside the folder created

For the OSGI bundles different approaches are available :

  • Spring archetype : mvn archetype:create -DarchetypeGroupId=org.springframework.osgi -DarchetypeArtifactId=spring-osgi-bundle-archetype ...
  • PAX archetype : mvn org.ops4j:maven-pax-plugin:create-bundle ...

but for the purpose of this tutorial, the spring archetype has been used because it allows to create :

  • all the folders required including also the MANIFEST,
  • Eclipse files
    in one step.

So, we will create the 10 maven projects using names defined in the table with the maven archetype 'simple'.

To create the projects, execute the following command in your Unix/Dos console.

mvn archetype:create -DarchetypeGroupId=org.springframework.osgi -DarchetypeArtifactId=spring-osgi-bundle-archetype -DarchetypeVersion=1.2.0 -DgroupId=org.apache.camel.example -DartifactId=reportincident.model -Dversion=1.0-SNAPSHOT

Import them into eclipse and enable dependency management (see sonatype site). You should see the following projects with a small M letter top of the project folder :

Step 2 : Develop the interface

#Resources

  • No labels