I noticed with interest that BIRT release 2.2 introduces OLAP capabilities,
in the form of Dynamic Crosstab support. This a welcome addition to a
well-conceived and popular open-source reporting stack.
Digging into the architecture behind this functionality, I discovered that
the BIRT team has built a cubing engine, and is using the JSR-069 (JOLAP)
specification as its API. Both of these design choices are curious, so I
would be interested hear more of the reasoning behind them.
I should state up front that I am involved with two components which could
be considered alternatives, or replacements, for the JOLAP API and the BIRT
cubing engine. I founded the mondrian project, and am contributing to the
olap4j specification.
olap4j (http://www.olap4j.org) is a relatively new API with the aim of
providing genuine portability for OLAP applications written in Java. It
provides the same services as JOLAP, such as connections, metadata, and a
query model, and in addition supports queries written in the
industry-standard MDX query language. Unlike JOLAP, olap4j is under active
development by the open-source community; and there are multiple providers:
the mondrian provider is the reference implementation, and a provider is in
the works for generic XML/A providers such as Microsoft SQL Server Analysis
Services.
mondrian (http://mondrian.pentaho.org) is the leading open-source OLAP
engine. With 6 years of development, mondrian is mature, expressive and
efficient, and has a large community of users and developers.
By using olap4j as its OLAP API, BIRT would have access to a range of OLAP
engines. It could continue to use the current cubing engine, substitute
mondrian as the in-memory cubing engine, or access a remote OLAP server.
With its eclipse-compatible license, mondrian could be distributed with
BIRT.
My posting has three goals.
First, I would like to understand the motivation behind these design
choices. There are two design choices here - choice of API, and choice of
cubing engine - and both, in my opinion, missed the opportunity to build on
an open-source technology.
Second, I would like to encourage the BIRT designers to reconsider, and
incorporate mondrian and olap4j in BIRT's OLAP architecture. I would like to
think any issues can be surmounted, and combining mondrian and olap4j with
BIRT would benefit all of our projects and our communities.
Lastly, I would like to encourage all members of BIRT's community who have
an interest in OLAP to get involved in the olap4j specification process. We
are looking for people to review the specification, develop providers for
various OLAP backends, and write applications on top of the API.