ONJava.com -- The Independent Source for Enterprise Java
oreilly.comSafari Books Online.Conferences.

advertisement

AddThis Social Bookmark Button

Transparent Data Pipelines for JSP
Pages: 1, 2, 3

MVC with Horizontal Interfaces

In an MVC paradigm, the "model" varies, depending on the nature of business objects it is carrying. Horizontal interfaces represent uniformity among interfaces presented by objects. Some of the most widely-known horizontal interfaces are the base interfaces of the COM spec -- IUnknown and IQuery.



If the model of the MVC is such that it always returns the same interface to the view, the JSP programmer's job becomes easier. This is because every JSP will deal with the model the same way. For example, the same methods are used to retrieve key value pairs from the model; the same mechanism is used to retrieve table data and list box data, etc. In other words, the interface of this unified model is the same, regardless of which JSP the model is delivered to by the controller servlet.

This is demonstrated in the following diagram, where a star represents this unified model interface. The only difference between this diagram and the previous diagram is that the controller servlet now delivers the same interface to all of the JSPs.

Diagram.
Figure 2. MVC with horizontal interfaces.

Inquisitive programmers will ask: "this uniform interface is still very abstract; please give us a concrete example of one such an interface." Let me give an example:

interface IDataSetNode
{
   boolean gotoNext(); // goto next row

   // Retrieve values from current row
   String getValue(String key);
   String getValue(String key, String default);

   // Retrieve a child dataset based on a name
   IDataSetNode getChildDataNode(String childName);

   // Close any resources in a recursive fashion
   void close();

   //Xpath support
   String getValueUsingXPath(String xpathExpression);
   String getValueUsingXPath(String xpathExpression, String default);
                                                   
}

Although the API still seems somewhat esoteric, the following data model should make the API very clear. In essence, a dataset is a collection of rows, where each row represents a set of columns and 0 to n datasets derived from the key value pairs in that row.

   <DataSet>
      <!-- 0 to n rows -->
      <row>
      
         <!-- 0 to n columns -->
         <key1>value</key1>
         <key2>value</key2>
         
         <!-- each row will have 0 to n data sets -->
         <DataSet name="set1">
            ...
         </DataSet>
         <DataSet name="set2">
            ...
         </DataSet>
      </row>
      <row>
         <key1>value</key1>
         <key2>value</key2>
      </row>
      ..   
   </DataSet>

Underneath an implementation of a DataSet, one can hide the data, coming from multiple data sources, that will include:

  • URL parameters (Request Scope).
  • Session attributes (Session Scope).
  • Memory-based tables.
  • Global configuration values (Application Scope).
  • SQL output.
  • Stored Procedure output.
  • Java-Object-based and EJB-based output rows
  • Connector-based output.

As you can see from the above, a unified interface gives you an idea of how to represent the data needs for any JSP. One can improve upon these interfaces to suit more complex needs. But the fact remains that one can design interfaces that have commonality and reap the benefits of that commonality.

At this juncture you might ask, how is this different from an XML DOM tree? The important consideration is one of storage efficiency and navigational ease. The presented navigational interface has the following characteristics:

  1. Pull-based data model for higher scalability; the data is never collected until you ask for it from such sources as URL, Session, and Global sources.
  2. Data gatherers not executed unless you ask for them.
  3. Multiple strategies for either preloading the data or demand loading.
  4. Further simplifications with JSP in mind.
  5. DOM interface provided only if an XSL transform is in the offing, thus not paying the penalty of creating all the DOM nodes required.

Transparent Data Pipelines

Our exploration into the nature of MVC and its adaptation to JSP doesn't stop here. In this section, I will transform this idea into the idea of Transparent Data Pipelines. Figure 3 shows what happens when MVC with horizontal interfaces is transformed into a TDP.

The idea is that there is a data pipeline between your data sources and your views (in this case, the JSP page). One end of this data pipeline yields a horizontal interface called IDataSetNode, representing a hierarchical dataset. At the other end of the pipeline are the data sources.

Even in this scenario, the controller servlet will continue to receive the incoming request. Once the preliminaries of the request are complete (authentication, authorization, logging, etc.), the request is submitted to a data pipeline. Attached to the pipeline are such entities as EJBs, Stored Procs, etc. A set of EJBs and Stored Procs are chosen for an incoming request, and their output is collected and consolidated into a hierarchical data set and finally delivered to the JSP.

Another important component of this architecture is the XML definition file defining what entities (such as EJBs and Stored Procedures) belong to what request. The programmer will declaratively define these pipeline connections in a definition file. So, in essence, the TDP becomes the "model" part of the MVC architecture.

Diagram.
Figure 3. Transparent data pipelines.

TDP Composition: The Model Tier

The following diagram explains TDP from a compositional perspective. The core of TDP is that it knows how to combine relational data sets into a hierarchical data set. Let us first find out where we get the relational data sets from.

When we execute a "Select" SQL from JDBC, we end up with a relational data set represented by a result set. When we execute a stored procedure from JDBC, we could end up with a relational data set. When we have a Java class that returns a Java object that implements the concept of rows and columns, we again have a relational data set.

So we have multiple data sources that could yield the concept of relational data sets. This relational data set could be encapsulated into an API (similar to the rowset API of JDBC 2.0). In the example shown below, we have stored procedures, EJBs, Java procedures, and flat files yielding relational data sets.

The transparent data pipeline, assisted by an XML definition file, will organize these relational data sets into a hierarchical data set identified by the IDataSetNode interface.

Diagram.
Figure 4. TDP Composition.

Although the composition is taking place inside of the TDP architecture, the developer is exposed only to the XML definition file and the JSP. Because of this there seems to exist, for the developer, a transparent data pipeline between the data sources and the JSPs.

TDP Characteristics

Let's pause at this point and review the characteristics of the TDP:

  • MVC design pattern is preserved.
  • JSPs work with a uniform set of interfaces presented to them by the model.
  • The model itself is composed declaratively, assisted by an XML definition file and entities yielding relational data sets.
  • When applied with external entities such as stored procedures, the programming model eliminates the complete middle tier, as JSPs now can receive hierarchical data sets by simply composing the stored procedures declaratively in an XML file. This is a powerful metaphor for database shops.
  • The TDP programming model is completely open, allowing all sorts of relational adapters to be plugged in.

TDP, InfoSets AND XPath

As TDP is delivering hierarchical data sets, there is an interesting connection between TDP and XML; this is via InfoSets. The InfoSets specification recognizes that XML data is fundamentally hierarchical and hence any hierarchical data, regardless of its representation, is XML.

Because of this, many of the tools that were previously defined for XML (schemas, xdata, etc.) can now be used against hierarchical data, as long as it follows the InfoSet model. So, potentially, one can apply XPATH queries on this hierarchical data to populate HTML via JSPs.

Realizing that this hierarchical data is indeed XML, one can even turn over the presentation of this data to XSL.

Choice of Transformations

Diagram.
Figure 5. Choice of transformations.

If we can apply a JSP transformation or an XSL transformation on the end points of a transparent data pipeline, what other transformations are possible? The hierarchical data set, due to its horizontal interface, is extremely suitable for your own homegrown template languages that could circumvent a minor irritation of JSP and XSL (namely, the inability to visualize the HTML template in which JSP and XSL is embedded).

Related Reading

Java and XSLTJava and XSLT
By Eric M. Burke
Table of Contents
Index
Sample Chapter
Full Description
Read Online -- Safari

Why do horizontal interfaces aid template languages? Because a template language does not have to distinguish between what objects are being accessed, when all objects sport the same interface. This uniformity also helps in translating pages between templates and JSPs when needed.

Let's take a trivial template language and see how this can be converted to a JSP when the need arises.

<!-looptag_bgn myloop -->
Sample {{var_name}} and {{var_lastname}}
<!-looptag_end myloop -->

The above language will loop through the HTML section between the tags while replacing the {{var_name}} and {{var_lastname}} for each row that is in that loop. By examining the IDataSetNode interface, it is not difficult to imagine how the template engine could use that interface to walk through this HTML segment. By leaving the tags in comments, and exposing the substitution variables, the HTML design is kept intact, even after the tags are placed in the page.

Here is the equivalent JSP for that section:

<%
IDataSetNode pageData = request.getAttribute("PageData");
IDataSetNode myLoopData = pageData.getChildDataSet("myloop");

// Loop through the node data
while (myLoopData.getnext()){
%>

Sample <%= myLoopData.getValue("var_name") %> and <%= myLoopData.getValue("var_lastName") %>

<%
} // end of while
%>

The implication is that TDP eminently enables users to use their own transformations on the incoming data sets.

Pages: 1, 2, 3

Next Pagearrow