The 3 layers of abstraction to the Pentaho BI Server

Below is an attempt to fit the various elements of a Pentaho Server into a operating systems metaphor. The idea is there is a kernel of code which does the core work of the operating system, which in turn serves applications. So the layers go kernel->OS->applications.

Pentaho "Kernel" layer

The smallest indivisible unit in the BI Server infrastructure. It is worth noting that this layer is generic and has no BI-specific functionality. The kernel layer consists of:

a microplatform (for system initialization)
all core APIs (see next section for a listing of these core APIs)
a plugin management subsystem
a service locator subsystem (aka pentaho object factory)

Pentaho "OS" layer

This next layer builds on the infrastructure of the kernel to provide default implementations of the core APIs.
The OS layer could be developed and package to be offering for enabling embedded deployments. The components of the OS are unaware of the environment in which they are running, e.g. web app, fat client, embedded in another engine.

The Pentaho "OS" consists of default implementations of the core APIs of the kernel layer (declared in spring xml). These core APIs are:

solution and content repositories
datasource management
scheduling
plugin management (impl provided by the Kernel layer)
logging
auditing
system admin
system management
system health

Future consideration: if the requirement arises that implementations of certain core APIs need to be more easily swappable, we may need to investigate defining custom plugin extension points for these independent of the "worker" plugin framework.

Pentaho BI "Applications" layer

The applications layer includes the various engines and BI-specific components that make up a complete BI deployment. This layer represents the solving of the business problem, such as a BI Server deployment in a Tomcat application server configured to handle actions sequences or PDI jobs, etc.

General observations

The trend in the BI platform is to move business logic to the PojoComponent/IAction/BI Component level. Having business logic encapsulted in these beans enables us to move more quickly since these beans are beginning to be the global "currency" of the BI platform.
Regarding the framework code we are writing to run these workers, no-one conceptually has an issue with us finding a third-party solution, provided we do not sacrifice the flexibility we already have.

Development goals

We want to encourage community contribution of plugins and extensions that add new functionality and services. To achieve this, we must:

Be prepared to deliver multiple BI Server configurations to market
Concentrate on extensibility and reusability – implementing it in current code, considering it for future projects
Cleanly abstract all business logic
Design the server to support quickly adding engines and services, perhaps in different ways

Whiteboard images from meeting

Browser not supported