In-Depth
Making the Case for XML/A
Some companies are tapping XML/A to expose OLAP services to Excel, PowerPoint, Word, and other unconventional clients
It’s been a long time coming, but it looks like the XML for Analysis (XML/A) standard is just about ready for prime time.
A number of vendors—including Hyperion Solutions Corp., SAP AG, and SAS Institute Inc.—are today delivering canned support for XML/A, but when Microsoft Corp. finally ships its SQL Server 2005 database next year, XML/A will be said to have truly arrived.
XML/A describes a single API for exchanging data between OLAP clients and servers—on any platform and in any language. Like all putatively open standards, XML/A has been a long time coming: The first draft specification—developed by Hyperion and Microsoft—was published in April of 2001.
Microsoft, for its part, has supported XML/A in its .NET framework for several years now. The software giant also publishes a software development kit (SDK) that lets an XML/A client communicate with Analysis Services—Microsoft’s OLAP engine—running on SQL Server 2000.
But SQL Server 2005 will boast native support for the XML/A standard, which—if history is any indication—could push XML/A over the top. After all, when Microsoft built an OLAP engine into its SQL Server 7.0 database, the software giant’s OLE DB for Analysis API became, almost overnight, a de facto standard. “Microsoft has made XML/A the native API for Analysis Services in SQL 2005. This is pretty significant in that it basically forces the adoption of the technology by third party vendors, integrations, and customers,” says Chris Harrington, president of Web application and information portal development shop Active Interface Inc. “Everybody not on board with Service Oriented Architectures (SOA) is going to have to come up to speed.”
Harrington has been involved with XML/A almost from the beginning, and has for several years offered XML/A proofs-of-concept on his Web site (http://www.activeinterface.com/thinolap.html).
The attraction of XML/A, say Harrington and other users, is that it provides a more or less seamless way to turn unconventional clients—such as Microsoft Excel, Microsoft PowerPoint, or even a vanilla Web browser—into OLAP front-end tools. In this respect, they argue, it’s an ideal glue for the SOAs that some organizations are building.
XML/A enables a “course-granular, loosely coupled approach to information really makes possible the freeing of that information within the enterprise,” argues Harrington. “XML/A and other Web service APIs turn information into a resource which can be identified via a URL. What you do with the information obtained from that URL is limited only by your imagination.”
Some companies are already tapping XML/A to support promising uses. Consider Australian advertising agency Y&R and Wunderman, which—with a helping hand from consulting outfit Maximise Consulting Pty Ltd—implemented Microsoft’s XML/A provider to expose OLAP capabilities to ad teams scattered across the Australian continent.
“Ad-campaign teams are divided up all around the country. They include members such as the analytical team, the client, the campaign managers, [and] other contractors,” explains Maximise consultant Scott Underhill.
“In the past, they have used database systems, which has [resulted] in data being pulled from the system, then used in tools such as Excel, and then sent around to other members of the team through Excel and PowerPoint,” he says.
This approach was kludgey, however. Excel, PowerPoint, and other Microsoft Office applications simply weren’t designed for use in distributed environments, and they certainly weren’t developed with SOAs in mind. So Y&R turned to Maximise, which tapped XML/A to graft an SOA on to its existing fat client infrastructure.
“What we have done with the XML/A technology is too allow [users] to create their own views of the data through different client applications,” Underhill says. “The major client application is the Web with the use of BI-Controls. We allow for all the data on the system to be viewed through a Web page, [and] the data available will depend on who [is] logged on to the system.”
The result, Underhill continues, is speedier—and more transparent—access to OLAP services. “This has helped Y&R greatly, as specific views of the data can be set up on a Web page, then they have the freedom to save the view. Next time their client comes and looks at the data, they can see the views that have been set up. But, not only do we have it set up on the Web page, Y&R uses XML/A to talk directly to the cube from Excel and other applications.”
In lieu of Microsoft’s XML/A provider, Underhill says he could have used any of several different SOAP providers, but this would probably amount to grafting a kludge on top of a kludge, he maintains: “There are older Web connectors which we have used and still use to some degree. These older SOAP connections don't provide the flexibility and security that XML/A provided. XML/A seems to talk to Microsoft Office products a whole lot better with little effort.”
BI architect Mark Morris says his organization is using XML/A to recast one of its most important financial and customer targeting applications as an SOA-friendly play. Like other OLAP developers, Morris has traditionally tapped a patchwork of Microsoft technologies, such as OLEDB for Analysis and Pivot Table Services, along with ADOMD.NET, to accomplish some of the same tasks.
So why use XML/A? Partly, Morris says, because of Microsoft’s obvious support for the standard. Just as important, however, is OLE DB for Analysis’ limited scalability: It’s based on Microsoft’s proprietary COM architecture, and is poorly suited for the highly distributed world of Web services. “XML/A has been finally chosen by us due to a number of factors. These include the forthcoming Analysis Services 2005 support for XML/A and excellent scalability,” he comments.
Morris’ organization isn’t moving completely away from OLE DB for Analysis, however. “Although XML/A was chosen for the application’s primary functionality, we do continue to deploy OLE DB for Analysis [and Pivot Table Services] to support our Microsoft Office user base,” he confirms. “These users utilize a mixture of Excel and Office Web Controls for their custom analyses. XML/A is exclusively used by our internally developed BI portal and has proven to date to be architecturally sound.”
BI architect Harrington, for his part, believes it’s only a matter of time until XML/A gains truly broad adoption. “My own crystal ball tells me that all IT platforms are moving in the direction of Web services, and so whether it is XML/A or some other XML schema, there will be Web service front-ends—either provided by the vendor or by third parties,” he comments.
One holdout is Sun, which—not surprisingly—backs another Web services OLAP standard, Java OLAP (JOLAP). Hyperion itself first joined the JOLAP camp, and has made noises about supporting both standards. Harrington believes that the two worlds can be easily reconciled, however. “Sun’s J2EE is certainly getting with the SOA program—so why not a SOAP wrapper for JOLAP?” he wonders. “I assume that that this is how Hyperion has developed their [own] XML/A provider—as a wrapper on their JOLAP API.”
In the end, he says, XML/A—or something like it—just offers an easier, more scalable way of exposing OLAP capabilities. “Remember that the beauty of XML Web services is that we care a whole lot less about how the data is structured,” noting that XML can always be restructured by means of the eXtensible Stylesheets Transformation Language (XSLT). “That is my approach for transforming XML/A results into Web pages, PowerPoints, Excel workbooks, etc. A different XML schema doesn’t change the information flow architecture when you use Web services—but the information sources must expose Web services to participate in this new paradigm.”
Part of XML/A’s attraction, says Maximise’s Underhill, is that it can enable scenarios beyond seamless communication between front-end applications and OLAP engines. “One of our biggest problems in data mining is the quality of the data and the client’s ability to normalize the data. Something like XML/A is definitely a way forwards,” he concludes. “[It] gives us the ability to browse the data simply and create our own normalized views for modeling.”
Related Articles
XML/A: Truly Portable OLAP Getting Closer
http://www.esj.com/business_intelligence/article.aspx?EditorialsID=6828&t=y