A More Nimble OSGi

A growing sect of developers believe that OSGi and modularity are the inevitable future of programming.  However, the growth of OSGi support is slowed by the challenge of learning and managing OSGi frameworks and bundles.  Robert Dunne is a part of the growing OSGi movement who, in the process of designing an enterprise OSGi application platform at Paremus, created Nimble.  Nimble is a lightweight kernel that simplifies the management and deployment of modular applications.  It combines two main elements: the Paremus OSGi Shell (Posh) and a powerful dependency resolver and provisioner.  In an exclusive interview with Dunne, DZone got a full overview of
Nimble's technology and a sneak peek at future versions. 

DZone:  What is the Nimble OSGi Kernel and how did it come about?

Robert Dunne:  Most of the technology in Nimble was originally developed for use in our other product, Paremus Service Fabric.  What happened was that, internally, we were using a subset of the Service Fabric’s capabilities to make our day to day development work with OSGi easier and we realised that this subset would be useful to a lot of people.  So, we broke those pieces out, added some polish and turned them into a product: Nimble.

A lot of the people who are getting interested in OSGi find its highly modular approach appealing, but are put off by the following:

• Lack of an easy or standard way to interact with an OSGi framework
• The complexity involved in managing OSGi bundle dependencies
• Immature bundle creation tooling
• Nimble tackles the first two points. Paremus is also trying to address the third via the Sigil project which we recently donated to the Apache Felix project.

Software Developers and Administrators are used to interacting with their operating system using an interactive shell and scripting environment.  In the Unix world the most popular of these is Bash.  Nimble provides a Bash like shell called Posh, which lets you interact with the OSGi framework.  Posh’s command interpreter is Apache Felix GoGo, to which we are a contributor.  Posh also provides things like command history, command completion, and scriptability. Posh is portable across OS’s and OSGi frameworks.

An installed OSGi bundle isn’t useful until all of its dependencies have been satisfied.  Sorting these out manually can be extremely onerous.  The idea behind Nimble’s resolver is that when you are installing something, e.g. a bundle, all you should have to ask for is that thing, leaving the resolution of supporting dependencies to Nimble.

Nimble’s resolver resolves dependencies against configured repositories.  These repositories contain metadata extracted from, e.g. bundles, and policy information that is used to influence the resolution process.

There’s an interesting analogy between the recursive construction approach used by POJO configuration frameworks like Spring or Guice and the module level recursive construction approach used by Nimble’s resolver.  This influences a lot of our thinking.

                                      

DZone:  How does Nimble make things any easier on people who are still learning OSGi?

Robert:  The Posh shell provides a familiar environment that makes it easy to do interactive tests and experiments and to write scripts that automate common tasks.  Posh also makes it easy to switch between different OSGi frameworks so that you can see which one you prefer and easily determine if problems you are experiencing are due to bugs in the framework.

The resolver has the benefits described earlier. It also makes it easy to load common OSGI services, such as the configuration admin service in a single line.  It is also aware of popular OSGi runtimes such as SpringDM, Declarative Services and iPOJO, and will autoload them whenever they are required, and remove them when they are no longer needed.  Similarly it can detect WABs, i.e. bundles that are also WAR files, and will ensure that a full web stack is installed whenever one is deployed.


DZone:  Describe a basic deployment of Nimble.

Robert:  Nimble is a 55k download. To start it you just launch the Posh shell. Everything else is downloaded and cached on demand. Because of this, updates to Nimble don’t often require a new download. They are usually handled by updating Nimble’s cache.

Nimble uses Equinox as its default framework, but you can switch to Felix of Knopflerfish by using a different startup flag, The task of downloading these frameworks is handled by Nimble. Multiple instances of Nimble can run simultaneously from the same install directory.

Nimble can be started interactively or as a background process. The former is useful during development and the latter when you are actually deploying an application.  You can communicate with Nimble instances that are running in the background using SSH.

When you invoke a command in Nimble, Nimble first checks to see if the command is installed, and if not attempts to download and install the bundles required to support it.  Before you do anything, the basic Nimble installation uses only 3 bundles (4 in interactive mode)


DZone:  What makes Nimble unique compared to similar technologies?

Robert:  Apache Karaf is probably the nearest thing to the Posh shell. It uses the same GoGo command interpreter as Posh. Karaf is useful, but has a much larger minimal installation, so there’s more chance that its bundles will interact with your applications.  Also, Karaf doesn’t have a resolver like Nimble. It can be used with OBR (see below), but relies more on canned installations.  The Posh shell's support for command history, command completion, scripts and multiple instances, is more mature.

Spring have their own non standard shell, mostly aimed at Spring DM Server.  It provides some commands and a history facility.  It doesn’t have things like the ability to write scripts with loops and conditionals.

The first OSGi resolver was OBR, now part of the Apache Felix project.  This has some similarities to Nimble’s resolver, but only allows for installation of bundles, not removal, and deals with a narrower range of dependency types.  OBR is in the process of becoming an OSGi standard. Nimble supports OBR’s repository format.

The Eclipse IDE uses the P2 resolver to manage its updates.  P2 is powerful, but heavyweight and very obscure, making it impractical in most cases.

Nimble’s advantages are that it is very small and portable, and that it has a well integrated shell and resolver that make it very productive and easy to use.


DZone:  What is the current version/state of the product?  

Robert:  1.0.6 - This is the third micro update to the 1.0 release.


DZone:  What can we expect in future versions?

Robert:  Support for the pending OSGi Web Container standard (RFC 66) and the OSGi Remote Services standard.

• Support for native code deployment and Peaberry (Guice OSGi)
• Deep support for using the resolver to set configuration values
• More predefined repositories for common development targets
• More easy to use, portable, commands for managing OSGi core and compendium services
• Continued focus on ease of use

DZone:  What license(s) is Nimble under?

Robert:  Nimble is available to download and use for free with a 30 day renewable commercial license

A perpetual Nimble license is also available for $250. One license allows up to 4 Nimble instances per machine. Support packages are available on request for customers who have purchased perpetual licenses.

Full details of Nimble’s licensing options can be found here.


DZone:  Is there anything else you'd like to add?

Robert:  It’s worth mentioning the relationship between Nimble and the Service Fabric again.  After extracting Nimble from the Service Fabric we turned it around so that the distributed Fabric is now made up of multiple Nimble based processes called Fibres.

Nimble lets you ask for what you want to deploy locally and then analyses the dependencies to figure out how to do this.

The Fabric does something analogous for distributed systems.  When you pass the Fabric a description and SLA for a distributed system it analyses the dependencies and available hardware to plan the layout of the system and then provision it.  Once live, the system is monitored for failures and threats to the SLA and rebalances the system to compensate for these and maintain system performance.