Distributed OSGi - what is the correct way to manage packages in all containers?

Question

We are considering the use of distributed OSGi in our corporate environment.
We would have the following setup:

• 10 - 100 OSGi containers on many hosts offer various services.
• Many of these services are provided in more than one container.
• Some of these services may require coordination across all containers (deployed in the same version).

How can I manage the life cycle of packages (install, start, update, stop, remove) in all containers?

A few requirements:

• Since there can be so many containers, they all need to be handled together; that is, when I am going to update a package, one command should update all containers in which this package is already present.
• Commands must be repeatable: first run the command on the test systems, and then repeat the same command on the production system after testing is complete.

I appreciate any suggestion on the above issue.

Regards, Marton

Answer 1

You might want to take a look at more “manageable” cloud solutions: Apache ACE or its older brother, Amdatu .

Apache ACE turns a single OSGi container into managed containers that can be monitored from a single administrative point. Amdatu is a more complete framework that includes ACE to provide, but adds horizontal functionality.

Answer 2

As for managing a large number of packages, look at the functions of Karaf - they greatly simplify the processing of mainly sets of packages.

For the distributed side of things, take a look at the Karaf Cellar subproject, it clusters Karaf using HazelCast (and it installs in Karaf through the feature engine).

Answer 3

If you are serious about an off-the-shelf, “solid”, distributed OSGi battery life, then take a look at the Paremus Service Fabric. We have been doing this since 2005 :)

Fabric service provisioning / management architecture is extremely scalable (→ 1,000 out of containers), responsive and stable! Several years of development and commercial execution experience underlying this product. The Service Fabric architecture supports many concurrent OSGi-based distributed applications. Service Fabric architecture is OBR oriented; Our lead engineer was responsible for the recent activities of the OSRi Alliance OBR.

Fabric Service Message Backplane uses the DDS messaging protocol, which IMO is a natural partner for distributed OSGi. Paremus RSA (implementation of remote services) is a clean room that implements a standard that is highly reliable, lightweight and allows you to dynamically connect protocols and distribution providers. The default discovery provider is again DDS.

Finally - and the Service fabric works out of the box.

Answer 4

At Gyrex, we use p2 to distribute packets across different nodes of the cluster. You can control which packages should be provided to which node using node tags and LDAP filter expressions (common in OSGi). For example, you can install (and activate) web packages only on websites.

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