ADO MD, the programming interface that Microsoft introduced with SQL Server 7.0, is an extension of ADO that supports OLAP Services' and Analysis Services' multidimensional capabilities. Like ADO, ADO MD is a COM interface built on OLE DB for OLAP. Supported by PivotTable Service, OLE DB for OLAP is a lower-level data-access interface that communicates with the database server by using a proprietary binary protocol. If you use ADO MD, you have to install Microsoft Data Access Components (MDAC) on the client PC. MDAC is large (more than 10MB) and frequently requires a reboot during installation, so it isn't Internet friendly. (An Internet-friendly component is one that you can quickly install across the Internet without prompts so that it doesn't interrupt your Internet browsing experience.) However, ADO MD is fast. Because OLE DB for OLAP caches cube data on the client and understands MDX queries, ADO MD can respond to queries without a round-trip to the server.
The emerging .NET approach, XML for Analysis, helps solve the deployment problems of MDAC but introduces new performance challenges because no caching happens on the client. XML for Analysis is a communications protocol based on HTTP and XML; it provides the client application the same functions as ADO MD does. The primary advantage of using XML for Analysis is that it doesn't require you to install client-side components. Thus, you can develop an XML for Analysis client application for platforms that MDAC doesn't support. For example, you could develop a Macintosh, Linux, or Pocket PC application that communicates through XML for Analysis.
Unfortunately, like XML, XML for Analysis is verbose (e.g., a query result can be very large) and requires a server round-trip. Also, XML for Analysis is stateless, so the client application has to provide additional information for every request (e.g., what database the query pertains to, data source properties). Another drawback to using XML for Analysis is that Analysis Services doesn't natively support it, so you have to use the middle-tier XML for Analysis implementation that Microsoft released in the past year, which doesn't have adequate support for different Internet security models. Microsoft will likely remove this limitation when it releases a version of Analysis Services that includes native support for XML for Analysis. For more information about how this protocol bridges the two worlds of client/server and .NET, see "XML for Analysis," April 2001, InstantDoc ID 19846.
A hybrid of ADO MD and XML for Analysis, ADOMD.NET is a .NET interface that has almost all the same objects, methods, and properties that ADO MD has. So if you're used to ADO MD, you'll have no problem using ADOMD.NET. The significant difference between the two interfaces is that ADOMD.NET uses XML for Analysis to communicate with Analysis Services, whereas ADO MD uses OLE DB. This difference is crucial because it means that with ADOMD.NET, you get no caching or MDX intelligence on the client. Every request to ADOMD.NET will turn into an XML for Analysis request to the server. The most serious limitation of ADOMD.NET is that it isn't yet generally available. By the time you read this article, ADOMD.NET should be in beta testing; Microsoft expects general availability in fall 2002.
How Can You Prepare?
Decision time is now. Many factors go into your organization's plans for the .NET future, and you'll want to choose carefully to be sure the technologies you work with will serve your organization now and as changes occur. Here are some questions you might consider:
- Is the application you're developing new or an enhancement to an older application?
- What's the application's expected lifetime?
- Is backward compatibility important for your customers?
- Is multiplatform support important?
- Do your users need to use the application when they aren't connected to the server?
- How time-critical is the development of the application?
- How much do you know about XML and .NET?
After answering these questions, you'll understand more clearly the trade-offs associated with using XML for Analysis or another analysis API.
Here are some recommendations to help you develop an action plan. First, make sure you understand and use XML. All emerging Internet technologies, including .NET, are based on XML. If you don't understand XML, you'll be lost. Second, if you're developing a new application or a major new portion for an old application, consider using one of the .NET languages. You'll be in a better position to take advantage of .NET technologies, you'll be more productive, and you'll produce a better result.
Third, think about building in some metadata caching to make the switch to ADOMD.NET easier. Consider the effect that client-side caching will have on your application's design. If you're using ADO MD today, you're getting excellent response time from metadata queries. Metadata queries are simple requests for lists of metadata such as dimensions, levels, members, and measures. Because ADO MD caches this metadata, you can make frequent requests at time-critical points in your application with little or no cost in performance. However, if and when you switch to ADOMD.NET, metadata requests will cause server round-trips that might significantly increase processing time and cause an application error such as a timeout.
For example, imagine that in your application you want to implement a fly-over hint that displays metadata such as member properties for a dimension member. In such a case, you might have to rework the program code that supports the hint when you switch to XML for Analysis or ADOMD.NET. (A fly-over hint is that little label that appears when you move your mouse over an icon on a toolbar, for example.) Safer alternatives are to cache part of the metadata or avoid this type of time-critical request. If caching sounds like too much to tackle, you can include a request for member properties in the MDX of each query you perform. Then, the member properties for each dimension member in the query result will be available for a fly-over hint.
Shake Up Your Routine
If you had some advance warning that a major earthquake was about to occur, wouldn't you be irresponsible if you didn't use that information to prepare? Because you know .NET is coming and can anticipate some of the changes it will bring, you should take this information into account as you develop your next analytical application. You might avoid a bigger shake-up down the road.
End of Article
Prev. page
1
[2]
next page -->
