經過近五年的工作,商業智能廠商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的伺服器和驅動的開發人員來說,這可是個好消息.
記者：到目前為止,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）.
