[Mondrian] xmla over olap4j server

Julian Hyde jhyde at pentaho.com
Fri Mar 4 16:58:54 EST 2011


Michele,
 
I have done about 90% of the work that you need, but the code is still part
of the mondrian code base. It would be great if you could push forward the
final 10%, and let me know what changes need to be made.
 
Then some point, I can spin all of this code (XmlaServlet, XmlaHandler) out
as a separate project that is outside the mondrian code base and has zero
dependencies on Mondrian. (I'd describe it as an "XMLA olap4j bridge"; not
to be confused with the XMLA olap4j driver, which operates in the reverse
direction.)
 
Later we might also move over mondrian's XMLA tests, packaging them in a jar
so that they can continue to be called from Mondrian's suite, but can also
be called from others' suites.
 
I did the changes on the //open/mondrian-release/3.2 branch (mainly changes
13929 and 13944, see below), but I have since integrated back to the main
line //open/mondrian. There aren't many differences between those branches
at this point, but you should work on main.
 
Perforce changes:

*	13929: http://perforce.eigenbase.org:8080/@md=d
<http://perforce.eigenbase.org:8080/@md=d&cd=//&rc=s&rg=c&c=Umg@/13929?ac=10
> &cd=//&rc=s&rg=c&c=Umg@/13929?ac=10
*	13944: http://perforce.eigenbase.org:8080/@md=d
<http://perforce.eigenbase.org:8080/@md=d&cd=//&rc=s&rg=c&c=Umg@/13944?ac=10
> &cd=//&rc=s&rg=c&c=Umg@/13944?ac=10

You would need to instantiate mondrian.xmla.impl.XmlaServlet (probably its
default implementation mondrian.xmla.impl.DefaultXmlaServlet) in your web
server.
 
You will see that XmlaServlet has a 'MondrianServer server' data member. But
it is only used to create an XmlaHandler, so you could easily remove it.
 
mondrian.xmla.XmlaHandler does most of the work, and following change 13929
and 13944 the dependencies on mondrian are minimal. Just utility classes. It
gets all of the information it needs from an olap4j connection.
 
The XmlaHandler.XmlaExtra interface provides extra metadata & functionality
that is not (currently) in the olap4j interface, such as drillthrough, and
whether a hierarchy is a parent-child hierarchy. Your olap4j connection
class can optionally provide an XmlaExtra, by implementing the
Connection.unwrap(Class) method. (Called from
XmlaHandler.getExtra(OlapConnection). If it returns null, XmlaHandler will
use a default XmlaExtra that uses dumb defaults.
 
The key callback is XmlaHandler.ConnectionFactory. Either provide
ConnectionFactory when servlet creates an XmlaHandler, or override
XmlaHandler.createConnection.
 
Your implementation of ConnectionFactory probably just creates an olap4j
connection, but it needs to set its catalog, schema and role consistent with
the values in the XMLA request.
 
Then XmlaHandler will call your olap4j connection to find other available
catalogs and schemas in that server.
 
I've punted on authentication for now. I assume that the container has
authenticated, and has set the "role_name" property in the request contet.
Probably if there is a username and password in the XMLA request they should
be passed into the getConnection method, but the olap4j provider should also
be able initiate request-response authentication over HTTP. And it should
figure out for itself the default role for that user. Much to do in that
area...
 
Hope that helps.
 
Julian


  _____  

From: mondrian-bounces at pentaho.org [mailto:mondrian-bounces at pentaho.org] On
Behalf Of Michele Rossi
Sent: Thursday, March 03, 2011 12:46 AM
To: mondrian at pentaho.org
Subject: [Mondrian] xmla over olap4j server


Hi, 
first all of thanks a lot for all your efforts on Mondrian and OLAP4J -
we're using both and they are working fantastically for us.

We have built our own OLAP4J driver for our internal system and we'd like to
use the feature described here by Julian Hyde:
http://julianhyde.blogspot.com/2010/11/architectural-shuffling-in-mondrians.
html

What is the status of the work in this area?
I think that the ideal solution would be a webapp configurable with the
details of the OLAP4J driver / URL to connect to.

Unfortunately I am not at liberty to contribute to open source projects
during my working hours but I could think about doing it in my free time.

In that case we'd have a discussion about it and agree broadly on the
implementation.

What do you think about the above?

What perforce branch should I look at for those changes?
Is mondrian_release/3.2 the correct location?


thanks a lot,
Michele

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.pentaho.org/pipermail/mondrian/attachments/20110304/5f8e5d5e/attachment.html 


More information about the Mondrian mailing list