经过近五年的工作，商业智能厂商Pentaho发布了olap4j 1.0，olap4j 1.0是一个全新、通用的Java API，适用于所有在线分析处理(OLAP)服务器。当前版本支持以下几款OLAP服务器：
　Pentaho分析服务(Mondrian)
　Microsoft SQL Server分析服务
　Jedox Palo
　SAP/BW
　　以前业界曾有过提供标准Java OLAP API的尝试。Java Community Process在2000年的时候正式提出要有一个标准的OLAP接口，以便在替换供应商的时候少更改实现。JSR 69——Java OLAP Interface(JOLAP)当初打算要为能创建、维护OLAP数据和元数据的J2EE环境提供厂商无关的纯Java API。但这个规范在2004年获批后并没有完成，导致Java开发社区仍然没有标准的Java OLAP API。
　　 有幸采访了olap4j规范的领导者、Pentaho分析的首席架构师和Mondrian的创始人Julian Hyde，以了解olap4j的更多内容。
　　 ：olap4j 1.0版本的主要功能有哪些?
　　Olap4j是一个允许你从Java环境里连接OLAP数据库、查询元数据、执行MDX查询的API。它是第一个让Java程序员连接不同厂商OLAP服务器的Java API。
　　有两种olap4j驱动。一种用于基于SOAP的标准XMLA(XML for Analysis)，这个驱动可以和任何XMLA服务器通讯，包括Microsoft SQL Server分析服务2005和2008版本、Jedox Palo、SAP/BW。用于Mondrian的olap4j驱动可以在同一个JVM内和Mondrian引擎通讯，Mondrian驱动是olap4j的参考实现，而且几年前就已经成为Mondrian的主要API了。
　　olap4j API和两种驱动这几年在生产环境里证明都是很稳定的。
　　 ：对开发社区来说，有一个用来和OLAP服务器交互的开放标准为什么很重要?
　　开放的标准能为开发人员、集成商和最终用户提供一种选择。没有开放标准的话，如果你想使用供应商X的OLAP服务器，你就会受到限制，必须使用供应商X的OLAP客户端。你要是正在构建应用，应用也会受限于供应商X。使用olap4j的话，如果有一款OLAP服务器更好、更便宜、更快，或者只是因为某个特定客户已经有该服务器的站点许可了，那你就可以切换到这个服务器上去。而且OLAP客户端也会有多种选择。
　　 ：olap4j和JSR 69有何不同?
　　在我看来，JSR 69有很多不足之处。它是一个相当高层次的接口，要求用户理解非常多的元模型(基于公共仓库元模型)和大量的查询模型。查询需要调用API，而不是在SQL或MDX之类的语言里用文本的方式去指定。发起JSR 69的那些厂商都有既有的实现，我觉得他们要在各种查询构建API里找到一种调和的方案，结果却僵持不下。最终，领军OLAP服务器市场的Microsoft并没有成为规范的贡献者。
　　大约在同一时间，Microsoft提出了自己的OLAP标准：在C和C++环境下用于OLAP的OLE DB，用于C#和VB等.NET语言的ADO MD，还有用于SaaS的XMLA(一种SOAP方言)。这些标准更加简单，而且由于基于查询语言MDX，它们更像开发人员用来和关系型数据库交互的API(ODBC、JDBC)。这些标准已经在各自的环境里得到了普遍的应用，Microsoft当然没有兴趣去创建一个Java标准。
　　olap4j为了让Java开发人员立即上手，采用了Java开发人员所熟悉的JDBC模式。比如说，olap4j里创建连接、准备和执行语句的代码看起来和JDBC里的非常像。所不同的是，查询语言是MDX而非SQL，而且结果是个多维的CellSet，而不是由行和列组成的ResultSet。
　　olap4j差不多可以说是JDBC的扩展，实际上这意味着你可以为olap4j连接使用连接池、目录服务等基础设施，就像供JDBC连接使用的一样。
　　 ：这些MDX查询是如何生成的?
　　在JDBC应用里SQL通常是硬编码的，相反，OLAP的目的是进行交互式的数据探索，所以查询需要动态生成。Olap4j提供了一个查询模型，可以一步一步构建查询，然后转换成MDX。olap4j和以查询模型为中心的API(比如JSR-69和Oracle的OLAP API)相比，最关键的区别在于olap4j里查询模型是可选的。如果你是应用开发人员，你的应用总需要展示同样的图表或数据表格，那你可以手工编写MDX查询;如果你是OLAP工具开发人员，你就可以使用olap4j的查询模型或是构建自己的查询模型。虽然我们已经到了1.0版本，但olap4j的查询模型仍然在继续进行。好消息是它并不是API的核心部分，而且它的演进不会破坏API的其他部分。
　　这样做的结果是olap4j要比JSR-69和Oracle的OLAP API更小、更简单。对学习API的应用开发人员，以及试图实现API的服务器和驱动的开发人员来说，这可是个好消息。

经过近五年的工作，商业智能厂商Pentaho发布了olap4j 1.0，olap4j 1.0是一个全新、通用的Java API，适用于所有在线分析处理(OLAP)服务器。当前版本支持以下几款OLAP服务器：
　Pentaho分析服务(Mondrian)
　Microsoft SQL Server分析服务
　Jedox Palo
　SAP/BW
　　以前业界曾有过提供标准Java OLAP API的尝试。Java Community Process在2000年的时候正式提出要有一个标准的OLAP接口，以便在替换供应商的时候少更改实现。JSR 69——Java OLAP Interface(JOLAP)当初打算要为能创建、维护OLAP数据和元数据的J2EE环境提供厂商无关的纯Java API。但这个规范在2004年获批后并没有完成，导致Java开发社区仍然没有标准的Java OLAP API。
　　 有幸采访了olap4j规范的领导者、Pentaho分析的首席架构师和Mondrian的创始人Julian Hyde，以了解olap4j的更多内容。
　　 ：olap4j 1.0版本的主要功能有哪些?
　　Olap4j是一个允许你从Java环境里连接OLAP数据库、查询元数据、执行MDX查询的API。它是第一个让Java程序员连接不同厂商OLAP服务器的Java API。
　　有两种olap4j驱动。一种用于基于SOAP的标准XMLA(XML for Analysis)，这个驱动可以和任何XMLA服务器通讯，包括Microsoft SQL Server分析服务2005和2008版本、Jedox Palo、SAP/BW。用于Mondrian的olap4j驱动可以在同一个JVM内和Mondrian引擎通讯，Mondrian驱动是olap4j的参考实现，而且几年前就已经成为Mondrian的主要API了。
　　olap4j API和两种驱动这几年在生产环境里证明都是很稳定的。
　　 ：对开发社区来说，有一个用来和OLAP服务器交互的开放标准为什么很重要?
　　开放的标准能为开发人员、集成商和最终用户提供一种选择。没有开放标准的话，如果你想使用供应商X的OLAP服务器，你就会受到限制，必须使用供应商X的OLAP客户端。你要是正在构建应用，应用也会受限于供应商X。使用olap4j的话，如果有一款OLAP服务器更好、更便宜、更快，或者只是因为某个特定客户已经有该服务器的站点许可了，那你就可以切换到这个服务器上去。而且OLAP客户端也会有多种选择。
　　 ：olap4j和JSR 69有何不同?
　　在我看来，JSR 69有很多不足之处。它是一个相当高层次的接口，要求用户理解非常多的元模型(基于公共仓库元模型)和大量的查询模型。查询需要调用API，而不是在SQL或MDX之类的语言里用文本的方式去指定。发起JSR 69的那些厂商都有既有的实现，我觉得他们要在各种查询构建API里找到一种调和的方案，结果却僵持不下。最终，领军OLAP服务器市场的Microsoft并没有成为规范的贡献者。
　　大约在同一时间，Microsoft提出了自己的OLAP标准：在C和C++环境下用于OLAP的OLE DB，用于C#和VB等.NET语言的ADO MD，还有用于SaaS的XMLA(一种SOAP方言)。这些标准更加简单，而且由于基于查询语言MDX，它们更像开发人员用来和关系型数据库交互的API(ODBC、JDBC)。这些标准已经在各自的环境里得到了普遍的应用，Microsoft当然没有兴趣去创建一个Java标准。
　　olap4j为了让Java开发人员立即上手，采用了Java开发人员所熟悉的JDBC模式。比如说，olap4j里创建连接、准备和执行语句的代码看起来和JDBC里的非常像。所不同的是，查询语言是MDX而非SQL，而且结果是个多维的CellSet，而不是由行和列组成的ResultSet。
　　olap4j差不多可以说是JDBC的扩展，实际上这意味着你可以为olap4j连接使用连接池、目录服务等基础设施，就像供JDBC连接使用的一样。
　　 ：这些MDX查询是如何生成的?
　　在JDBC应用里SQL通常是硬编码的，相反，OLAP的目的是进行交互式的数据探索，所以查询需要动态生成。Olap4j提供了一个查询模型，可以一步一步构建查询，然后转换成MDX。olap4j和以查询模型为中心的API(比如JSR-69和Oracle的OLAP API)相比，最关键的区别在于olap4j里查询模型是可选的。如果你是应用开发人员，你的应用总需要展示同样的图表或数据表格，那你可以手工编写MDX查询;如果你是OLAP工具开发人员，你就可以使用olap4j的查询模型或是构建自己的查询模型。虽然我们已经到了1.0版本，但olap4j的查询模型仍然在继续进行。好消息是它并不是API的核心部分，而且它的演进不会破坏API的其他部分。
　　这样做的结果是olap4j要比JSR-69和Oracle的OLAP API更小、更简单。对学习API的应用开发人员，以及试图实现API的服务器和驱动的开发人员来说，这可是个好消息。