Distributed OSGi - what is the proper way to manage bundles across all containers?

Question

We are considering utilizing distributed OSGi in our enterprise environment.
We would have the following setup:

• 10 to 100 OSGi containers on many hosts offer various services.
• Many of these services are provided by more than one container.
• Some of these services may require being consistent across all containers (same version deployed).

What is the proper way to manage bundles' lifecycle (install, start, update, stop, uninstall) across all containers?

Several requirements:

• As there may be so many containers, all of them should be handled together; ie when I am about to update a bundle, a single command should update all containers where that bundle already present.
• Commands must be repeatable: first perform a command on test systems, and then repeat the exact same command on production system once testing is complete.

I appreciate any suggestion regarding the above question.

Best regards, Marton

Answer 1

You might want to have a look at more "managed" solutions made for cloud-like environments: Apache ACE or its bigger brother Amdatu .

Apache ACE turns a single OSGi Containers into managed containers whose state can be controlled from a single administration point. Amdatu is a more complete framework that includes ACE for provisioning but adds horizontal functionality.

Answer 2

In terms of managing large numbers of bundles, look at Karaf features - they greatly simplify handling largely suites of bundles.

For the distributed side of things, take a look at the Karaf subproject Cellar , it's clustering Karaf using HazelCast (and it installs in Karaf via the features mechanism).

Answer 3

If you are serious about enterprise ready - meaning "robust" - distributed OSGi runtimes - then have a look at the Paremus Service Fabric. We've been doing this since 2005 :)

The Service Fabric's provisioning / management architecture is extremely scalable (>> 1,000's of containers), responsive and stable! Several years development and commercial runtime experience underpinning this product. The Service Fabric architecture supports multiple concurrent distributed OSGi based applications. The Service Fabric's architecture is OBR centric; our lead engineer was responsible recent OSGi Alliance OBR specification activities.

The Service Fabric message backplane leverages the DDS messaging protocol - which IMO is the natural partner for distributed OSGi. The Paremus RSA (remote service implementation) is a clean room implementation of the standard - which is highly robust, light weight and allows dynamic plug ability of protocol and distribution providers. The default discovery provider - is again DDS.

Finally - and Service Fabric works out of the box.

Answer 4

In Gyrex we use p2 to distribute bundles across different nodes of a cluster. It's possible to control which bundles should be provisioned to which node by using the node tags and LDAP filter expressions (common in OSGi). For example, it's possible to install (and activate) web bundles only on web nodes.

Support for distributed services is not available out-of-the box . ECF needs to be integrated manually.