分析处理服务器的java api（2）

记者：这些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的服务器和驱动的开发人员来说，这可是个好消息。 记者：到目前为止，JOLAP已经成为很多其他工作的基础了。比如Hyperion的XMLA实现就使用了基于JOLAP规范的Java API。但规范本身并没有真正成为这样的标准。你打算去复兴JOLAP规范本身吗？ 我们不打算那么做，原因上面已经说过了。不过olap4j采用了XMLA的很多内容，XMLA是目前最重要的OLAP规范。两个API的元数据非常像，查询语言MDX则完全相同。主要区别是，在Java环境里olap4j要比XMLA好用的多。而且olap4j在很多情况下都比XMLA有效率，因为驱动能使用缓存，或是使用比XML over HTTP更有效的协议。 记者：你打算把规范提交给JCP么？还是想让它继续作为独立的规范和流程发展下去？ 我们希望olap4j能像JDBC那样被看作是Java运行时库的标准部分。但我们现在还不打算把它提交到JCP。JSR-69的失败有一个教训，就是市场要比JCP的结果更为重要。我们希望越来越多的服务器能添加olap4j驱动，olap4j也能随之成为市场的生力军。服务器厂商看到olap4j的好处之后，希望他们会支持我们在JCP里提议olap4j。 记者：olap4j和其他Java OLAP接口的主要区别有哪些？像Oracle的OLAP Java API。 首先，包括Oracle API在内的其他API都不是基于MDX查询语言的。相反，查询都是通过编程方式创建的，而且构建查询的API往往因厂商的不同而不同。 其次，其他API会让你受限于特定的厂商。 大多数OLAP服务器近来都实现了XMLA。这需要继续做两件重要的事情。首先就是以用于XMLA的开源olap4j驱动为起点，创建用于这些服务器的olap4j驱动。第二，这些服务器实现XMLA实际上意味着他们要实现MDX语言。所以，为这些服务器实现原生的olap4j驱动应该是有可能的，这要比基于XMLA的驱动更有效率。 记者：有计划在olap4j以后的版本里对其他OLAP服务器提供驱动支持么？ 我们不能保证支持所有特定的服务器，但作为开源项目，我们希望社区能做出有价值的贡献。在过去的一年里，其他人已经实现了SAP/BW和Palo的驱动；我希望在接下来的几个月里能有Oracle/Essbase的驱动。 记者：关于olap4j，开发社区还有应该知道的信息么？ olap4j 1.0里的核心API是稳定的。我们保证API以后演进的时候能向后兼容。但我们不会止步于olap4j 1.0。我们将以兼容的方式增强核心API，在以后的版本里我们还会添加很多内容。 我们想扩展、改进查询模型。前面已经说过，查询模型是一个生成MDX的客户端库，所以修改起来非常容易，也不会修改API里查询元数据、执行查询的核心部分。 有一个单元格回写的实验工具。它允许“假设”场景和应用的规划。它在olap4j里只是一个可选的功能，但我们希望Palo和Mondrian至少要实现它。 还有一个实验工具，在服务器上的数据发生变化时能立即接收“推”过来的通知。想象一下，Web客户端上单元格的值在你眼前发生变化，还会简单地改变颜色以提醒你有变更。 由于olap4j是按照开放流程进行开发的，贡献者来自，所以我们可以期待在规范的后续版本里能出现更多的好点子。 Olap4j和开源项目联合开发的。它是一个开放的规范，遵循Eclipse公共许可（EPL）。