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 JEE architecture allows us to write code everywhere:
- Inside the web container we develop servlets and (old fashioned) JSP's using Java.
- Inside the application container we develop the EJB's in their various sorts, also with Java.
- Inside the JVM of the browser we develop rich internet applications with Java.
- Inside the JVM offered by the client operating system we can do the same.
- 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.
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).
- Apache accepts the request and,
- Forwards it to the web server container.
- The web container loads a class file from the filesystem
- The web container instantiates an object from this class file, and invokes a method on the object.
- The method then performs all relevant application logic, including,
- rendering the html for the next web page that is to be displayed inside the browser of the end user.
The same scenario described above now goes as follows.
- Browser sends a request.
- Apache forwards the request to the web container.
- The web container loads a Control class.
- And instantiates a Control object.
- 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,
- Loads a Model class, instantiates an object from it, and invokes a method on the object.
- This method then performs all necessary model logic and communicates the result back to the control object.
- 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.
- 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.
In the next post I will discuss seven (2 power 3 minus 1) alternative ways to use the MVC design pattern. To be continued...