Transparent Data Pipelines for JSPby Satya Komatineni
Despite the undeniable popularity of JSP among Java programmers, there is a substantial amount of doubt, if not criticism, over its suitability as a front-end language for delivering HTML pages. One of the main complaints is that it breaks the MVC (Model-View-Controller) paradigm. Other issues include:
- Exceptions are awkward, at best, to work with on a JSP page.
- Resource reclamation is harder to achieve, particularly for large result sets, in the face of exceptions.
- HTML pages, once embedded with JSP, are harder to visualize through graphical editors.
- For non-trivial pages, it is difficult to see where HTML ends and JSP starts and vice versa, resulting in a very difficult maintenance situation.
- Taglibs present only a partial solution for addressing the inviolable MVC rule, as they only facilitate but do not impose MVC.
Some of these issues arise from the nature of the current JSP usage patterns, rather than the JSP itself. I would like to present here a concept called "Transparent Data Pipelines" (TDP), which borrows elements from the following proven metaphors:
- Horizontal Interfaces.
Once implemented, such a facility will allow one to treat the Java code on a JSP page as merely a subset of the Java language, where the programmer will only use:
Although I do believe a well-designed template language will assist with most of these issues, for the majority of JSP users the TDP solution should solve, to a large extent, the MVC goal. In addition, TDP addresses resource-reclamation and exception-handling issues, while preserving for advanced Java programmers a single programming language solution.
In addition to bolstering the "View" portion of the MVC, the TDP architecture proposes solutions to the rarely addressed "model" part of the MVC and provides declarative solutions for data gathering.
TDP also addressees an increasingly important standard called "InfoSets" and delivers the model data as a hierarchical data set to the view portion. The reason why InfoSets matter here is because the InfoSet is represented as Java Object Tree and not a DOM tree (allowing lazy loading, etc.).
Every architecture is eager to confirm that it supports, if not embraces, MVC. What exactly is MVC and why is it my starting point? As depicted in Figure 1, the Web is built with the request/response model. A request is received by a "controller" on the Web server, which then orchestrates a response to be sent back. To generate a response, data has to be gathered and presented in a requisite format, in this case, HTML. The gathered data becomes the "model" part of the MVC. The presentation logic is said to constitute the "view" part of the MVC.
In a well-architected system, a controller is designed as a servlet, the model as a set of EJBs, and the view as a set of JSPs. Of course, variations of this concept are not uncommon. For example, one might choose to represent the model as a set of Java Beans, as opposed to Enterprise Java Beans. And one might decide to use template engines to present views instead of JSP.
Now on to the details of what MVC does not prescribe as a hard rule. A controller servlet typically receives a request, retrieves an appropriate business object or objects, and passes them over to the JSP. The JSP then uses those data objects to merely paint. How less intricate the JSP page is depends on how well your model data object is designed.
If you have two JSPs, then each page will typically receive its own business object. For example, a customer detail page will receive a customer business object, and an invoice detail page will receive an invoice business object. These types of specific business objects are called "vertical interfaces;" each JSP presents its own interface. For this reason, these objects are characterized as a circle and a triangle in Figure 1.
The role of the JSP is to walk through these distinct interfaces, retrieve data, and paint the page. If one were to call these distinct objects "vertical interfaces," won't there also be "horizontal interfaces"? To answer this question, let us move on to the next section.