XML for Analysis Decoded

The XML for Analysis API has snared widespread support. But will the big fish slip through the .Net in favor of Java and proprietary APIs?

THE COMPETITION

XML for Analysis will compete not only with mature, highly functional programmatic APIs that have been widely implemented by software vendors, it will also compete with the emerging Java OLAP (JOLAP) API. Hyperion is the JOLAP specification lead within the Java Community Process. Expert group members include IBM and Oracle - the leading data-management vendors, both heavily invested in Java and XML and promoting application-server-centric architectures - and SAS Institute. According to the Java Specification Request, JOLAP will "provide a standard API for creating, storing, accessing, and managing all metadata and data related to OLAP systems ... independent of the underlying data resource." At first blush, this sounds like the justification for XML for Analysis, but in fact JOLAP's data and metadata management capabilities aren't found in the XML API and, unlike XML for Analysis, JOLAP will provide a single data-manipulation and query language.

In an AlphaBlox press release, company founder Michael Skok stresses that "a company's analytical infrastructure must integrate with its J2EE-compliant application servers ... for optimal performance, scalability, reliability, and security." Skok spoke at the same Hyperion conference that launched the XML for Analysis specification, which his company endorsed, yet while praising JOLAP's approach (although not naming it), he had nothing public to say about the XML API. I'd infer that vendors like AlphaBlox, Hyperion, and SAS Institute - and perhaps Oracle - are holding back on a more ringing JOLAP endorsement because enabled products will take even longer to reach market than products that implement XML for Analysis. OASIS, the XML coordinating body, allows standards developers more freedom than the Java Community Process, which regulates JOLAP development, and JOLAP is more comprehensive than XML for Analysis.

Although limited material is available to compare the two APIs, JOLAP may be superior in the following:

• Robustness for support for sessions and multistatement transactions
• Efficiency given the verbosity of XML-marked-up documents and the need to translate to and from native formats
• Integration with metadata repositories and metadata services
• Suitability for simultaneously accessing multiple distributed and federated data sources.

Rate This Article Rating: 1 (best) 2 3 4 5 (worst) Comments: Optional e-mail address:

In addition, Java has very well-developed facilities and APIs for parsing, manipulating, and generating XML.

I believe that JOLAP will prove a better bet for integrating analytics into Web services than XML for Analysis because its capabilities will go far beyond the XML API's. But software using the XML API should hit the streets first and, given the importance of the .Net strategy to Microsoft, the specification should see rapid improvement. Although J2EE platforms support XML and related protocols and could easily support both interfaces, on their own, the XML API and SOAP should do much to broaden access to analytic capabilities.

Seth Grimes [grimes@altaplana.com] is a principal of Alta Plana Corp., a Washington, D.C.-based consultancy specializing in large-scale analytic computing systems.

RESOURCES

Hyperion Software: www.hyperion.com

Java OLAP Interface: java.sun.com/aboutJava/communityprocess/jsr/jsr_069_jolap.html

Microsoft: www.microsoft.com

Organization for the Advancement of Structured Information Standards (OASIS): www.oasis-open.org

World Wide Web Consortium XML: www.w3.org/XM

XML for Analysis 1.0 Specification: msdn.microsoft.com/library/techart/XMLAnalysis.htm

Related Articles on IntelligentEnterprise.com:

"Untangling the Web," March 27 2001: www.intelligententerprise.com/010327/feat2_1.jhtml