Home » Docs

History and background

Since its birth in 1999, OSGi has steadily been gaining popularity as the component model of choice for Java. Originally designed as a framework for home gateways and other embedded systems, it has since moved on to desktop and enterprise systems and embraced by major software vendors.

OSGi allows you to build your systems out of well defined, reusable components, which brings both exciting new benefits as well as a set of challenges. One of these is the actual management of components, deployed on different target systems.

Traditional, monolithic systems usually have fairly straightforward and linear release schedules. It is quite common for most target systems to have the same version and configuration of such a system.

Component based systems can easily be customized on a per target case, meaning there might be many different configurations out there. When components are developed over time, they might be released individually and a lot more often than these traditional systems.

Keeping track of what is installed where becomes quite a challenge if the number of components and targets grows, and this is where Apache ACE comes in.

Apache ACE is a software distribution framework. It is written as a set of OSGi components and consists of three major subsystems:

  1. dependency management, which handles the complexity of managing the dependencies between component, aggregating them into features and distributions and associating those to targets;
  2. deployment management, which ensures that the right components get installed onto the right targets in a robust and scalable way;
  3. feedback management, which collects life cycle feedback on the target and aggregates that on a central server.

A typical topology consists of:

The Apache ACE software, which consists of a set of OSGi bundles, gets deployed on a server. A target can be any OSGi framework (Apache Felix, Equinox or Knopflerfish) with the Apache ACE management agent installed. This agent will connect to the server, identify itself and poll for updates. If an update is found, the agent will download and install it using the Deployment Admin specifiction, allowing for rollbacks to the previous installed version in case the installation fails.