Platform migration to OSGI
Platform migration to OSGI
Introduction
For some years now it’s been our desire to transition away from our limited home-grown plugin system to an industry standard modular system based-on OSGI. In 5.0 we began laying the groundwork for this transition. 5.1 sees us forge a clear migration path and rolls-out the first stages of OSGI in the Platform.
Background
Why is this migration necessary? The answer requires a little background on the architecture of the Platform.
The Platform at one time was designed around a central service-locator backed by a singular ObjectFactory ( Spring in production ). Unfortunately this service locator didn’t support collections of objects, querying, or the ability to extend it without editing a bunch of core files. There was no clean way to drop something into the platform and have it integrate well with the system. Consequently the IPluginManager came to prominence. IPluginManager and PlatformPlugins provided a good “vehicle” for getting new features into the system. Since then the Platform has steadily moved to a more plugin-centric model. This has been a double-edged sword. One one side the extensibility of the Platform without having the modify the core increased greatly. On the other, "core" code became a second-class citizen in it’s own house. To work around this many of the "core" features had to be registered through placeholder plugins such as the “default-plugin” and "admin-plugin".
We also increasingly find ourselves running into the limitations of the Platform Plugin system. Classes cannot be shared between plugins, limiting the extension of the platform and hurting cohesion between plugins. As Classes cannot be shared , no new concepts can be added to the system. Calls between plugins are diffucult to perform, often relying using web services, content-generators and even reflection to work-around this limitation.
Why OSGI?
OSGI is a industry-standard Modular Software framework. It's design supersedes that of a plugin architecture. Core code and extensions are built using the same modular design, Bundles, which most closely resemble the concept of Plugins. Everything is on the same footing in OSGI. Versionsed Classes can be freely shared between bundles allowing for the controlled extension of the platform. The OSGI environment has built-in resilience to change at runtime for bundles installing and uninstalling.
In truth the Migration to OSGI is not exchanging one plugin system to another. Rather it is moving to an architecture which does not require a Plugin system at all.
5.0 and 5.1 Enhancements preparing for OSGI
You can read about the steps taken to in 5.0 and 5.1 which set the stage for this migration here:
Platform enhancements in 5.0 and 5.1
6.0 and Beyond -the next steps
The goal for 5.2 is to be able to migrate PlatformPlugins to Bundles. Several Jira cases have been created to encapsulate the work to be done in 6.0
BISERVER-11539 - Support the ability to provide Platform Plugins from OSGI
Our home-grown plugin system is limiting our ability to deliver compelling product
BISERVER-11540 - Deprecate the IPluginManager as a Service Locator
Have the PluginManager register objects with PentahoSystem instead so we have a single point for service location
BISERVER-11541 - IPluginResourceLoader needs to be modified to work with resources provided by OSGI Bundles
The ResourceLoader api is separate from PlatformPlugins and The IPluginManager but one that needs to be made to work with OSGI Bundles
MARKET-151 - The Marketplace needs to be updated to work with OSGI Bundle plugins
BISERVER-11542 - Sample OSGI Bundles need to be written demonstrating PlatformPlugin-like behavior
BISERVER-11543 - A Type-Tracking system needs to be added to the Pentaho Platform API
As the new system allows PlatformPlugins and OSGI Bundles to be de/registered at runtime, we need a way to notify other areas of the system of the events
BISERVER-11544 - PentahoSystem's AggregateObjectFactory needs to be updated to cache query results
7.0 Goals
Once we have the ability for plugins migrate the OSGI, the next step is to move the "core" code into OSGI as well. This involves moving the OSGI container from an isolated embedded space to become the top-level container of the system. This migration is easier than it sounds. The "core" code left after 5.2 is all contained in the "pentaho" WAR. OSGI supports the deployment of WARs as OSGI bundles. The entire pentaho WAR will become one large WAB (Web Application Bundle). From there the work of separating out parts to their own distinct bundles can begin.
Also in 6.0 is the switch to the OSGI Service Registry away from PentahoSystem. All IPentahoObjectFactories in the 6.0 timeframe will be updated to register with the OSGI ServiceRegistry. Once done the PentahoSystem.getXXX() calls can be migrated away from our code to simply call into OSGI. Once this is done we can start the process of deprecating the Pentaho-Specific APIs and transition to plain OSGI.
7.0 Architecture:
