R-OSGi and Distributed OSGi: differences and similarities

ECF Eclipse Communication Framework is a framework for supporting the development of distributed Eclipse-based tools and applications. It can be used to create other plugins, tools, or full Eclipse RCP applications that require asynchronous point-to-point or publish-and-subscribe messaging.

Equinox Aspect: Example from Martin Lippert

Martin Lippert is a senior consultant and coach at akquinet it-agile GmbH. His main work and research focuses on Agile Software Development, Refactoring, Eclipse-Technology, OSGi, Spring and Aspect-Oriented Programming.

Martin posts, in your blog, a Code Examples from “Aspect Weaving for OSGi” Talk.

The code example is divided in:

• Eclipse Monitor Demo
• Dependency Injection with Spring Dynamic Modules and Equinox Aspects

Neil Bartlett meet Michael Coté (RedMonk): e4, Equinox, OSGi and Android

MIchael Cotè an industry analyst with RedMonk interview Neil Barlett on e4, Equinox, OSGi and Android.

Neil Bartlett is a good, maybe but certainly an expert, of OSGi. I have learn alot throught Neil’s Blog; Getting started with OSGi and OSGi Book.

After letting it rest way to long, I finally got around to editing and publishing this short video with Neil Bartlett
from EclipseCon 2008. As the title implies, we talk about the next major version of Eclipse, “e4,” get into a discussion about the Equinox, and wrap up talking about Neil and other’s work on getting OSGi running on Android.

iPOJO library: Declarative Services alternative

iPOJO aims to simplify service-oriented programming on OSGi frameworks; the name iPOJO is an abbreviation for injected POJO. iPOJO provides a new way to develop OSGi service components with the main goal being to simplify service component implementation by transparently managing the dynamics of the environment as well as other non-functional requirements. The iPOJO framework allows developers to more clearly separate functional code (i.e., the POJO) from the non-functional code (i.e., dependecy management, service provision, configuration, etc.). iPOJO combines the functional and non-functional aspects at run time. To achieve this, iPOJO provides a simple and extensible service component model based on POJOs.

iPOJO strength points are :

• components are developed as POJO
• the component model is extensible, you can easily add non-functional properties
• the standard component model manages service providing, service dependencies, dynamic reconfiguration …
• iPOJO manage the component lifecycle and the environment dynamics

A component is implemented in Java in a “POJO” class. This class does not have any links on OSGi. All requirements, as service dependencies, will be injected at runtime when needed.

OSGi and AspectJ into Equinox Aspects

In software engineering, the programming paradigms of aspect-oriented programming (AOP), and aspect-oriented software development (AOSD) attempt to aid programmers in the separation of concerns, specifically cross-cutting concerns, as an advance in modularization. AOP does so using primarily language changes, while AOSD uses a combination of language, environment, and method.

Separation of concerns entails breaking down a program into distinct parts that overlap in functionality as little as possible. All programming methodologies—including procedural programming and object-oriented programming—support some separation and encapsulation of concerns (or any area of interest or focus) into single entities. For example, procedures, packages, classes, and methods all help programmers encapsulate concerns into single entities. But some concerns defy these forms of encapsulation. Software engineers call these crosscutting concerns, because they “cut” across multiple modules in a program.

Pros and Cons of Plugin Systems

A plug-in (plugin, addin, add-in, addon, add-on or snap-in; but see extension) is a computer program that interacts with a host application (a web browser or an email client, for example) to provide a certain, usually very specific, function “on demand”. Applications support plugins for many reasons. Some of the main reasons include: enabling third-party developers to create capabilities to extend an application, to support features yet unforeseen, to reduce the size of an application, and to separate source code from an application because of incompatible software licenses.

Examples of applications and their plug-ins include:

• Email clients use plug-ins to decrypt and encrypt email (Pretty Good Privacy)
• Graphics software use plug-ins to support file formats and process images (Adobe Photoshop)
• Media players use plug-ins to support file formats and apply filters (foobar2000, GStreamer, Quintessential, VST, Winamp, XMMS)
• Packet sniffers use plug-ins to decode packet formats (OmniPeek)
• Remote sensing applications use plug-ins to process data from different sensor types (Opticks)
• Software development environments use plug-ins to support programming languages (Eclipse, jEdit, MonoDevelop)
• Web browsers use plug-ins to play video and presentation formats (Flash, QuickTime, Microsoft Silverlight, 3DMLW)
• Some digital mixing consoles allow plug-ins to extend features such as reverberation effects, equalization and compression.

Declarative Services and bnd

I really like declarative services because it satisfies one of my main instincts: less is more. You can get services to work in a very easy way. However, the XML is still, well, ehh, XML. Obviously, the unnecessary verboseness of XML still offends my instincts. XML is useful in machine to machine communications because it is well standardized but it should have no place in human-machine interaction.

I therefore, a long time ago, added a facility in bnd to create the declarative services from a manifest header. For simplicity, I like the static 1:1 policy/cardinality so that was the default.

  Service-Component: aQute.shell.osgi.OSGiShell;\
     provides:=aQute.command.CommandProcessor; \
     threadio=aQute.threadio.ThreadIO

This creates the following XML:

 <?xml version='1.0' encoding='utf-8'?>
 <component name='aQute.shell.osgi.OSGiShell'>
   <implementation class='aQute.shell.osgi.OSGiShell'/>
   <service>
     <provide interface='aQute.command.CommandProcessor'/>
   </service>
   <reference name='threadio'
     interface='aQute.threadio.ThreadIO'
     bind='setThreadio'
     unbind='unsetThreadio'/>
 </component>

As the Ruby guys would say: convention over configuration. However, not all services are 1:1 static and the syntax for specifying other cardinalities is kind of ugly. You need to list the reference names in special directives for policy:, multiple:, and optional: :

  Service-Component: aQute.shell.osgi.OSGiShell;\
     provides:=aQute.command.CommandProcessor; \
     threadio=aQute.threadio.ThreadIO; \
     dynamic:=threadio; \
     multiple:=threadio; \
     dynamic:=threadio

Yuck!

Web Applications and OSGi (Costin Leau)

Costin Leau is a Java enterprise developer with extensive J2EE and Spring framework skills, working as a software engineer for SpringSource (formerly known as Interface21). Involved in Spring framework development, Pitchfork, Spring JPA, project lead for Spring Dynamic Modules (Spring OSGi), Spring Modules and Spring JavaConfig.
Speaker at conferences on Java/Spring related topics.

Since the first milestones of Spring Dynamic Modules, requests for running web applications in OSGi started to come in. It has been probably one of the most requested features and no wonder, once 1.0 final was released, web support has been the main focus of the 1.1 branch. I am pleased to report that, with the just released M2, as already hinted by Juergen, Spring-DM supports not just vanilla wars (available since 1.1.0 M1) but also Spring-MVC applications running inside OSGi. In this entry, I would like to briefly discuss the typical OSGi web scenario and Spring-DM’s approach. But first,

Why deploy WARs in OSGi?

Easy question: OSGi natively provides versioning, package wiring and hot reloading. Imagine taking advantage of these features within your applications: you can stop embedding libraries under WEB-INF/lib and start sharing them between your web apps, avoid taglibs duplications (while keeping multiple versions running) and update, at runtime, only certain parts of your application. This is especially useful as web applications tend to be tiered and thus subject to a significant number of changes during their life cycle.

Why are web applications in OSGi problematic?

The Servlet specification revolves around the idea of a web container: a runtime environment for web components that provides standard services such as life cycle management (object creation and disposal, thread allocation), concurrency, HTTP request handling and so on. The OSGi platform on the other hand, acts also as a managed environment with its Service Registry, package wiring and versioning (to name just a few). To deal with this problem, the OSGi committee designed, part of the compendium specification, the Http Service.

Spring Dynamic Modules for OSGi(tm) Service Platforms

The Spring Dynamic Modules for OSGi(tm) Service Platforms project makes it easy to build Spring applications that run in an OSGi framework. A Spring application written in this way provides better separation of modules, the ability to dynamically add, remove, and update modules in a running system, the ability to deploy multiple versions of a module simultaneously (and have clients automatically bind to the appropriate one), and a dynamic service model.

OSGi is a registered trademark of the OSGi Alliance. Project name is used pending approval from the OSGi Alliance.

How to create a Spring bundle project in maven (and eclipse…)

The Spring-OSGi project supplies a maven archetype that will create a Spring bundle project for you all set up and ready to go.

To create a new project simply type the following:

mvn archetype:create   \
   -DarchetypeGroupId=org.springframework.osgi   \
   -DarchetypeArtifactId=spring-osgi-bundle-archetype   \
   -DarchetypeVersion=1.0   \
   -DgroupId=<your-project-groupId>  \
   -DartifactId=<your-project-artifactId> \
   -Dversion=<your-project-version>

The result of this is a maven project that defines a simple bean, configures it using src/main/resources/META-INF/spring/bundle-context.xml and src/main/resources/META-INF/spring/bundle-context-osgi.xml, and provides unit and (out of container) integration tests. The project is packaged as an OSGi bundle.

There project does not contain a META-INF manifest yet – to generate one invoke the following command:

mvn package
mvn org.apache.felix:maven-bundle-plugin:manifest

You should now see the MANIFEST under target/classes/META-INF/ folder (the upcoming 1.0.1 version will properly generate this folder under META-INF).

Note: if you haven’t already downloaded and installed the spring-osgi artifacts (by running ‘mvn install’ on the spring-osgi tree) you’ll need to add an additional parameter to the above command: -DremoteRepositories=http://s3.amazonaws.com/maven.springframework.org/milestone. If this parameter does not work for you first time, see the additional instructions here.

Getting Started with OSGi (Neil Bartlett)