[birt-pmc] Fw: BIRT, olap4j and mondrian

["Scott Rosenbaum" <scottr@xxxxxxxxxxxxxxxxxxxxx>]

Guys,

There is a post from Julian Hyde (Mondrian / Pentaho) asking about why we
are building are own JSR-069 DataCube as opposed to using Mondrian.  I have
included the entire text below.  I think that we need to have an answer that
we can post back to provide the BIRT PMC position.  

I realize that this may be more of a DTP question, but can we get this on
the agenda for next week?

Scott




From: "Julian Hyde" <jhyde@xxxxxxxxxxx>
Sent: 9/11/2007 11:38:44 PM
Newsgroups: eclipse.birt
Subject: BIRT, olap4j and mondrian

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.

Julian Hyde