All classes above PAProgramsCompaigns are reused by other blocks in the application and don't contain any code specific to the P&C compartment. As a result, the whole compartment implementation takes just 10 lines of code.

This example clearly demonstrates that code reuse in the Vitrage Framework can make a block implementation very simple. These examples were taken from an application that actually contains a dozen compartments that differ only slightly from the P&C compartment. With Java inheritance, implementing a slightly different compartment can be accomplished with a small number of Java statements. As discussed above, with custom tags, it would probably take another 29 tag occurrences and 129 lines of JSP code for each compartment.

The JSP fragment that invokes the block looks as simple as:

<blocks:useBlock blockId="PE12"/>

The parameter PE12 is a unique block identifier.

The last type of JSP-block in Vitrage is Composites. These blocks manage collections of other blocks and apply some logic to coordinate the code generation between inner blocks. Composites provide inter-block layout automation; this part of the framework was developed with a view to creating lightweight portlets usable outside portal platforms. In their present form, composites are used to manage HTML surrounding blocks, e.g., when several blocks share a single frame that should be rendered if at least one of them produces any content.

Building Compartmentalized Applications with Vitrage
Vitrage Framework can help save resources and improve the process of developing Web applications.

Use
When assembling a JSP from blocks, the most common syntax is to use a custom tag from the blocks library provided with the framework:

<blocks:useBlock blockId="PE1"/>

In this example, PE1 is a unique block ID that identifies a compartment in the page design. Alternatively, a JSP-block can be invoked directly from a scriplet:

<% BlockFacade.useBlock("PE1", request) %>

Runtime code behind these constructs is not exactly the same. Custom tag style invocation has a small overhead: an object of class InvokeBlockTag that implements custom tag blocks:useBlock will be created for each invocation of each JSP page. With a scriplet invocation, such overhead is eliminated. In either case, the HTML developer uses identical code, varying just the block ID.

Vitrage Container
Vitrage includes a containier that manages the lifecycle of JSP-blocks, including block initialization, caching and invocation, similar to the way the JSR 168 Portlet Container manages portlets. This similarity runs further: in Vitrage, only one instance of each JSP-block is created for the entire application. All JSP invocations reuse that single instance without the unnecessary creation and garbage collection overhead. JSP-blocks are thread-safe, and one instance of each block is created during application initialization and kept alive in the block cache. In some cases, that could save a significant amount of resources. By contrast, custom tags aren't thread-safe by design, and a new instance of each tag is created on each JSP invocation.

Resources & Prototypes
One of the selling points of tag library technology is the separation between content and layout. Normally, JSP content comes from a database and is rendered by custom tags, while the layout is specified directly in the JSP. This prevents content from affecting layout, as is often required by the presentation logic.

Since this approach doesn't work for compartmentalized applications, Vitrage has to use another way to support such separation. On the page level outside of the block scope, static layout elements are still kept in the JSPs. A compartment may contain both static and dynamic internal layout elements. The dynamic elements are generated in JSP-blocks, while static elements are located in resource bundles and loaded at application startup. This also lets the Vitrage Framework support JSP-block internationalization. While similar to how internationalization is provided in Struts, it could be more runtime effective; the only instance of a block is created on application initialization, while with custom tags, a resource will be read on each JSP invocation.

Development Tools
Vitrage provides a structured means for integration between compartments realized by JSP-blocks and the application's back-end, which relies on strongly typed universal transport objects such as IblockData, Contentlet and ContentReference.

Taking advantage of this architecture, Vitrage supports two modes for serving content to JSP-blocks. In the production mode, each block obtains its content from the request, where it was put by the controller. In the test mode, all invocations of getData() are intercepted and forwarded to TestDataProvider component, which supplies test data in the format expected by the block. It takes some work to fill TestDataProvider with test data, but lets front-end development move forward independent of the application back-end. This way, Vitrage supports testing and integrating front-end components on several levels:

• As individual JSP-blocks with JUnit test suite, with output redirected to an HTML file, which can be viewed in browser; this method doesn't require any application or Web server or any application back-end
• As complete JSP pages inside the Web container without any Model or Controller components
• As a complete MVC application, bypassing the lack of test data in the database
• Conventional end-to-end integration testing.

Conclusion
Modern Web applications use increasingly complex pages with compartments and exhibit sophisticated presentation logic. Tag libraries, JSP templates and portlets don't give developers adequate support for effectively implementing such dynamic front-ends. Being highly compatible with various J2EE platforms, MVC frameworks and tag libraries, the Vitrage Framework offers extensive support for compartmentalized applications. In many cases it also improves support for the application development process and provides significant performance gains for the resulting application. In some cases it permits the development of applications that wouldn't be feasible with tag libraries, templates or portlets. Additionally, developing applications with the Vitrage Framework can economize resources and time.

References

Vitrage Whitepaper. www.roundarch.com/about.html

JSTL specification. http://jcp.org/aboutJava/communityprocess/final/jsr052/

BEA Tag Library. http://e-docs.bea.com/workshop/docs81/doc/en/workshop/reference/tags/navJspTags.html

More on Tag limitations. www.theserverside.com/articles/article.jsp?l=BestBothWorlds

Separation of Business Logic from Presentation Logic in Web Applications www.paragoncorporation.com/ArticleDetail.aspx?ArticleID=21

Tiles 101/201 by Patrick Peak www.theserverside.com/resources/article.jsp?l=Tiles101

A Brief History of Tags by Rich Rosen, JDJ, 2003, Volume:8, Issue:6 pages 10-22.

Enterprise BluePrints http://java.sun.com/blueprints/enterprise/index.html

• Figure 1
• Figure 2
• Figure 3
• Figure 4
• Figure 5
• Figure 6
• Figure 7
• Table 1