Dynamic Data Analysis on the Web-a Design Approach

Learn about an adaptable approach which separates programming tasks from Web page design tasks. This strong conceptual model encourages good design, enables re-use of data definitions, and is well-suited to the construction of dynamic user interfaces. The authors also illustrate the particular challenges you might encounter when you dynamically change the analysis performed by Web pages. (This intermediate-level article was first published by IBM developerWorks, August 5, 2004, at http://www.ibm.com/developerWorks).

Introduction

In a multi-disciplinary Web application development team, the fulfillment of several roles need to occur, one of which is that of the page author. This role typically includes HTML or JavaServer Pages (JSP) editing, graphic design, and scripting. An experienced page author knows how to present information effectively while conforming to relevant standards. When it comes to defining data analyses and accessing the results, a programmer is usually required. Our design approach capitalizes on the best skills of each role, and brings the complex task of data analysis and results access within the scope of the page author, while leaving the details of the data access to the programmer.

Online analytical processing (OLAP) applications use a data model that provides an abstraction of the underlying data that separates the definition of the data access and aggregation mechanisms from the selection, presentation, and exploration of the data. Therefore, an OLAP-like model is particularly well-suited to separating the roles of programmer and page author. Full-scale OLAP engines offer a huge range of features for slicing, dicing, and aggregating data, but as with many complex systems, the majority of users only need a relatively small subset of these features.

We will discuss the most commonly used OLAP features and describe a simplified OLAP-like conceptual model. The use of the model will be the foundation for a set of custom JSP tags for page author use.

{mospagebreak title=Data analysis concepts}

Understanding data and being able to express it in an appropriate form is a key task. Many often overlook this task in the rush to get information to the user. By providing a means to focus on the important concepts and a tool set to exploit them, our design approach encourages an up-front analysis of data that pays dividends in the development cycle.

Data Sources

Early in the development cycle, and typically during the requirements gathering phase, you develop an understanding of the required data. The questions that need to be answered during this phase include:

  • What are the user tasks to be supported, and what data is needed to perform those tasks?
  • Where is the source data, and how closely does it match the required data?
  • If there is a mismatch between the required data and the source data, how can the mismatch be remedied?
  • If the source data is distributed over more than one location, how can it be joined?
  • In what ways will the user need to aggregate, filter, and sequence the data?
  • What metrics does the user need to view and manipulate?

Arriving at the correct answers to these questions requires user consultation, as well as the services of an expert in the data domain. The use of low-fidelity prototyping helps to clarify user thinking and hone in on the true requirements. This iterative phase will identify the shape and characteristics of the required data, and from this, the programmer will be able to define one or more data sources which will be made available to the page author. The lessons learned about the user tasks will be important to the page author, who can now focus on the user interface (UI) details secure in the knowledge that the building blocks necessary for accessing and presenting the data will be there.

{mospagebreak title=Dimensions and measures}

Not all data is suitable for analysis and presentation using an OLAP-like model. The data should be rectangular in nature; in other words, it should be representable using a row-and-column structure. A common way of obtaining such data could be by querying relational databases or by reading from spreadsheets or other file-based data.

The OLAP model for analysing data involves the aggregation of values classed as measures according to related values classed as dimensions. Dimensions group, filter, and order data. For example, sales figures might be analysed by sales region and month. The sales region and month will both be dimensions of the data. Measures, on the other hand, are the data that is being sliced and diced. It is sometimes also useful to order by measure values. In our sales example, we might have unit volume and revenue. Unit volume and revenue are both numeric, and inherently aggregatable. Each data source will be defined in terms of dimensions and measures.

Collaterals

Collaterals is the term we use for data. Their use is not for slicing and dicing data. This means they are not dimensions and are not aggregatable. An example of collateral data might be the free-form responses to survey questions or images.

Data resulting from an OLAP analysis returns in one or more slices, with each slice containing one or more rows of data. You can control the arrangement of slices by using slice dimensions. For example, if we request the dimensions Month, Sales Region, and Product, and we specify Sales Region and Product as the slice dimensions, then there will be one slice for each month with each slice containing a row for each combination of sales region and product within the month. The choice of slice dimensions depends on how the data is to be presented.

{mospagebreak title=Filtering and ordering}

When focusing on a subset of data, such as one particular sales region, filtering is required. You might achieve filtering by specifying data to be included or less commonly, data to be excluded. You need to identify the dimensions to be tested for the values.

It is often useful to present data in a certain sequence so the ability to specify the order in which slices and rows within each slice are returned is required. Alphabetic ordering uses the lexicographic sequence of values, while numeric ordering works by numeric comparison. Other custom orderings are also possible. Ordering might be in ascending or descending sequence.

The conceptual model for data

To enable the page author to express data requirements in the terms described above, a set of custom JSP tags can be provided. The programmer will need to implement a tag handler for each of the custom tags and create a tag library descriptor file, which defines the custom tags and associates each custom tag with its tag handler. When you contruct a Web page, you can embed the custom JSP tags, and identify the appropriate tag library descriptor along with a prefix used to distinguish this set of custom tags.

A well designed custom tag library closely reflects the conceptual model to the page author. Listing 1 shows a set of custom tags that present the OLAP-like data model described above. In this example, a data source is identified along with the dimensions and measures which are required for a particular analysis, and the slice dimensions, filters, and orderings which are to be applied.

Listing 1. A representative set of data definition tags


<%@ taglib uri=”/WEB-INF/tlds/dd.tld” prefix=”dd” %>

<dd:data id=”sales”>
  <dd:dataSource>Sales Figures</dd:dataSource>

  <dd:dimensions>
    <dd:dimension>Year</dd:dimension>
    <dd:dimension>Product</dd:dimension>
  </dd:dimensions>

  <dd:measures>
    <dd:measure>Unit Sales</dd:measure>
    <dd:measure>Revenue</dd:measure>
  </dd:measures>

  <dd:sliceDimensions>
    <dd:dimension>Product</dd:dimension>
  </dd:sliceDimensions>

  <dd:filters>
    <dd:includeFilter>
      <dd:dimension>Sales Region</dd:dimension>
      <dd:value>North</dd:value>
    </dd:includeFilter>
  </dd:filters>

  <dd:orderings>
    <dd:numericOrdering>
      <dd:dimension>Year</dd:dimension>
    </dd:numericOrdering>
    <dd:numericOrdering direction=”descending”>
      <dd:measure>Unit Sales</dd:measure>
    </dd:numericOrdering>
  </dd:orderings>
</dd:data>

Taglib directive, data, and data source tags

In Listing 1, the taglib directive establishes the scope of the data definition tags within the JSP with a prefix here of dd.

The data tag acts as a container for all the other data definition tags, which together define the required data and how the results are to be arranged. The id attribute provides a means of referencing the results, and we shall see how this is used in the Data presentation tags section.

The dataSource tag identifies the name of the data source of interest. The data source must contain all of the dimensions and measures referenced within this data tag.

{mospagebreak title=Dimension, measure, and slice dimension tags}

The dimensions tag acts as a container for the dimension tags that define the dimensions that are required in the results. In this example, the Year and Product dimensions are included in the results.

The same pattern is followed with the measures and measure tags: In this case, the Unit Sales and Revenue measures are included in the results.

The sliceDimensions tag acts as a container for the dimension tags that define the slice dimensions to be used as described above. In this case, the Product dimension is included as a slice dimension so there is a slice for each year, with each slice containing a row for each product.

Data conversion

Depending on the interpretation, data values can be strings or numbers. The data access tags should perform the correct conversion, and the page author should make sure that the format of the data values have been understood, and that the data has the appropriate filtering and ordering selected to achieve the required results.

Filtering and ordering tags

The filters tag acts as a container for all required filter tags. In this example, the includeFilter tag is acting on the Sales Region dimension. It includes only those rows whose sales region is North in the results.

The grouping of numericOrdering tags within an orderings tag follows the tag containment pattern, which by now, should be familiar. Note that the sequence in which ordering tags are specified is significant. In this case, result rows are sequenced first by year, and then by unit sales in descending order.

{mospagebreak title=Presenting data}

To present and explore the result data, the page author will require some further custom JSP tags. These custom tags will often be general purpose, and leave the page author in control of the layout and display attributes of the result values. In certain cases, specialised custom tags might provide a more sophisticated presentation of the entire result set.

Listing 2 shows some general purpose custom tags which can be used to iterate through the result values and extract individual values for presentation. In this case, the result values from the data definition shown in Listing 1 are formatted as a series of HTML tables, one for each year of sales results.

Listing 2. General purpose data presentation tags


<%@ taglib uri=”/WEB-INF/tlds/dp.tld” prefix=”dp” %>

<dp:forSlices id=”slices” dataRef=”sales”>
  <TABLE border>
    <TBODY>
      <TR>
        <TH>Year</TH><TH>Product</TH><TH>Unit Sales</TH><TH>Revenue</TH>
      </TR>
      <dp:forRows id=”rows” sliceRef=”slices”>
        <TR>
          <TD>
            <dp:write>
              <dp:valueFromColumn rowRef=”rows”>
                <dd:dimension>Year</dd:dimension>
              </dp:valueFromColumn>
            </dp:write>
          </TD>
          <TD>
            <dp:write>
              <dp:valueFromColumn rowRef=”rows”>
                <dd:dimension>Product</dd:dimension>
              </dp:valueFromColumn>
            </dp:write>
          </TD>
          <TD align=”right”>
            <dp:write>
              <dp:valueFromColumn rowRef=”rows”>
                <dd:measure>Unit Sales</dd:measure>
              </dp:valueFromColumn>
            </dp:write>
          </TD>
          <TD align=”right”>
            <dp:write>
              <dp:numberFormat style=”currency” locale=”server”>
                <dp:valueFromColumn rowRef=”rows”>
                  <dd:measure>Revenue</dd:measure>
                </dp:valueFromColumn>
              </dp:numberFormat>
            </dp:write>
          </TD>
        </TR>
      </dp:forRows>
    </TBODY>
  </TABLE>
</dp:forSlices>

Slice and row iteration tags

In Listing 2, the taglib directive establishes the scope of the data presentation tags within the JSP with a prefix of dp.

The forSlices tag references a data tag by using the dataRef attribute to specify the id of the data tag. In this case, it references the data tag defined in Listing 1. The forSlices tag will evaluate its body for every slice in the result data. It, in turn, has an id attribute by which it might be referenced. In the example, an HTML table with borders switched on is defined for each slice. The page author, knowing the dimensions and measures to be presented, has included a row of suitable headers in each table. This is followed by a table row for each row of data within the slice.

The forRows tag references a forSlices tag using the sliceRef attribute. The forRows tag will evaluate its body for each row in the result data slice from the referenced forSlices tag. It, in turn, has an id attribute by which it might be referenced.

{mospagebreak title=Value formatting tags}

In the example, the page author has chosen specific presentation tags that he or she knows will suit the result values.

The write tag is used to evaluate data values in its body and include them in the page content.

The valueFromColumn tag references a forRows tag using the rowRef attribute, and extracts a value from a particular column in each row. It is configured with a single dimension or measure tag.

The numberFormat tag expects a numeric value within its body and formats this according to the specified style. The documentation for each data source needs to explain to the page author what type of values are found in each of the dimensions and measures. The set of custom tags for data presentation have to include a range of value formatting tags to meet the needs of the page author.

Table 1. Example output of generalised presentation tags

Year Product Unit Sales Revenue
2001 Widget A 100 £1,000
2001 Widget B 80 £1,200
2001 Widget C 60 £1,100

Year Product Unit Sales Revenue
2002 Widget C 80 £1,650
2002 Widget A 60 £600

Year Product Unit Sales Revenue
2003 Widget B 60 £900

In Table 1, an example of the output generated by the tags in Listing 2 is shown. The table lists sales information covering three distinct years and three products for the sales region of interest. Note that the measures have been aggregated for each unique combination of year and product, resulting in six output rows which have been collected into three slices. The rows are in order of year first, and then by unit sales within year in descending order.

Specialised presentation tags

The generalised tags above will meet the many needs of the page author. However, inevitably specialised presentation requirements will need the development of bespoke function.

Listing 3 shows an example of a bespoke tag designed with specific knowledge of the data it is to work with.

Listing 3. A specialised presentation tag


<%@ taglib uri=”/WEB-INF/tlds/dc.tld” prefix=”dc” %>

<dc:satisfactionChart id=”sattrend” width=”100%” dataRef=”satdata” aggregation=”trend”
  monthDimension=”Month” yearDimension=”Year”
  sampleSizeMeasure=”NSI Sample Size” lowSampleSizeMeasure=”Low Sample Size”
  nsiMeasure=”NSI” satVSatMeasure=”SatVSat”>
  <dc:title>Net Satisfaction Index (NSI) – Product Diagnostic Survey</dc:title>
</dc:satisfactionChart>

In Listing 3, the satisfactionChart tag references a data tag using the dataRef attribute. The dimensions and measures that the satisfactionChart tag requires are named by attributes, which allows it to work with different data sources with different dimension and measure names, provided the data in those dimensions and measures conforms to its requirements. A chart title is provided using the nested title tag. An example of the output from the satisfactionChart tag is shown in Figure 1.

Figure 1. Example output of a specialised presentation tag


Example output of a specialised presentation tag

Enabling dynamic data analysis

Flexibility in presenting information is half of the equation, but to be truly dynamic, the user has to be given the means to modify the information being presented.

The data-related tags illustrated in Listing 1 lend themselves to dynamic control in a structured, yet versatile way. The OLAP-like model provides a structure which ensures that any resulting query is well-formed and valid. Custom JSP tags, such as those illustrated earlier, provide a number of opportunities for dynamic substitution including:

  • Selection of dimensions to be included in the analysis
  • Selection of measures to be included in the analysis
  • Provision of filtering values to be used to constrain the result data
  •  Selection of alternative ordering options for the result data

{mospagebreak title=Use of JavaBeans to provide dynamic values}

A common way to transfer information within and between JSPs is by using JavaBeans. Bean attribute values might be set using HTML form submission, or a variety of other means. Once set, those attribute values can be used to control aspects of the data-related tags.

Listing 4. Controlling filtering using a JavaBean


<%@ taglib uri=”/WEB-INF/tlds/dd.tld” prefix=”dd” %>
<jsp:useBean class=”package.beanClass” id=”salesChoices” scope=”page”/%>

<dd:data id=”sales”>
  …
  <dd:filters>
    <dd:includeFilter>
      <dd:dimension>Sales Region</dd:dimension>
      <dd:value
        ><jsp:getProperty name=”salesChoices” property=”region”/>
      </dd:value>
    </dd:includeFilter>
  </dd:filters>
</dd:data>

In Listing 4, a JavaBean is given an id of salesChoices and given page scope. This bean might support a number of properties that have been set by various means, but in this case, we assume that the region attribute has been set by user input using an HTML form control. The includeFilter tag filters on the sales region dimension, and the value to be included is taken from the region attribute of our salesChoices bean.

Populating form fields with dynamic values

To make the example shown in Listing 4, the page author will need to construct a page where the user can select the region from a list of current regions. The page author might choose to hard code a set of known sales region values. This is an acceptable strategy if the set of valid sales regions is fixed. However, if the list of current regions is volatile, or the list of regions that will be returned in the data varies according to other selections, the page author will wish to present the user with region choices that reflect the current state.

To meet this requirement, provide custom JSP tags can that produce HTML form controls populated with the appropriate values. You can obtain these values from the data source by leveraging the existing data definition.

{mospagebreak title=Reporting common errors}

When filtering is applied to data, it is not uncommon to find that no rows of data match the filtering criteria. The page author might wish to deal with this and other exceptional occurrences gracefully. An ifDataState tag can be used to allow various common conditions to be anticipated, detected, and reported in a structured way. Listing 5 illustrates the use of ifDataState tags in a common pattern used to protect against empty result sets and access violations.
Listing 5. A common error-handling pattern


<dd:ifDataState dataRef=”sales” notAuthorised=”true”>
  You are not authorised to access this sales data.
</dd:ifDataState>

<dd:ifDataState dataRef=”sales” rows=”none”>
  Your selections have returned no data.
</dd:ifDataState>

<dd:ifDataState dataRef=”sales” rows=”oneormore”>
  <%– All seems OK, let’s use the data here –%>
</dd:ifDataState>

The example in Listing 5 assumes that identification, authentication, and authorization mechanisms are in place to match the user with access rights for the associated data. The details of such a scheme are beyond the scope of this article. What is important is that the problem has been encapsulated by the custom tag, and that the page author does not have to worry about the nasty details.

In this example, two cardinalities of result rows are then tested. Each cardinality test can only be satisfied if the authorisation test is met and data is successfully fetched. The first cardinality test recognises the empty result set situation. The next performs the data presentation if at least one result row is available. Other cardinalities might be tested for, but these are the most common.

Implementation notes

The JSP specification provides services which enable cooperating sets of custom JSP tags, such as those described here, to be developed and deployed successfully. This article is not intended to be a detailed survey of JSP custom tag development, but this section does address some of the principle issues in the implementation of sets of custom JSP tags of the type we have discussed here. It also provides pointers to appropriate parts of the API and the associated documentation.

{mospagebreak title=Tag containment}

To associate the contained tags with some particular purpose or context, it is often useful to provide custom tags that act as containers for other types of custom tag. Examples in Listing 1 include the dimensions tag, the sliceDimensions tag, and the includeFilter tag. All three of these tags can contain dimension tags, and in each case, the contained tags specify the dimensions which are to be applied in a particular way when fetching the data. Listing 6 shows the dimensions tag again for reference.

Listing 6. The dimensions tag from Listing 1


<%@ taglib uri=”/WEB-INF/tlds/dd.tld” prefix=”dd” %>

<dd:data id=”sales”>
  <dd:dataSource>Sales Figures</dd:dataSource>

  <dd:dimensions>
    <dd:dimension>Year</dd:dimension>
    <dd:dimension>Product</dd:dimension>
  </dd:dimensions>

  and so forth..

The dimension tag will implement the JSP BodyTag interface, as it needs to work with the text contents of the tag (which is the dimension name). The most straightforward implementation is to extend the BodyTagSupport class, and override the doEndTag method to extract the body text. However, it is not the dimension tag itself that needs to know the dimension name. It is actually the containing tag (the dimensions tag in this example) that knows what to do with it. So, a system is needed for passing the dimension name to whatever containing tag can handle it.

The JSP findAncestorWithClass static method is very helpful for locating a suitable containing tag. Notice that this method does not only look at the immediate containing tag (which is known as the parent tag), but continues to look at parent tags all the way out until it either finds one that is suitable or runs out of tags to look at. This is important because the example here has the dimensions tag as an immediate parent of the dimension tags that are within it. Many reasons exist why other tags might come in-between. For example, the page author might use some suitable conditional inclusion tags to selectively activate certain combinations of the contained tags, and the findAncestorWithClass method will step past any such intervening tags and find the required containing tag if it exists.

Of course, quite a variety of tags might want to contain dimension tags. To enable the dimension tag handler to find the right container, a Java interface is created. Listing 7 shows a suitable interface. Any custom tag that is designed to contain dimension tags needs to implement this interface, as well as the JSP Tag interface. Listing 8 shows a typical implementation of the doEndTag method for the dimension tag itself.

Listing 7. An interface for containers of dimension tags to implement


public interface DimensionTagContainer
{
  /**
   * Supply the name of a dimension from a contained dimension tag.
   * @param dimensionName The name of the contained dimension.
   * @throws JspTagException If this tag cannot accept the contained dimension.
   */
  void addDimensionName(String dimensionName)
  throws JspTagException;
}

Listing 8. Implementing the dimension tag handler


public class DimensionTag extends javax.servlet.jsp.tagext.BodyTagSupport
{
 /**
  * Give the body content as a dimension name to the containing tag.
  */
 public int doEndTag()
 throws JspException
 {
  final DimensionTagContainer container =
   (DimensionTagContainer)TagSupport.findAncestorWithClass(this, DimensionTagContainer.class);

  container.addDimensionName(getBodyContent().getString());

  return EVAL_PAGE;
 }
}

You can use this same strategy repeatedly at each level of containment. The data tag needs to contain several types of custom tags, including the dimensions tag we have been discussing. By implementing a suitable interface, the data tag can ensure that it will be found by the dimensions tag handler, which can then report to it the complete set of dimension names to be fetched. The dimensions tag will be told each of these names by the dimension tags it contains, and it will store these in a suitable list until its own doEndTag method is called.

{mospagebreak title=Custom tags: lightweight, cheap, replaceable}

One benefit of using suitable interfaces to enable contained tags to find their appropriate containers is that it avoids having tag handlers explicitly looking for other classes of tag handler. This ensures a greater flexibility of design. Custom tags are the interface between the function that the programmer is providing and the page author who will use that function. So, the custom tag sets should be adapted to the needs of the page author and not encapsulate too much of the implementation detail that lies behind them.

Ideally, a custom tag handler is:

  • Lightweight: inexpensive to instantiate and destroy, maintaining low overhead in terms of memory and other resources.
  • Cheap to develop: most of the effort of the development team can be focused on ensuring the back-end function works smoothly.
  • Easy to replace: as the needs of the page authors change, the design of the custom tag set might change, and this should be quick and easy to do as the tag handlers do not embody the back-end function but only provide access to it.

Referencing tags

Several custom tags have been shown which must reference the data tag, which has been configured with all the details of the data to be fetched. These tags then have to get the data and work with it in various ways. Note that it is not the data tag handler itself which does the data fetching: following the principles just outlined, the data tag handler simply acts as an interface to the appropriate data fetching function produced by the programmer or sourced from a third party.

Scripting variables

As well as allowing other tag handlers to access stored values by using the findAttribute method, a tag can also make stored values available to Java code embedded directly into the JSP (sometimes fragments of Java code included in a JSP in this way are called scriptlets). This requires the use of a TagExtraInfo class, which supplements the tag handler and can be used to specify extra validations and also to create scripting variables. When this is done, the id value becomes the name of the Java variable which can be used to refer to the object from within Java code in the JSP.

Suppose, for example, that a back-end class called DataProvider can be suitably configured and then used to fetch the required data. The data tag handler creates and configures an instance of DataProvider using all the details specified in the contained tags. It then needs to make that instance of DataProvider available to other tags which might need it. This is accomplished by setting an id attribute on the data tag, and then using this id as a key to save the instance of DataProvider into a suitable store.

The setAttribute and findAttribute methods provide the means to save values into a suitable store and then retrieve them later. The setAttribute method can be given the value of the id attribute as the key value, the instance of DataProvider as the value to save, and the scope (request scope, page scope, session scope, or application scope) in which the value is to be saved. For most purposes, page scope is appropriate. If necessary, a scope attribute could also be included on the data tag to specify which scope the instance of DataProvider should be saved in.

Custom tags, such as the forSlices tag (see Listing 2) and the satisfactionChart tag (see Listing 3), have a dataRef attribute which allows the id of a data tag to be supplied. When the tag handler needs to obtain data, it can use the findAttribute method, supplying the dataRef attribute value as the key to search for. This method will attempt to locate a stored value in request scope, page scope, session scope, and finally in application scope with a return value. The tag handler now has access to the instance of DataProvider, which it can use to fetch data and work with it as appropriate.

{mospagebreak title=Benefits of this design approach}

The design approach described in this article uses a set of custom JSP tags to implement an OLAP-like data model, which provides an architected interface between the data access and presentation parts of a Web application. The sections that follow describe the benefits.

Separation of data access from presentation

It is widely recognised that an architectural separation between data model and presentation is desirable within all but trivial Web applications. For instance, the Model-View-Controller paradigm is one widely used approach to achieve this, and the architecture described in this article is compatible with such approaches.

As well as providing a well-defined interface to separate the implementation of data access from that of presentation, the actual tasks of creating such implementations are also separated. Once the initial work of defining the data sources (in terms of dimensions, measures, and so forth) is complete, then the tasks of implementing them and any pages that depend on them can be done in parallel and by different individuals.

Separation of the roles of page author and data access programmer
The OLAP-like data model is inherently simple, but retains a high degree of flexibility. It neatly surfaces the key concepts most commonly required to control the analysis and delivery of data for presentation, while insulating the page author from almost all of the details of how it is achieved. When combined with the separation of data access from presentation, this means that not only can the tasks of page authoring and data access programming be done by different people, but that those people do not need to have the same skills. Indeed, specialists can now be employed to undertake each task, with their efforts focused towards providing and using the data sources that are the central feature of the data model.

The OLAP-like data model, in conjunction with a well-implemented data source, provides the page author with little likelihood of inadvertently configuring an incorrect analysis of the data. This is in stark contrast to technologies such as SQL, where a simple typographical error or misunderstanding of the database schema can lead to very significant and sometimes subtle errors.

From the perspective of the data access programmer, the OLAP-like data model provides a lot of flexibility for implementation. It is conceptually simple and requires only the ability to filter and aggregate data to support it. This leaves a considerable design space for the data access programmer to exploit any capabilities of the underlying data source (such as converting requests into appropriate queries against a relational database, for instance).

Dynamically configurable

The illustrated tag library is particularly suited to dynamic configuration as a result of form submission. The individual component tags that are used to configure a data tag, such as filter tags and ordering tags, can be readily integrated with conditional logic tags and input from form fields. This enables the page author to create pages that permit the user to control some parameters of an analysis (such as selecting a sales region to filter the results to, or selecting whether to aggregate by months or quarters, and so forth).

Reusable data sources

A well-thought-out data source can be used to supply data for a variety of pages. It is not necessary to use every dimension and measure whenever a data source is used — just the subset required for the particular purpose. So, data sources can often be defined that offer a common superset of the dimensions and measures needed for several different analyses/pages.

Encourages good design

The fact that the design approach is centered around the definition of the required data means that this critical aspect of the design must be approached early on and in considerable detail. Neither the implementation of the pages nor the data sources can begin before the definition of the data source in terms of dimensions and measures is done. Furthermore, considering the data to be used in the relatively abstract terms of dimensions and measures encourages good conceptual design independent of the physical details of how the data will be displayed or accessed. In short, this approach encourages design before implementation, as well as conceptual design before physical design.

Standards

These data definition and data presentation tag libraries conform to the J2EE 1.2 standard, making them compatible with a wide range of Web application servers.

The custom JSP tags that are used to implement the interface between page author and programmer are readily understood by integrated development environments and other tooling, thus improving productivity.

{mospagebreak title=In conclusion}

The design approach of combining a simple but flexible OLAP-like data model with a custom JSP tag library implementation provides an architecture with many benefits which is well-suited for Web applications that need to support dynamic analysis of data. A particular strength of the approach is that it not only provides a good structural basis for implementation but also encourages good up-front design. Finally, it can be readily replicated and adapted to a variety of situations because it is based on standard J2EE technologies.

Resources

    * To understand why data is important to page authors, read Designing Easy-to-use Web Sites by Vanessa Donnelly.

    * Get a broad view of the OLAP world from The OLAP Report (http://www.olapreport.com/)

    * Read “Learn from your customers for usable Web apps” (developerWorks, June 2003) to design an effective business site.

    * For more information on the misconceptions about information architecture, read “Information architecture concepts” (developerWorks, July 2002). The article also addresses the role an information architect plays in Web site development.

    * Browse through “JSP best practices: Combine JavaBeans components and JSP technology” (developerWorks, May 2003) to learn more about dynamic site design.

    * In “JSP taglibs: Better usability by design” (developerWorks, December 2001) discover how declarative tags improve the usability of JSP pages.

    * Find articles about every aspect of building for the World Wide Web in the developerWorks Web Architecture zone .

    * Visit the Developer Bookstore (http://devworks.krcinfo.com/).for a comprehensive listing of technical books, including hundreds of Web development titles.

    * Develop and test your Web applications using the latest IBM® tools and middleware with a developerWorks Subscription: You get IBM software from WebSphere®, DB2®, Lotus®, Rational®, and Tivoli®, and a license to use the software for 12 months, all for less money than you might think.

About the authors

Simon Moore joined IBM in 1986 as a software developer, working on the Personal AS product at the Application System International Centre in Warwick, England. During the next eight years, he worked on the development of various pieces of business intelligence related software and specialized in UI development. In 1994, one of these products moved to the Santa Teresa laboratory in California, and Simon went with it on a three-year assignment. During this time, he worked on the development of various products related to the IBM DB2 relational database, including Visualizer, Intelligent Decision Server, and DB2 OLAP server. In 1998, Simon returned to the United Kingdom, and he now works in the Ease of Use department.


Dave Clark first worked for IBM as a pre-university employee in 1988, and returned on several occasions for vacation employment before joining the company permanently in 1992 as a software developer specialising in UI technologies and design, working on the Visualizer product range at the Warwick Software Development Laboratory in the United Kingdom. Since 1995, he has worked in the Ease of Use department supporting the mission of Vice President, Tony Temple. Dave has worked with Java since its inception, and on Web technologies for several years. He has also developed Web applications for Java 2 Enterprise Edition (J2EE) deployed on IBM WebSphere Application Server both within IBM internally and on the Internet.


Photo of Andy SmithAndy Smith joined IBM in 1977 as an operator working with the Call 360 timeshare service. After five years as an operator, systems programmer, and product support analyst, he moved to Warwick, England to join the Application System International Centre. This centre was responsible for the development and support of Application System, a mainframe business intelligence product. Andy worked on a complementary PC product called Personal AS, later renamed to Visualizer. Specifically, he worked on business graphics before becoming one of the overall product architects. When this function was moved to Santa Teresa Lab in 1994, Andy remained in Warwick in what has evolved into the Ease of Use department. He has produced several software components that have been incorporated into IBM products or made available via alphaWorks. His recent work includes an internal project that presents disparate data using a Web application, allowing users to dynamically configure the analyses. This article is informed by that project.

[gp-comments width="770" linklove="off" ]
antalya escort bayan antalya escort bayan