Java Application Architecture Lessons

Most large modern web application have the following needs/goals:

  • Front-End Isolation (FEI)–Let the front-end developer do h/er job without having to lean on the back-end developer for data or framework education.
  • Easy Persistent Data Access (EPDA)–Provide an easy way to interact with persistent data.
  • Data Flow Visibility (DFV)–Provide an easy way to map data transfer objects to visual data. The application should provide a clearly visible path from visual elements to persistent storage. This IMHO, is the key to low cost maintenance in the face of dynamic resource availability.
  • Easy Service Layer Access (ESLA)–Provide an easy way for services to be accessed in the back end.
  • Easy Ajax (EA)–Provide an easy-to-use AJAX layer.
  • Modular Design (MD)–All tiers should be modular enough to ease maintenance.

Bootstrap has employed several techniques on various projects in order to achieve these goals. Some are highlighted below.

Servlets/JSP/Hibernate/DWR

A couple of our large projects leverage the standard MVC paradigm with Java Servlets for controllers, JSPs for view technolgy and Hibernate to handle the data. The main issue here is the uninhibited use of JSPs. This leads to a tangle of spaghetti code all over the place, which is a UI and back-end nightmare to maintain. There actually exists a class in one of these applications called “HeaderNightmare” and having worked with it for many moons, it’s easy to see the programmer’s frustration. To be fair, this is simply a lack of discipline as JSP does provide the flexibility to go either way. However, that in itself is a caveat. Programmers (all types) need structure and a good spanking (in the form of errors) to avoid them doing naughty things like breaking up an HTML table element among two or more files and linking them with a jsp:include, or putting tons of server-side logic in the JSP files themselves. Lessons learned from this is that goals FEI, DFV and MD are severely hindered.

WebComponents/JSP/Hibernate/DWR

This combination provides a nifty solution for DFV. However, the presense of plain JSPs still leads to the possibility of chaos. There is still some dependency between the back end developer and the UI developer because the pages just won’t work with “variables” on them. To over come this, the UI person will have to code the pages before the back-end person, which could be a resource planning nightmare. With some discipline, this is actually not a bad combination. However, the home-grown webcomponents framework can be limiting in the face of changes around other technologies. It is almost always best to use community-accepted open-source techologies over in-house ones.

Spring MVC Customized with WebComponent/JSTL/Hibernate/DWR

This comes very close to achieving our goals, except that we still haven’t achieved full support for FEI. JSTL is a rendering engine, which requires a backend server running and some knowledge of the tags by the front-end dev. It is however fairly intuitive and easy to setup, so that provides a useful compromise that could enable parallel development. The use of Spring gives support for easy access of service objects and visibility into the data paths via wiring of data access and other services.

A Note on UIsAll the examples above fail to address front-end architecture. It is naturally assumed that there is a combination of HTML markup, Javascript, and CSS, but the rules applied on how to combine these on the projects above are not clearly defined. Like the back-end, maintainability would be much easier with clean separation of behaviour and style from content. Assuming a disciplined approach to using logic on the pages, its easy to provide clean separation of styling from markup, but not behavior. Frameworks discussed below also address this issue.

Spring/Echo2/Wicket

These frameworks take the front-end developer for a ride in Java land. Echo2, the worse of the two, makes it possible to architect the entire display with just Java code. Wicket at least forces every page to have a backing class, which serves as controller and model for the markup. This does give clean separation and enforces a strict NO SERVER-SIDE LOGIC in the view pages. Wicket and Echo2 both provide clean separation of style and behavior, but it can only be achieved in Java code. The front-end developer has little to do here but learn some Java. This needless to say is a huge hinderance to FEI. The event-based programming style of these frameworks also make it difficult for developers accustomed to traditional request/process/response development. Another big problem with these frameworks is that there is too much magic, which leaves most developers in the dark when a problem occurs. This hinders our beloved need for DFV in a major way.

The appeal that Wicket and Echo2 gained was as a result of the ease of authoring Web 2.0 style components. However, due to the lack of provision for FEI and DFV, I believe these frameworks will not last very long (at least not at Bootstrap).

A Suggested “Silver Bullet”

Well, there is no silver bullet, but based on lessons learned from using all of the above technologies, I propose the following:

  • Spring MVC
  • WebComponents
  • JSTL
  • jQuery
  • DWR

For the view layer, this seems to be the best compromise between the UI personel and the application developer. There are ways to overcome data-related errors with JSTL tags that are not that far of a stretch, thus allowing front and back end personnel to work in a parallel. Spring MVC allows visibility into the data flow from front to back end, easing maintenance.

Perhaps the best feature with this combination is the use of jQuery, which allows the clean separation of behavior from markup, but does not force the UI developer to learn Java. jQuery reportedly co-exists with other Javscript frameworks (e.g. Prototype), so using DWR for Ajax calls would be a breeze (call for case study). DWR provides visibility in the flow of data for ajax calls, which adds to the maintainability factor of the application overall. Using jQuery and CSS also helps maintainance based on their respective mantras of separation.

Martin Constantine
Tech Lead

Resources

Why Use a PHP Framework

Several problems can arise when applications contain a mixture of data access code, business logic code, and presentation code. Such applications are difficult to maintain, because interdependencies between all of the components cause strong ripple effects whenever a change is made anywhere. High coupling makes classes difficult or impossible to reuse because they depend on so many other classes. Adding new data views often requires re-implementing or cutting and pasting business logic code, which then requires maintenance in multiple places. Data access code suffers from the same problem, being cut and pasted among business logic methods.
The Model-View-Controller design pattern solves these problems by decoupling data access, business logic, and data presentation and user interaction.

MVC divides an application into three concerns:
• Model – Encapsulates core application data and methods for accessing it.
• View – obtains data from the model and presents it to the user.
• Controller – receives and translates input to requests on the model or the view.
The separation into three concerns is inspired by a information processing model where the controller represents system input, the model represents processing and the view represents the output of the system.

Pros

- Better Maintainability: Orders of magnitude in ease of maintainability.
- Code Faster: Separation of business logic allows for ease of reuse which in turn leads to faster development and less time on tedious maintenance tasks.
- Redesign UI Easily: Ability to reskin entire application very easily.
- Ease of growth: Controllers and views can grow as the model grows; and older versions of the views and controllers can still be used as long as a common interface is maintained.
- Already in used in Enterprise sites such as Yahoo Bookmarks.
- Database Abstraction: Most frameworks can easily switch an entire application to use MySQL, Oracle, or SQL Server. Code is not database specific.

Cons
- Need to become familiar with specific framework

Leading Options

Michael Sleman
Tech Lead