A New Face For OLAP

OLAP on the Web Shows Almost the Same Flexibility as Its Client/Server Counterpart.

Web browsers are becoming a popular user interface to many kinds of data and information stores. Corporate developers are beginning to evaluate and build Intranets using browser-based interfaces and tools instead of using traditional client/server development tools to build customized GUI applications. Vendors, including those who sell Online Analytical Processing (OLAP) tools, are fueling this trend by enabling their products to work with Web browsers and servers.

In this article, I explore how the progression of OLAP must overcome many of the same issues facing traditional applications in their migration to Web delivery. However, OLAP's analytical roots also present a few unique hurdles. Today, most OLAP vendors provide some level of Web browser access to their OLAP engines -- often referred to as Web OLAP or WOLAP. A closer look at how analytical reporting is used in corporate environments reveals that the browser can provide an effective complement to more functional client/server OLAP applications. (Note: OLAP is a specialized form of analysis; many of the same issues pertain to data warehouses and data marts, which store data to be analyzed using a variety of querying, analysis, and reporting tools and techniques.)

What is OLAP?

Vendors take three approaches to delivering OLAP applications. The first uses a multidimensional database server to store data. Data is stored as a cube, which lets the user peel off pieces of it while keeping certain dimensions of the data constant.

In the second approach, data from relational database engines is retrieved in a multidimensional fashion. Metadata defines where the data resides in the relational database. The OLAP server uses this metadata dynamically to generate the SQL statements necessary to retrieve the data as the user requests it. Users see a multidimensional view of data that is stored in relational tables.

The last approach -- less common and somewhat of a hybrid -- uses a multidimensional database server as middleware to access data stored in a relational database. This process, commonly referred to as "reach-through," lets a multidimensional server provide users with the detailed transaction data that contributes to the summary totals stored in the multidimensional server.

Let's look at how these approaches work when the data being delivered goes to the Web.

The Internet Link

Ironically, a few of the driving factors for the Web are also issues of concern. HTML, CGI, and HTTP -- the cornerstone technologies of the Web -- are limited when compared to those used in building client/server applications. It's difficult to deliver the same interface and functionality users like and need in the applications they work on today. Technologies such as Java and ActiveX, which are being evaluated to deliver more functional Web-based systems, are for the most part new and unproved. And although expertise is growing rapidly, people experienced in these technologies are scarce.

The task of the Web server is to build processes that can speak HTTP and HTML on one end and communicate with the OLAP application or database server on the other. The Web server manages communication between the browser and application or database server -- usually through a combination of CGI scripts, Web server APIs, application APIs, and database APIs. On the client side, a combination of HTML, Java applets, ActiveX controls, JavaScript, and VBScript concoct the functionality and interface. (See Figure 1.) (Another architecture being evaluated today lets multiple client applications -- both traditional client/server and Web-based -- use the same protocols to access the same business processes installed on networks as application servers. This capability lets a single architecture deliver systems across multiple delivery mediums.)

OLAP works in this mix by being installed on the network as an application server. You can access the application server via any client application -- including one delivered through a Web browser. The developer can thus use the best technology for each part of the job in delivering Web-based applications.

As Figure 2 shows, the Web server delivers the interface components in HTML files to be loaded by the browser. Once in the browser, the application's components communicate directly with the application server, effectively bypassing the Web server. Protocols such as Distributed Component Object Model (DCOM, or formerly Network OLE), Distributed System Object Model (DSOM), or Common Object Request Broker Architecture (CORBA) are used with HTTP to accomplish the communication. Under this design, tighter communications between the client and server improve performance, provide better functionality, and address security issues (through the process of exchanging information in memory).

The Publishing Aspect of OLAP

Publishing encompasses the steps necessary to prepare or create information to be viewed in a browser. Administrators must somehow generate the reports and graphs to be presented; they accomplish this task by using publishing utilities. Some of these utilities are being positioned as programmer tools. An assortment of proprietary HTML tags, for instance, may be used to tell Web server processes which data to pull from the database. Similarly, programs can use a toolkit that provides HTML functions to customize what gets delivered to the browser. Other publishing utilities may be extensions of existing products. For example, a development environment or scheduler could include a "Save As Web Report" option for administrators who want to build reports using the applications they already know.

Some vendors are positioning new products as the vehicle for publishing reports that will run against their OLAP servers. For example, Spider-Man from Hyperion Software and Pilot Internet Publisher from Pilot Software are new applications used to define reports that contain data retrieved through each vendor's OLAP engine. In any case, static approaches to providing information almost always provide user-friendly dialogs to create reports as HTML files.

OLAP on the Browser Side

As a result, vendors are looking to Java applets and ActiveX controls to improve the user's experience with the browser. These new technologies can be used to provide functionality and a look and feel comparable to those in traditional client/server applications. In this scenario, a user could switch the layout of a report by dragging a "product" panel onto a "time" panel. However, portability across server platforms and Web browsers may be sacrificed as vendors embrace technologies that may be non-standard nor widely supported. More on this shortly.

Approaches to Web-enabling OLAP

• through static HTML reports, created offline
• by populating HTML templates with data on the fly
• through Java or ActiveX components feeding the browser.

On the Fly. In the second and most common approach, the OLAP server populates HTML templates with data on the fly, as users request information from the browser. In this approach, only report templates and metadata exist on the Web server. This metadata tells the Web server which data to put in the HTML file before sending it to the browser.

The metadata exists on the server in two formats. It may reside inside custom HTML tags in the templates on the server. Alternatively, it may be stored in binary format such as fields in a database. Oracle's Express Web Agent can store report metadata in either format. Using proprietary HTML tags, the report view metadata exists in an HTML file. If a view is created using one of the Oracle Express-based products (such as Express Objects), the report view metadata is stored in an Express Web Agent database.

The HTML templates also exist in two formats on the server. If an off-the-shelf editor is used to create the templates, they exist simply as HTML files on the Web server. Arbor's Essbase Web Gateway uses this method of HTML report templates. Users can click in their browsers on an HTML jump containing the name of a report view and an HTML template. It might look like this in the HTML file:

<". . .ESSCGI? -h TEMPLATE.HTML -r Report_A">

Here, Essbase Web Gateway will merge the data from Report_A with the HTML template file, TEMPLATE.HTML, and then send the resulting HTML response file to the browser.

Some vendors offer Web toolkits to create and store the template metadata with report metadata in binary format. In this scenario, both the report and templates can be created on the fly by Web server processes. Kenan Systems Corp.'s Acumate Web includes a toolkit for designing and formatting report pages. This information is then stored in an Acumate Web database. Acumate Web creates the HTML template using this information and merges it with the report data as the report is requested by the browser.

Independently of how templates and report metadata are stored on the server, the information is gathered by the Web server based on a report code sent from the browser. The Web server software uses the report metadata to pull the appropriate data from the database. The database that houses this data may or may not be on the same machine as the Web server application. This information merges with the template, and the whole package is sent to the browser as an HTML response file. The default report usually offers some level of OLAP functionality. As the user interacts with the report, a user code is sent with other information to the Web server, which uses the code to keep track of what information a user is looking at in the browser. The code may exist in the HTML file as part of the HTML command that will connect to the server when the user asks for new data. In this case, it may look something like this in the HTML file:

<HREF = "0001/GOGETDATA">

In this example, the application on the Web server managing the flow of data to the browser knows this user as "0001." The application server runs the GOGETDATA program to retrieve and deliver the data to the browser. Alternatively, the user code might exist as a value of a hidden HTML control in the HTML file:

<INPUT NAME = "USERCODE" TYPE = "HIDDEN" VALUE = "0001">

Unless otherwise specified, the value of any HTML control is sent to the server when the user requests new data. Using this design, the application on the Web server identifies the user by reading the value of the USERCODE control -- in this case, "0001." This process is commonly referred to as maintaining state. Using this code and other information about the browser session, the Web server pulls and formats the necessary information from the database engine and delivers it to the browser.

This architecture is portable across client platforms because the interface is HTML. Depending on how the Web server application is built, the design can also be portable across server platforms. Specifically, CGI is portable; most Web server APIs aren't. For example, a Web server application built using the API provided with Microsoft's Internet Information Server (ISAPI) will most likely run only on Internet Information Server.

The Java and ActiveX Approach. The third approach uses Java applets and ActiveX controls to minimize communication between browser and Web server and to enhance the user experience through improvements to the interface. Vendors are trying two approaches in using these components.

In the first approach, the Web server populates a binary file with the data for the reports, and the interface controls are sent to the browser along with the HTML response file. On the client, a property of the control tells the browser the name of the corresponding data file. The browser downloads this file and the component loads the data. In this design, the components provide functionality such as drilling and layout rotation with a slick interface -- without going back to the server. Also, because data is passed in binary format between client and server, this approach is more secure. Data Dynamics Ltd.'s ActiveX control, DynamiCube, uses this approach.

In the second approach, the interface component communicates directly with the server, interactively bringing data to the client as the user requests it. Here, an interface component requests data from the Web server by opening an HTTP stream. When the component receives the results from the server, it parses the results and moves the data into an object for displaying the information. Comshare uses Java Applets in this manner.

This approach has similar advantages to the first. However, to achieve the same security as the first method, a protocol such as Netscape Communications Corp.'s Secure Socket Layer (SSL) must be used with HTTP. For example, a Web server might use SSL to encrypt HTML being sent to the browser; an SSL-compliant browser can then decrypt this information on the client. Of course, security protocols aren't entirely a function of the application. Any HTML-compliant application can take advantage of these protocols, as long as the application's Web environment supports them.

The component approach also entails several hazards. Even though Java is fast becoming an Internet standard, it isn't as portable as HTML. Vendors who choose to use ActiveX risk making the wrong choice. (A lot of us are watching closely as Microsoft takes the steps necessary to ensure wide support of ActiveX on the Internet.)

The next generation of browser-based reporting may see Web-based applications mixing other network protocols with HTTP to communicate directly with the same server processes used by traditional client/server applications. These more generic network transport protocols can be used with HTTP to facilitate this communication. Again, these protocols include DCOM, DSOM, and one based on CORBA. This design can enhance the user experience when using a browser and enable corporate IS to develop a single architecture to deliver systems across multiple delivery mediums.

Some Final Thoughts

• Information-centric applications migrate nicely to the Web and stand to gain much value from its architecture. That is, systems that present information with a low-level of functionality, in multiple formats, to a broad audience are the success stories.
• Conversely, using a browser to deliver specialized, functionally-intensive applications with a small number of users will create headaches for users and developers alike. Developers must administer additional software on the server, and users get a less capable interface if only HTML is used. The largest headaches will come from the attempt at duplicating functionality on the client and managing the larger demand for information between browser and Web server.

Looking to the future, the largest hurdles faced by OLAP vendors in delivering functionality over the Web will be the browser's procedural environment and the volumes of data that could potentially be needed on the client. Much like a DOS application, users usually move through information in a browser one page at a time, navigating back and forth in a procedural fashion. Although newer browsers offer some support for a window object, implementing a multiple document interface (MDI) application with multiple windows or forms isn't easy. Additionally, information passed between the browser and Web server is text that must be parsed before it can be manipulated. As a result, moving large amounts of data between the two platforms is inefficient. As client/ server technology begins to adapt to browser-based applications, vendors will have the tools they need to address some of these issues. For example, Java or ActiveX could be used to pop up a form over a Web page to prompt a user for information -- an efficient alternative to moving the user to a totally different page in the browser.

Now that OLAP vendors have Web-enabled their engines, they've begun focusing on the authoring and improved delivery of information in the browser. Today, some approaches require that administrators know how to write HTML in order to provide Web-based access to OLAP engines. In most cases, applications with more user-friendly dialogs are needed to create and manage browser access to data and functionality. This capability will be a directive for OLAP vendors over the next year.

Most OLAP vendors provide basic HTML-based Web access to their engines. These vendors are evaluating technologies such as Java, ActiveX, and CORBA to deliver more functional browser-based reporting. I have found as many ActiveX components being prototyped to work with these OLAP engines as Java applets. During the first half of this year, we will get a closer look at both approaches.

Figure 1.

--A typical architecture for delivering live Web-based OLAP functionality.

Figure 2.

--The architecture for implementing universal OLAP application servers. The Web server delivers the interface components in HTML files to be loaded by the browser. Once in the browser, the application's components communicate directly with the application server, effectively bypassing the Web server.

Figure 3.

--An interface that uses standard HTML looks plain and provides rigid functionality. The user needs to define multiple parameters to derive a different view of the data.