• Created by Unknown User (julio_carlos_barrera), last modified on 27 Mar, 2013

OpenNaaS uses a pile of technologies and frameworks in order to make easier developing, maintaining and extending source code of the project. In this chapter these technologies are briefly summarized to explain how them are used.

OSGi

According to OSGi Alliance, OSGi technology "is a set of specifications that defines a dynamic component system for Java. These specifications reduce software complexity by providing a modular architecture for large-scale distributed systems as well as small, embedded applications".

Basically, OSGi framework is a module system and service platform for the Java programming language that implements a complete and dynamic component model. Those characteristics are not provided by Java Virtual Machine itself. OSGi provides a collection of benefits: Reduced Complexity, Reusability, Easy Deployment, Dynamic Updates, etc. and it is widely used.

The reasons for the adoption of this technology are multiple. For more information there are some slides to reinforce the basic concepts and motivation of using OSGi: Why OSGi?.

OSGi itself is only an specification. There are different versions of OSGi specification:

  • Service Gateway Release 1 (released in May 2000)
  • Service Platform Release 2 (released in October 2001)
  • Service Platform Release 3 (released in March 2003)
  • Service Platform Release 4 (released in October 2005)
    • 4.1 (released in May 2007)
    • 4.2 (Core and Compendium released in September 2009 and Enterprise released in March 2010)
    • 4.3 (Core released in April 2011, Compendium and Residential released in May 2012)
  • Release 5 (Core and Enterprise released in June 2012)
An implementation is needed to use this technology.

Architecture

OSGi has a layered model as it is shown in the next figure:

There are 4 stacked layers and a cross one:

  • Execution Environment
    Defines what methods and classes are available in a specific platform.
  • Modules
    Defines how a bundle can import and export code.
  • Life-Cycle
    The API to install, start, stop, update, and uninstall bundles.
  • Services
    Connects bundles in a dynamic way by offering a publish-find-bind model for plain old Java objects.
  • Security
    The cross layer that handles the security aspects.
More information can be found here.

Bundles

OSGi specification defines a new concept called bundle. A bundle is a plain old JAR file. The difference resides in the visibility of the packages inside the bundle: OSGi hides everything in that JAR unless explicitly exported. A bundle that wants to use another JAR must explicitly import the parts it needs. By default, there is no sharing. This information is added in the JAR manifest (/META-INF/MANIFEST.MF).

The manifest has some headers that can be used. Some of them are standard, and another ones are implementation-specific. A complete list can be found here. Basically, these headers define the exported and imported packages and other information about the bundle. An Apache Maven plugin is used to build bundles from source code (Apache Felix Bundle Plugin for Maven).

Life-cycle

Bundles have a life cycle inside OSGi. It is defined by a set of states and a rules to change between them. A bundle can be in one of the following states:

  • INSTALLED
    The bundle has been successfully installed.
  • RESOLVED
    All Java classes that the bundle needs are available. This state indicates that the bundle is either ready to be started or has stopped.
  • STARTING
    The bundle is being started.
  • ACTIVE
    The bundle has been successfully activated and is running.
  • STOPPING
    The bundle is being stopped.
  • UNINSTALLED
    The bundle has been uninstalled. It cannot move into another state.

This state diagram shows how the states can change between them:

Services

This layer allows registering services. A service is a Java interface and a bundle can implement this interface to provide the service. There exist a Service Registry that allows any bundle to register services, search for them or receive notifications when their registration state changes. This notifications are built using a register-event system. OSGi specification defines some standard services.

Implementations

OSGi is only an specification, an implementation is necessary to use this technology. There are different implementations, some of them open sourced. Apache Felix and Eclipse Equinox are the more commonly used. OpenNaaS uses Apache Felix.

Apache Felix

Apache Felix is an implementation of OSGi Service Platform Release 4. It is divided in a set of more than 30 subprojects as it is shown here. There are some tutorial examples in Apache Felix official documentation that show how to develop OSGi bundles using Apache Felix.

OpenNaaS uses Apache Felix as OSGi framework, it is configured in the Apache Karaf properties file using this guidelines.

Apache Karaf

Apache Karaf is an OSGi runtime which provides a container plus some other complementary tools. It is possible to choose the OSGi framework to use between Apache Felix or Eclipse Equinox; OpenNaaS uses Felix.

This figure shows Karaf's architecture: 

Karaf has lots of features that improve the experience developing on an OSGi container. Some of these features are:

  • 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, 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.

Console

One of the most powerful tools of Apache Karaf is the console. It provides an entry point to add, remove and configure bundles for instance. There are a bunch of available commands to interact with Karaf instance. Besides, the console functionalities can be extended.

In fact, OpenNaaS extends Karaf console to interact with their capabilities. Each OpenNaaS capability exports Karaf commands to be accessed through Karaf console. Some examples can be found in OpenNaaS source code, a good point to start is GenericKarafCommand, an abstract class that must be extended to create new OpenNaaS Karaf commands. An example of an OpenNaaS capability that uses this functionality is the Router Capability called IP and his SetIPv4 Command implemented in the Java class SetIPv4Command.

Moreover, this console can be accessed through SSH allowing a remote user to control an Apache Karaf instance.

Apache CXF

Apache CXF is a Web Services framework. It supports multiple Web Services standards, development tools. different transport layers, etc. OpenNaaS exports his API using this technology. By now, it is exported using RESTful WS. Besides, OpenNaaS has some SOAP clients developed to connect to some external services like GÉANT AutoBAHN.

There are documentation about how to develop RESTful Services in the Apache CXF official documentation. Furthermore there are documents to develop client in the same web page.

On one hand, OpenNaaS SOAP client example can be found in the Java class called AutobahnProtocolSession that interacts with GÉANT AutoBAHN service. On the other hand, an example of RESTful Web Service in OpenNaaS can be found in Router Capability called IP and his IPCapability interface IIPCapability.

Apache Aries

Apache Aries "consists of a set of pluggable Java components enabling an enterprise OSGi application programming model". It provides components  like Blueprint container and tools to integrate enterprise technologies like JTA, JNDI and JPA into an OSGi environment. In conclusion, it provides OSGi bundles to use these technologies inside an OSGI framework.

The persistence layer of OpenNaaS uses Apache Aries. Concretely OpenNaaS uses Apache OpenJPA as persistence provider. There are more information about it here.

Apache OpenJPA

Apache OpenJPA is a POJO persistence layer that can wrok standalone or integrated into any Java EE compliant container. Used inside Apache Aries, it is the persistence provider of OpenNaaS. More information about this technology an his usage can be found in the chapter Persistence.

Apache ServiceMix

Apache ServiceMix is an integration container that unifies the features and functionality of Apache ActiveMQ, Camel, CXF, ODE and Karaf into a runtime platform. It provides an ESB exclusively powered by OSGi."

Apache ServiceMix provides an easy way to develop and to integrate this set of technologies and OpenNaaS uses it.Some of these technologies are not used in OpenNaaS (Apache ActiveMQ, Camel and ODE), but Apache ServiceMix is flexible and allow not to use all of them.

Fuse ESB

Fuse ESB "is a flexible, standards-based enterprise service bus based on Apache ServiceMix". OpenNaaS uses Fuse ESB as a distribution of Apache ServiceMix. In practice, OpenNaaS uses a version of Apache ServiceMix that is released by FuseSource called Fuse ESB. They guarantee stability,  Quality Assurance, packaging, verification and incremental patches of their Apache ServiceMix distribution. Moreover FuseSource offers training, support and other value-added services. More information can be found here.

FuseSource has a great documentation, not only related with their products like Fuse ESB. It can be found here.

Apache Maven

According to official documentation, Apache Maven "is a software project management and comprehension tool. Based on the concept of a project object model (POM), Maven can manage a project's build, reporting and documentation from a central piece of information".

The use of Maven gives a development team and users many advantages to develop, build, extend, manage a project or a bunch of them. Furthermore, it can be configured to use plugins allowing extensions to the basic functionalities of the tool.

Basically, a POM file defines the project, its internal or external dependencies, manage the repositories to obtain these dependencies and defines goals to build the project. Also its allows to perform other tasks like generating documentation, deploying project builds into different servers or places or generating project skeletons based on archetypes.

Maven requires Java to work. This quickly guide shows how to get started using Maven.

  • No labels