View Full Version : A new OLAP API: olap4j

09-03-2006, 08:18 AM
The first draft of the olap4j specification has just been released. olap4j is a new, simple, open API for Java-based OLAP.
What does olap4j mean for mondrian? It's well known that open source projects thrive when a standard API allows them to compete with each other and with commercial products. We expect olap4j to have the same effect. It will be possible to write an OLAP application on one server, say Mondrian, and run it on another, say Microsoft Analysis Services via olap4j's XML/A driver. And olap4j should spur development of new OLAP client tools. Users will be free to choose whichever OLAP server and OLAP client fits their needs best - which should increase adoption of mondrian.
How will olap4j affect mondrian's users? However you use mondrian, the impact on your application will be minor to moderate:
* If you use jpivot as your interface to mondrian, migration will be easy. There will be port of jpivot to olap4j soon after the first release of olap4j.
* If you use mondrian's API directly, you will have to migrate to the new API in mondrian-3.0. olap4j is based on similar concepts to mondrian's API, so this should not be too difficult.
What is the status of olap4j? olap4j is still in its early stages. The first draft of the specification, version 0.5, was just released. We will be writing the specification and developing the SDK and test suite over the next few months.
How can you participate? We want input from end-users, integrators, and representatives of other OLAP projects, so that this standard is useful to the widest possible audience. Now is a great time to get involved. Visit
download the specification, and subscribe to the olap4j forum and mailing list. We look forward to hearing from you!

09-03-2006, 02:33 PM
Whatever happened to JOLAP,
Is it valid to assume that because of functional and control/process issues it didn't fit the needs that will be met by olap4j?

09-03-2006, 09:49 PM
I think JOLAP failed to find its audience. The JSR-069 committee members meant well, but they delivered a specification aimed at an 'enterprise' audience which had a lot of functionality and was difficult to understand.
Making CWM part of the JOLAP API was a controversial choice. Sure, it's useful to have comprehensive support for metadata. But it made the API more heavyweight, both to use and to implement.
Another bad decision was that the API would build queries programmatically as opposed to using a query language. In my opinion, a query language is a better basis for an OLAP API. Why? You can layer a 'navigation API' for building queries on top of the query language, which is what everyone does with SQL, and what we intend to do in olap4j. MDX was well established at the time that the JSR-069 committee first convened, and from a design perspectivie, it would have made better sense for MDX to be at the heart of the API. Political considerations prevailed: the vendors' OLAP servers all built queries programmatically (albeit via very different APIs) and MDX had been introduced by their arch-competitor Microsoft.
All of these decisions, and others, raised the barrier to entry. No one implemented a JOLAP-compliant server or client. I wrote a very basic implementation of JOLAP for the mondrian, but there was never very much interest. Writing the JOLAP implementation was a struggle. Besides the spec, the JSR-069 committee never made any resources available besides the spec: not a TCK (test compatability kit) nor even a set of source code.
In contrast, mondrian's XML/A provider has been hugely popular. The difference? There are XML/A clients.
If there had been just one compelling client for JOLAP, I think things would have been different. Any one of the vendors could have spun off a JOLAP client, but they chose not to. So, I think it's fair to say that JOLAP died because the vendors wanted it to.
Now compare JOLAP to JDBC. In particular, think of the range of JDBC drivers today. There is a spectrum of complexity, embedded databases like Derby and hsqldb, big sophisticated drivers like oracle's driver, and exotic drivers like RmiJdbc and csvjdbc. This diversity exists because it is relatively easy to write a JDBC driver.
Our aim with olap4j is to lower the barrier to entry to writing or using an OLAP driver. Lower the barrier to entry, and people will jump aboard -- especially open source projects.
We will use the MDX query language so that people can easily create OLAP queries using just a few lines of Java. It's a lot easier to build a suite of reports if the queries underlying those reports can be serialized as human-readable text.
We will provider an MDX parser and a 'navigation' API to allow application writers to manipulate queries programmatically. (A default implementation of the MDX parser will be part of the API, so driver implementers will not need to write their own MDX parser.)
And we will provide two drivers (mondrian and XML/A) and at least one olap4j client (jpivot) with or soon after the first release of olap4j. So, there's little chance that this standard will become shelfware.
Our biggest challenge is persuading other OLAP companies and projects that we really want them to join in. Well, we do. Pentaho, JasperSoft and OpenI are on board, as are the companies behind the user-interfaces JPivot and JRubik. I've already reached out a hand to Eclipse/BIRT and to PALO. I would love to hear from OpenOLAP and vendors such as Hyperion. If just a few of these organizations can get together and deliver a pragmatic API for OLAP, along with a set of interoperable OLAP tools, I think we might have a success on our hands.