Access to IntelligenceThe New OLAP APIs
by George Spofford Continued from Page 1 Broadly speaking, the OLAP query capabilities of each API are similar, and each provides features that the other lacks. (I confess that deadlines prevented me from reviewing the JOLAP specification in enough detail to uncover any key differences; its spec only became available a couple of weeks before this article was completed.) Both of these APIs leave room for future enhancements. Notably, despite the collective experience available within both efforts, neither API specifies support for client input of data or cancellation of long-running commands. Comparing the ApproachesThe two different specifications represent two different technical and procedural approaches. XML/A is a stateless XML-based protocol wrapping ODBO. A client can theoretically have a low software overhead, although if it is going to do anything with the XML results, then practically speaking it will need additional layers to be usable. JOLAP, by contrast, is a fairly function-rich API, with a number of required and optional classes. As a process, JOLAP has spent more time and considering a large number of issues, while XML/A is moving more quickly, addressing less of the big picture but becoming available for adoption earlier. While OLE DB for OLAP is a Microsoft specification, XML/A is jointly owned by its sponsoring organizations, Microsoft, Hyperion Solutions Corp., and SAS Institute Inc. Table 1 highlights a few salient points for each API, both intrinsic and by extension. Figure 1 illustrates the software components of JOLAP in use, while Figure 2 illustrates the software components related to XML/A in use. In short, JOLAP is a fairly rich object-oriented Java API aimed at interactive clients. XML/A is a lightweight interface to ODBO's rich query functionality (and soon OLE DB for Data Mining's) for many programming languages. Vendors are taking each of these APIs seriously, and some vendors are pursuing both. It is especially worth noting this for JOLAP, given that there is a great deal of overlap between the OLAP Council and the JOLAP expert group. For Oracle, Java is still a strategic language. Oracle has been developing and evolving its own Java-based OLAP API (termed OLAPI) for quite some time. OLAPI provides a somewhat richer framework than JOLAP, but according to Oracle, JOLAP will support the needs of about 80 percent of applications, and the remaining 20 percent can access OLAPI through the template methods mechanism of JOLAP. Oracle does not view these as the only Java APIs through which to access its analytics; the recent integration of Oracle's analytics into the SQL engine means that JDBC can be used as well when query results don't need a multidimensional shape. For Microsoft, XML and SOAP are critical to its API strategies. Microsoft already supports an XML/A provider and SDK. Microsoft plans to allow its ADO MD library to use XML/A connections as well as ODBO drivers. Microsoft is planning two additional versions of ADO MD, which it calls ADOMD.Net and ADOMD.J, that will also provide access to XML/A sources. ADOMD.Net will be accessible from its .Net environment. Surprisingly, ADOMD.J is planned to be an EJB version of ADO MD that will only use XML/A for its transport. Both ADOMD.Net and ADOMD.J will provide an object model for query construction as well as metadata, something that has been absent from ADO MD since the beginning. (COM ADO MD will not provide this query object model.) As XML/A provides the low-level structuring of ODBO, most developers working within the .Net framework will probably seek to use an ADOMD interface for the simplified access. Hyperion is looking at these APIs as more than simply an either-or choice, by both co-sponsoring the XML/A specification and by acting as specification lead for JOLAP. According to product manager Ragnar Edholm, the goal is to provide as broad an audience as possible for Essbase. Developers who prefer a more linguistic interface can use MDX with XML/A. Java developers can use XML-related APIs to access XML/A through Java, but Hyperion engineers feel that serious Java developers may well prefer a rich object programming model, namely JOLAP. Of course, the technical differences between the APIs will influence developers' choices as well. Part of Hyperion's leadership role in each of these efforts is to ensure that the models are compatible: ideally, either could be expressed in terms of the other. Supporting MDX for XML/A significantly rounds out the functionality of Essbase, which has required a lot of effort on Hyperion's part but leads to rewards in terms of query functionality. (As widely used as its Report API is, MDX increases the possibilities available in a single query.) Hyperion has previewed XML/A support for select customers and partners and is targeting release of the support for the next feature release of Essbase. Timing for JOLAP support depends on the progress of the JCP effort, but the company plans to release support swiftly upon finalization of the spec. Direction of the MarketAPIs need support from both sides to be worthwhile. With adequate server support, corporate developers will find both of these APIs suitable for mid-tier applications. Client tool vendors are tracking the efforts as well, and the sample of vendors I was able to speak with for attribution shared similar thoughts and concerns, especially the previously described concern over performance. XML/A, with its head start in implementation work and its similarity to ODBO, figures more prominently in their plans. ProClarity Inc. is "definitely going to support XML/A providers", according to R&D VP Russ Whitney. He observes that there seems to be a more serious effort at cross-server interoperability and fuller support for specified functionality with XML/A than with prior efforts like OLE DB for OLAP. Certainly, the fact that XML/A has three sponsors and a mechanism for group input gives it an advantage over ODBO in that regard, although this could be attributed to the greater maturity of underlying ODBO mechanisms on the part of some vendors. Business Objects plans to support XML/A 90 days after a server vendor releases a tier-one implementation, whereas it plans delivery of JOLAP subject to customer demand and database vendor implementation. Its sees JOLAP as supplementing the company's already announced SQL access to Oracle 9iR2 OLAP. Cognos Inc. is investigating use of XML/A, seeing in it the possibility of a de facto mid-tier and Web service OLAP API. The company is also looking at JOLAP for its potential of improved access to Oracle servers, although Oracle's exposure of OLAP functionality through SQL extensions is also of interest to Cognos. In general, as articulated by both Business Objects development director Neil Thomson and Cognos director of R&D Colin Moden, the fact that these APIs increase the number of interfaces to server products makes ISV adoption a little more complicated, because it only increases the number of things that need supporting. The issue of implementation compatibility arises with every multivendor API. There are two areas of compatibility to attend to: Does Vendor A's implementation agree with the spec, and does Vendor B's implementation agree with Vendor A's? The vendors working with the XML/A advisory council plan on using one or more interoperability testing events to work out any kinks in XML/A implementations prior to deployment of products. The Java Community Process yields a reference implementation as one of its artifacts, so out of the gate JOLAP comes with a reference standard that is not itself one vendor's own product. Either Way You Cut ItIt looks like both of these APIs will emerge and find applications. While neither offers a fundamentally different way to access analytics, the existence of the new plumbing itself will provide options that may significantly alter how we can make use of our investment in analytic technologies. George Spofford [george@dsslab.com] is chief architect at DSS Lab, a decision-support services, training, and technology company. He has worked with the OLAP Council and the XML for Analysis Advisory Council on their standardization efforts. NOT JUST FOR HUMANS ANYMOREWhat constitutes an analytic interaction from which humans are absent? Consider intelligent agents; for example, an intelligent agent within a B2B exchange that is searching for parties to include in a proposed transaction. The search involves risk scoring for parties, analogous to a credit risk inquiry. The agent's top-level intent is to answer the question "Will party P be suitable to include in this transaction?" The agent will specify the important criteria (variables and algorithms) in a scoring query. Time series calculations, ranking, and perhaps mining-model-based estimation of unknown partner parameters may all be involved in the query, but the query was generated and consumed by an agent, not a human. Furthermore, a more intelligent agent may need to embody real analytic prowess; the results of one query drive the selection of another set of queries, and their results perhaps another set of selections. To the API this looks like an interactive session; to an end user, like a smart system. RESOURCESCWM specification: www.omg.org/technology/cwm/index.htm JOLAP specification: www.jcp.org/jsr/detail/69.jsp OLE DB for OLAP specification: www.microsoft.com/data/oledb/olap SOAP: www.w3.org/TR/SOAP XML for Analysis Web site: www.xmla.org
|
 |
Most Popular This Week
IE Weekly Newsletter
Subscribe to the newsletter
| |
| ||||||||||||||||||||||||||||||||
