[Mondrian] xmla over olap4j server

Julian Hyde jhyde at pentaho.com
Tue Apr 19 14:03:40 EDT 2011


Michele Rossi  wrote: 

you're right, at the moment the only open source implementation of olap4j
that I know of is mondrian.

Well, there's the XMLA driver for olap4j. You can use that to talk to a lot
of databases, including the open source OLAP database, Palo.
And there is your use case: using the XMLA driver plus server to build a
proxy. Pretty useless on its own, but you could extend it to do some cool
architectural things: access control, routing, caching.

But for example we have decided to use Olap4j as API for our internal
proprietary system too.
In the future there might be more "mondrians" out there.. unlikely but who

Of course one hopes that there will be multiple implementations of a
specification. But a good spec it is useful in itself; it saves a lot of
design time if someone has already designed an API, test suite and tool set
for you. That's why I would advise others building OLAP capabilities to
implement the olap4j spec.
Other reasons to split out the XMLA server from mondrian:
1. Mondrian is a large piece of code. It is difficult to maintain and
especially difficult to contribute to. If we can carve it up into smaller
modules, we get more contributions.
2. The XMLA server was using mondrian's legacy API. We want to remove that
API someday.
3. The olap4j API is intentionally similar to XMLA. You'll find similarly
named classes and attributes in both. Making the XMLA server run on top of
the olap4j API.
4. Modularizing the XMLA server (i.e. removing unnecessary dependencies on
Mondrian) allows new architectural options. I had never dreamed that someone
would want to build an XMLA proxy.
5. Mondrian is an embeddable engine, but it doesn't quite have the services
necessary to make it a full server. (The ability to run as a service, e.g.
start up when the O/S starts; Authentication; Assignment of roles based on
who is making the connection; A repository of schemas.) Mondrian's XMLA
server had some of those services. Refactoring forced us to make those
services explicit, and pluggable.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.pentaho.org/pipermail/mondrian/attachments/20110419/68c364f0/attachment.html 

More information about the Mondrian mailing list