|
Commentary: OLAP API wars |
You can contact Nigel Pendse, the author of this section, by e-mail on NigelP@olapreport.com if you have any comments, observations or user experiences to add. Last updated on August 23, 2007.
Microsoft announced XML for Analysis in late 2000, and Hyperion publicly added its support on April 23, 2001. SAS Institute became the third co-chair of XML for Analysis (XML/A) Council in April 2002, reflecting the data mining capabilities of the API.
This Microsoft-led specification had already gained wide acceptance from vendors who already supported OLE DB for OLAP, but Hyperion was the first major competitor of Microsoft’s to join the group. This was not just a paper endorsement: Hyperion and Microsoft had been working together for almost six months before the announcement, and Microsoft has adjusted the specification based on input from Hyperion. In contrast, Hyperion has always shunned OLE DB for OLAP which it regarded as Windows-specific.
Current XML for Analysis contributing council members include Alphablox, Applied OLAP, Applix, arcplan Information Services, Aspirity, Brio Software, Business Objects, Cognos, Comshare, Crystal Decisions, Dimensional Systems, Harmony Software, Lawson Software, MicroStrategy, ProClarity, Simba Technologies. and Temtec. Obvious omissions include Oracle and IBM, though Hyperion’s joint leadership provides IBM with a form of virtual membership.
XML for Analysis is evolved from Microsoft’s OLE DB for OLAP and has many similarities, but unlike OLE DB for OLAP it is not tied to any particular client or server platforms. It can be used not only for Web queries, but also for server to server communications.
It does look like XML for Analysis will soon become the most widely accepted multi-vendor OLAP query API, but it is unlikely to replace native APIs because it cannot be as efficient. XML has a large overhead that means that queries will be slower and network traffic greater than if optimized programmatic APIs were used. So vendors like Microsoft and Hyperion will continue to maintain their native APIs, which will remain the preferred choice when performance is an issue.
2007 |
Microsoft made XML for Analysis the native API for Analysis Services 2005 and it is also supported by many other vendors. Although it is not the native API for Essbase, Hyperion made more concerted efforts than we expected to support it well, and this is likely to continue under Oracle’s ownership. Essbase also makes significant use of MDX as a native calculation language. To our surprise, with Analysis Services, XML for Analysis has turned out to be more efficient than OLE DB for OLAP, thanks to efficient compression. Though there is no ‘official’ industry-standard OLAP API, XML for Analysis is now the de facto industry standard. The main fly in the ointment is that vendors have implemented their own, incompatible flavors, so client tool vendors have to build special adaptors for each server. |
On August 21 2000, the proposed new “JOLAP” Java-based multi-vendor OLAP API initiative was announced. Led by Hyperion Solutions, the other initial members of the group defining the proposed API are IBM, Internetivity, Nokia, Oracle, Painted Word, SAS Institute and Unisys. Apart from Hyperion itself, only Oracle and SAS Institute have OLAP servers of their own. JOLAP is described by the group as “a pure Java API for the J2EE™ environment that supports the creation and maintenance of OLAP data and metadata, in a vendor-independent manner”. Business Objects was the first, and so far the only, other front-end tools vendor to promise support for the initiative. Surprisingly, neither Comshare nor AlphaBlox have shown any public interest in it, despite both having Java-based Web clients for Essbase.
Previous attempts to produce multi-vendor OLAP APIs have foundered, as the companies were much more interested in competing than in cooperating. At best they intended to produce a lowest common denominator specification, although even this proved to be much too ambitious. Unlike Microsoft’s OLE DB for OLAP and XML for Analysis, and the OLAP Council’s dead MDAPI, JOLAP is intended to be more than just a query API, as it is planned to support the creation, storage, access and maintenance of data and metadata in OLAP servers and multidimensional databases. This is an ambitious goal that will be much harder to achieve than would just a common query API. Indeed, it is most probably an impossible goal.
However, facing a powerful common enemy in Microsoft, this new, smaller, grouping, with clearer leadership, should have a better chance of some modest degree of success than did the OLAP Council, whose efforts were never taken seriously even by its own members — but this is probably the anti-Microsoft group’s last chance to come up with a single OLAP API not controlled by Microsoft. Additionally, these companies do have a genuine interest in creating a Java-based API, because even those companies that also support Microsoft's OLE DB for OLAP (eg, SAS Institute and InterNetivity), know that Microsoft has no interest in producing a Java version.
JOLAP has the further problem that the Hyperion and Oracle implementations are not expected to be identical because of the differing capabilities of the underlying servers. Indeed, Oracle9i OLAP Services itself has two different OLAP engines with differing capabilities, so that there will, in effect, be at least three different levels of JOLAP support. Front-end tool vendors cannot ignore these differences, so that they will have to design and test for each of the JOLAP engines, which means it will not be a true standard, common API.
The final version of JOLAP is expected to be published in early 2003, about three years after the process started, though it is not known if or when any products supporting it will ship. This extended cycle shows how hard it is to get an agreed open API supported by competing vendors.
2007 |
JOLAP was not properly implemented by any vendors and has been quietly forgotten. Even though Oracle now owns both the Oracle OLAP Option (which has a proprietary Java OLAP API) and Essbase (which also has a proprietary Java OLAP API), we do not expect JOLAP to be resurrected. |
Literally no-one at all implemented the MDAPI 2.0, so the now-superseded OLAP Council apparently managed the impossible with the MDAPI 2.0: an even lower level of acceptance than the first version of its once hoped-for industry standard OLAP API.
The OLAP Council finally published its long-awaited Oracle-led, read-only MDAPI 2.0 specification on January 26, 1998. The revised API was packaged as Java libraries and COM objects and is accessible via low-end programming languages like C++ and JAVA as well as application development tools such as Visual Basic and Java Script. One key point is that (unlike Microsoft's OLE DB for OLAP API) the MDAPI supports heterogeneous computing environments: Windows NT servers, any Windows client, Unix, OS/2, Macintosh and any Java Virtual Machine. It also enables client and server interaction via any customer standard such as DCOM, CORBA, Java, etc.
The creation of an industry-standard API was one of the most important, and most welcomed, objectives of the OLAP Council when it was formed at the beginning of 1995. Unfortunately, its first attempt create even a draft API standard was very protracted, but finally in September 1996 a 0.5 specification was published. However, this was largely ignored, with Gentia being the only server vendor to implement it. Strangely, although no 1.0 specification was ever produced, the Council published a 2.0 version in early 1998, presumably as a reaction to the successful Microsoft OLAP API initiative.
During 1997, the OLAP Council's membership dropped from 18 to 12 companies (although the press release incorrectly claimed 13), and went down to nine before the Council was re-born as the Analytical Solutions Forum (ASF), but the 2.0 specification initially promised to attract somewhat greater support than the first attempt, because Oracle said it planned to adopt it as the native API for Express; NCR initially also said it would do the same with the new Teradata OLAP (although it later dropped this plan). In effect, this API might have succeeded because it was an Oracle-led initiative, not because of the technology or the misleading OLAP Council branding.
Apart from Oracle, which led this initiative, the OLAP vendors which publicly supported the API announcement were Cognos, Infospace (now Viador), MSA, NCR, Application Consulting Group, Pilot Software and Platinum technology (although none actually ever implemented it). Apart from this short list of OLAP vendors, two consultants with OLAP interests — the then Price Waterhouse and Dimensional Systems (which had a big hand in producing the MDAPI) — expressed support, as well as two Oracle allies with no obvious OLAP connections: Netscape and Sun.
Many more current and former members of the old OLAP Council have publicly announced support for OLE DB for OLAP than ever did for either version of the OLAP Council's MDAPI. Overall, there is no chance that there will be any real support for the MDAPI outside the Oracle camp, and even Oracle has backed away from the failed effort. It will be implementing a new "OLAPI" which will be its new proprietary API; no other OLAP server vendors will be using it, and few client tool vendors are likely to adopt it.
This phony war between Microsoft and the defunct OLAP Council is analyzed in a major section on OLAP APIs.
2007 |
The OLAP Council and its intended-successor, the Analytical Solutions Forum, are long-forgotten. Their only achievement was an OLAP benchmark, the APB-1. However, this had many flaws which were not fixed as the Council soon became inactive. |
This page is part of the free content of The OLAP Report, but ten times more information is available only to subscribers, including reviews of dozens of products, case studies and in-depth analyses. You can register for access to a preview of some of the subscriber-only material in The OLAP Report or subscribe on-line.
|
All information copyright ©2002, 2007, Business Application Research Center, all rights reserved