J2EE and traditional MVC (Part 1)

A short note to new visitors: this blog documents my vision on how to build database web applications. Normally I do this by presenting a two hour presentation know as "A Database Centric Approach to J2EE Application Development". First given at Oracle Openworld 2002. You can find the original paper here (it's the one titled "A First Jdeveloper Project"). Since the Mayday Miracle gathering in Helsinki Finland, the message now carries the flag: The Helsinki Declaration. Over the next few weeks, (probably months) I will document this presentation that has been given many times by now. This is why you will often see powerpoint slides in the blog posts: they are from the actual presentation materials and help me deliver the message in the same way as when giving the presentation.

After presenting the four historical observations (see previous four blog posts), I now proceed in giving my "layman's understanding" of this beast called "JEE".

The(?) JEE Architecture

Here's a way to look at JEE.


In this architecture we discern three (some say four) "tiers".

• The data tier
• The middle tier (which holds two "containers")
• The client tier

The data tier holds the data managed most likely by some DBMS. The middle tier holds the web-server container and the application-server container. The former runs servlets (and JSP's in the "old days"), the latter runs enterprise java beans (EJB). Both containers communicate with the data tier using the JDBC protocol. The client tier represents the device that sits at the end user: typically a PC running a browser that displays an html page. But it could also run a Java applet inside the browser. And last but not least the architecture allows for a java program running inside a JVM of the operating system.

The JEE architecture allows us to write code everywhere:

1. Inside the web container we develop servlets and (old fashioned) JSP's using Java.
2. Inside the application container we develop the EJB's in their various sorts, also with Java.
3. Inside the browser we use Javascript to increase the user experience of the application.
4. Inside the JVM of the browser we develop rich internet applications with Java.
   
5. Inside the JVM offered by the client operating system we can do the same.
   
6. And of course, allthough the JEE architecture does not mention this in any way whatsoever: at the data tier we can write code inside the x-VM of the DBMS. In the case of Oracle this would be the pl/sql-VM.

What all this means, is that there is no such thing as the JEE architecture.


There are many ways you can use JEE to develop a database web application. It all depends on where you want to write the "application logic" for your application. I will return to exactly this particular subject in-depth in upcoming posts.

A very popular design pattern in the JEE world is the Model-View-Control design pattern. Commonly referred to as just MVC. Whenever the end user triggers some event inside the user interface (UI) typically the application code needs to perform something. Code that investigates the event and determines what to do next is called Control code. More often than not, the application will have to query and/or transact data at this time. Code that performs this is called Model code. And finally the UI needs to be refreshed/modified: this is done by View code. The MVC design pattern dictates that these three types of code are not to be merged in one another, but specifically coded into separate modules that communicate with eachother.


Note the "traditional" adverb in the title above. Of course it's not traditional ... , yet! This is a mainstream design pattern used in almost every JEE project. However I believe it should be traditional at some point in time in the near future :-).

To clarify in more detail what the MVC design pattern is about I show my audience two animations. The first one animates how a pre-MVC built web application would handle a browser request.


The browser sends a request to the webserver (due to some event triggered by the end user).

1. Apache accepts the request and,
2. Forwards it to the web server container.
3. The web container loads a class file from the filesystem
4. The web container instantiates an object from this class file, and invokes a method on the object.
5. The method then performs all relevant application logic, including,
6. rendering the html for the next web page that is to be displayed inside the browser of the end user.
   

The servlet would be "fat": it takes care of the Control+Model+View responsibilies. Since this created hard-to-maintain web application code a better approach would be to follow the MVC design pattern shown below.


The same scenario described above now goes as follows.

1. Browser sends a request.
2. Apache forwards the request to the web container.
3. The web container loads a Control class.
4. And instantiates a Control object.
5. The control object investigates the request, and might decide that some querying and/or transacting needs to be done. However it does not perform this, instead it,
6. Loads a Model class, instantiates an object from it, and invokes a method on the object.
7. This method then performs all necessary model logic and communicates the result back to the control object.
8. The control object then determines what the next page of the application should be and loads/instantiates/invokes a view class (eg. a JSP) to perform so.
9. The JSP might communicate with the model object to retrieve some cached data that needs to be embedded in the html output stream that it sends back to the browser.

There you have it: MVC in its full glory.

In the next post I will discuss seven (2 power 3 minus 1) alternative ways to use the MVC design pattern. To be continued...