In-Depth

XML/A: Truly Portable OLAP Getting Closer

A single API for exchanging analytical data between OLAP clients and servers—regardless of platform or language—is part of the promise found in a draft specification called XML/A.

• By Stephen Swoyer
• 10/08/2003

Psssst! Want a single API for exchanging analytical data between OLAP clients and servers—on any platform and in any language? Looking for a way to arm your users with unconventional OLAP clients—such as Microsoft Excel, Microsoft PowerPoint, or even a vanilla Web browser—that can exchange analytical data with non-Microsoft sources?

Too good to be true? Not necessarily.

Hyperion Solutions Corp., Microsoft Corp., and SAS Institute Inc. are pushing a new standard, dubbed XML for Analysis (XML/A), which purports to deliver on the promise of truly portable OLAP. It’s not just a pipedream, either: SAP has already productized support for XML/A in its new Business Warehouse 3.0, and other vendors—such as Microsoft—have released tools that allow customers to exploit draft versions of the standard.

Funny thing is, there may already be an unofficial standard API for OLAP—Microsoft’s OLE DB for OLAP API, which the software giant announced in 1997. Slightly more than a year later, Microsoft unveiled a SQL Server 7.0 database that featured an integrated OLAP engine, called OLAP Analysis Services. At that point, says Mike Schiff, a senior analyst with Current Analysis Inc., OLE DB for OLAP became a de facto standard. “Because of Microsoft’s installed base, and because they were giving [SQL Server’s Analysis Services] away for free, [OLE DB for OLAP] was something that [ISVs and enterprise developers] had to take seriously,” he observes.

Enter XML/A

Because OLE DB for OLAP was based on Microsoft’s proprietary COM architecture, however, it was poorly suited to the highly distributed world of Web services. In December 2000, Microsoft introduced XML/A, which it initially positioned as a .NET counterpunch to the Java OLAP (JOLAP) standard then being touted by Hyperion, IBM Corp., Oracle Corp., and Sun Microsystems Inc. Unlike OLE DB for OLAP, which was a Microsoft-centric query and retrieval mechanism, XML/A proposes to be a platform-indifferent standard.

Matt Abrams, senior manager of global partner technologies with Hyperion, likens XML/A and its mdXML query language to ODBC and SQL, which defined a consistent interface and query language for relational database management systems. “One of the major problems that XML/A is trying to solve is similar to what relational databases have solved with SQL and ODBC, which is providing a single, consistent interface into OLAP servers or data mining servers that front-end tools can access without having to write to multiple interfaces or OLAP engines,” he explains.

In April of 2001, Hyperion joined forces with Microsoft to publish a draft version of the XML/A specification. The move surprised some industry watchers because the two companies had traditionally bickered over OLAP APIs. Not anymore. One upshot of Hyperion’s move was that IBM, which OEMs Hyperion’s Essbase OLAP server, also came on board the XML/A bandwagon, albeit in an unofficial capacity. Hyperion didn’t abandon JOLAP, however. It retained its role as specification lead in the Java Community Process Program’s expert committee for JOLAP. It’s for this reason that Current Analysis’ Schiff has called Hyperion the “Switzerland of OLAP APIs.”

For his part, Hyperion’s Abrams says that XML/A and JOLAP are actually highly complementary standards that address different market niches. “In terms of the Java OLAP camp and XML for Analysis, they actually work very well together. They serve two different needs: JOLAP is for the procedural Java developer, there’s no linguistic interface, it’s straight java procedural coding, whereas XML for Analysis is much more of a linguistic interface, a query language specification, combined with Web services.”

Momentum Behind XLM/A

Hyperion and Microsoft were joined by SAS in April of 2002. The three partners chair the XML Analysis Council, which consists of representatives from more than two dozen member companies—including BI powers AlphaBlox Corp., Applix Inc., Business Objects SA, and Cognos Inc.—who meet quarterly to discuss the XML/A specification.

The XML Analysis Council says that it will turn XML/A over to a standards body when its members feel that the specification is mature enough. When that will be isn’t quite clear at this point. Version 2.0 of the XML/A draft specification was promised for delivery by the summer or fall of 2003, but Abrams says the XML Analysis Council probably won’t release another version of the specification—possibly a 1.2 release—prior to February 2004. “Our objective as founders is to ensure that we do hand this over to a standards body at the appropriate time, and that’s when we think that we’ve matured the specification enough among the council members that it‘s a workable version that has the performance and compatibility aspects that people are looking for.

As it now stands, XML/A describes a simple object access protocol-based (SOAP) mechanism for transmitting client requests to, and retrieving information from, a server. XML/A can exploit a variety of transports, including HTTP. More importantly, it’s based almost entirely on Microsoft’s OLE DB for OLAP, so that many of its functions—including its mdXML query and modeling language—should seem familiar to the thousands of developers who already use OLE DB for OLAP and Microsoft’s MDX query language. XML/A also encompasses another Microsoft standard, OLE DB for Data Mining, and will be able to query and return results from data mining servers.

Aaron Zornes, a senior vice president of enterprise analytics with META Group, says that XML/A is definitely an up-and-comer. “To me the surprise was that XML for Analytics actually has true momentum, as opposed to politically correct waving-the-Microsoft-flag momentum, because there have been a lot of other Microsoft standards that people have paid lip service to, but, let’s face it, weren’t very enthusiastic about,” he comments. “But in the last six months, I’ve seen a definite increase in substantive R&D work with the OLAP vendors we work with.”

Adds Rob Hamm, director of the Microsoft Alliance with SAS: “There [are] 33 companies involved in this specification, which has really taken off in the last year. Now that the [version 1.1] specification is out, we expect that this will only continue.”

If developer interest is any litmus test, XML/A appears to have won a few converts. Microsoft has released an XML/A toolkit, and several contributors to a discussion forum sponsored by the XML Analysis Council have said that they’re at least playing with the technology. Many are using XML/A in tandem with version 3.0 of Business Warehouse from SAP AG, which supports the standard (see http://www.xmla.org/display_forump.asp).

Others, such as Chris Harrington, president of Web application and information portal development shop Active Interface Inc., have already used XML/A to build a variety of intriguing proof-of-concept applications—including Excel analytic report workbooks and PowerPoint presentations that have been generated from OLAP data.

Not surprisingly, Harrington is excited about XML/A’s potential. “It creates capabilities that previous to this … the infrastructure from a developer’s standpoint simply wasn’t there to do those things,” he comments. “As my code samples show, you can generate very rich PowerPoint presentations directly from [SQL Server’s] Analysis Services with very little code.” (Harrington’s code samples are available at http://www.activeinterface.com/thinolap/thinolap.asp.)

Harrington knows of what he speaks. He’s done contract work for a variety of big names—including CIBC World Markets and AccuWeather—and was tapped by one client in 1998 to build a Web OLAP client. In the absence of viable XML alternatives on either the server or the client sides, Harrington says, he had to shoot from the hip. “It was a very contorted process,” describing an “impressive” finished solution that used a technique called remote scripting to make “lots and lots” of individual requests to a database to build a structure which represented the hierarchical organization of data, which was then generated as Java script so that it could be sent down to a Web browser. “It was the only way to do it at the time, but it was far from ideal,” he says.