JSP and Java EE

If you are looking for a good intro into the semantics of JSP then may I suggest here.

So what are Java Server Pages (JSP)? If you have done any work with PHP then you'll be right at home with JSP.

JSP is a method of creating Servlets with specially formatted HTML pages. You add in Java code scripts inside tags delimited by <% and %> (properly called: scriptlets I know, I find myself calling them Java Script sometimes too, but that's a whole different thing)

Expressions, one line shots of Java code that return a String, are encapsulated in <%= %>

Here is a quick sample of the two intermixed:

<%
 int j = 0;
 while (j != 12 {
%>
<div style="border:1px dotted #338833">
This is line #<%= j %>
</div><br />
<% } %>

If that brings up memories of PHP, you wouldn't be the first. JSP also adds Directives <%@ %> and Declarations <%! %>. The latter being important because this is how you add methods to the servlet that will be created from your JSP.

The servlet that is created for also has some special data members added to help you out. The tutorial covers how to use these quite well. It is important that you use these members because most of the time you're JSP is assumed to be thread safe (try not to break that assumption.)

The really cool thing is JSP tags! Unlike PHP (but like ColdFusion, if you've ever used it) you have access to a tag library. These tags quickly provide functions that you're most likely to use (like include another page.) You can also write your own library of JSP tags to encapsulate logic in your pages. This effectively allows you to separate logic from presentation (the ultimate goal in web application.)

But this brings us bark to the idea of MVC vs. Three Tier. JSP acts as our presentation in Java EE, however JSP brings us almost too close to Three-Tier design. Things that you want to go from page to page (shopping cart contents come to mind) have to either be pushed down to the database or passed through cookies/URL. This can make a lot of developers feel uneasy because it is a lot of work for such a small gain (easy presentation of Java objects.) If only there was a way to keep the ease of MVC design, have the ease of JSP presentation, and still have the flexibility of Three-Tier design.

Lucky for you, there is. There has been a lot of Java community members banging their heads over this, and over the years it has yielded about a dozen or so very mature frameworks. All coming together in the Java standard call Java Server Faces (JSF).

As you can see JSP offers a very powerful method of building presentations of Java objects. Many companies use JSP as the display end of their products. Later I'll cover JSF and show you how to bring the ease of MVC design into a Multi-Tier development platform.

If you haven't guessed from the avatar, I'm a fan of family guy. I know I'm so original.

Understanding OOP pitfalls in Java EE:

Object Orientated Programming (OOP) is the foundation on which the Java language is built upon. When you build a Java program you are building a set of objects that will work together towards a goal. This brings me to the first point: in Java EE it is important to remember to think of the object and not the task.

A common pitfall is to start adding logic into a class that broadens its scope. Remember, objects should be single shot, single idea things. Let's say you have an object call BankAccount. You would put into this class the account number, the account name, address, details, balance and so forth. However, you may be tempted to place logic that converts the object into, say a SQL string or properly formats an address for display in a GUI. NO! Do not add logic to the class if it does not need to be added to keep the concept that the class represents, sane. A bank account does not need to know about SQL, a bank account does not need to know about GUIs.

The reasoning behind this is that the Java EE platform takes a lot of the bridge work out for you, you adding it back in prevents you from fully accessing all of the features (besides if you're adding them in who is Java to tell you wrong?)

Complex logic goes into classes that will handle other classes. In the example above you might include the BankController class. It will be this class' job to gather the needed objects to handle the object you pass in. The BankController
class may need to gather the objects that handle permissions, validation, database connectivity, and so forth. The Java EE platform has this covered for you. So you just worry about modeling classes after the real world thing they represent.

MVC, why is it so important and why n-tier matters:

If you've been programming for a while, you've undoubtedly have come across the Model-View-Controller (MVC) design pattern. When I started programming my code started out as just one long procedural call, the "everything in the main function" design pattern. As I got better with programming I started breaking logic into different functions and calling the functions. Eventually, I got to Object Oriented Programing (OOP) and began the path of looking at programming not as a bunch of steps that need to take place to reach a goal; but instead as distinct ideas and concepts that put together, made a program.

The MVC design pattern was developed to give developers a way of looking at a problem and separating common areas of a program. Basically, a program has to deal with the end-user and a database. We could easily design a monolithic program that did the task, but if something changes in the database, then we need to modify all of our code (or at the very least hunt down the section in our code that deals with the database) to adapt to the change. Logically speaking, it wasn't long until people started to understand that the user interface should be a separate body of code from the part that deals with the database. As user interfaces got more and more complex, the logic that handles validation and talking to the database module had to be separated too. Thus was born the MVC design pattern. In essence, gurus would preach the divide and conqueror technique of MVC to new developers in hopes that they would start their programs in the vein of MVC. This way as the program evolved, it evolved with ease.

However, there is one fall down to MVC. It assumes that all things are on the same machine. When we start connecting to a remote database to update our view, we start getting into handling SQL statements, exceptions, invalid return values, and many more issues (does NULL mean that the line should be blank or does it mean invalid?). The view is not the place to handle this type of code, or at least if you want to keep things simple. Thus, people holding to the MVC design pattern have created ways of wrapping database connections into convenient APIs that handle the mess, so that you can devote more time to making a good user interface.

It's a nice thought, but it only goes so far. Just pick up a book on MySQL and PHP and notice how many times they suggest that you just ignore exceptions. Eventually, way back in the day don't let me make you think that this is a new development, it was understood that one machine just couldn't run everything (contrary to IBM's claims), and thus we embarked on a mission to find a way to make a program run on multiple machines. Enter multi-tier design patterns.

At first, people used messaging systems to communicate between different machines. Think of it as Bob's copy of program A is running on Server A, Jane's copy of program A in running on Server B, and so on. Server A and Server B talk to each other to keep data in sync using a messaging protocol. This was an alright solution, but it really didn't get far from the MVC way of looking at things. It was also a waste of resources, the View didn't use as much resources as say the Controller; the Model used the most disk space; the View was limited to the interface capabilities of the machine holding the Model and the Controller. Basically, if your database had eaten all of your hard drive, you upgraded the drives; controller eating all your memory, you added more. It would have been better to place the Model on a machine with tons of hard disk space, the Controller on the fastest CPU, and the View on a system that supported familiar GUI elements.

Multi-tier design patterns were developed to allow each layer in the tier (Presentation, Logic, and Data) to run on different machines. Some used proprietary protocols to achieve this (SNA comes to mind). With the advent of the Internet, the standardization of TCP/IP as the protocol of choice, Microsoft bringing open network connectivity (I know, who would have thought), and the desire for things to be less single vendor and more heterogeneous, new methods would need to be put into place to actually implement multi-tier design patterns.

This is where multi-tier underwent its first redesign. Now instead of assuming that the protocol would be packed with the vendor, multi-tier patterns had to abstract protocols altogether; in essence the developer shouldn't have to worry about the protocol, as long as the program can see the server everything should work. While we haven't gotten away from the idea that a program is tied to a protocol (Web browsers still assume TCP/IP as the transport), we have made progress (Web browsers can used IPv4 or IPv6). So it's important to remember that multi-tier is still protocol dependent, just now you don't have to worry about directly working with the protocol (unless you really want to!?).

This redesign is what gives us the model that we all know and love. It breaks the way an application works into three parts. Presentation, Logic, and Data. At face value it looks a lot like MVC, and to an extent it is. However, in a multi-tier application the Presentation is assumed to never talk to the Data, all things must pass through the Logic layer. Where as in MVC, the Controller provides input to the Model, and the view gets the output of the Model. This is the fundamental difference between the two.

In MVC your View must deal with the data straight from the Model. In multi-tiered applications the Logic formats the Data into something that can be Presented.

In MVC, your web designers must know what kind of assumptions should be taken on data from the data source and how to issue the commands to get that data.
In Multi-tiered applications, the Logic handles all of this, your web developers simply access the properties of you logic (much better to write something like #{shoppingCart.orderNumber} versus SELECT ORDERNUMB FROM ORDERS WHERE SHOPPINGCART='cartnumber';).

All in all, multi-tiered design patterns have been developed to make use of multiple machines, abstract protocols from developers, and allow specialty developers to concentrate better on the task at hand. I know that some people still have the notion of what three and four tier development was like in the 60's, 70's, and 80's (which wasn't good and took long amounts of time to deploy) but the methods and tools have been refined to a point to make multi-tier more like Rapid Application Development (RAD) software. Simply put, MVC is an easier model to work within, but Multi-tier is continuing to keep the pressure on MVC as an easy model to develop within. Multi-tier isn't like it was back in the day, it has mature enough to be seriously considered before you begin your next enterprise application.

Logic, Database, Your customer:

That's the basic breakdown when it comes to providing central application services. You centralize the applications so you don't have to network share every single application you want your clients to use (it just doesn't look professional).

When you centralize your applications in your company, you add many different complex challenges to providing those applications and keeping things manageable and agile.

• How do we secure our applications?
• How do we make them available to the clients?
• How can we remove redundant functionality?
• How can we simplify the deployment process?
• Database, logic, and client...Oh my!

If you come from a LAMP or RoR background this may all be very new to you. Basically the setup works as such:

1. The client (web, thick, thin, or services) calls up an action like: *Create new shopping cart, *Add product #23, #46, #107, and #428-A to the cart
2. Check out using the following information: (name, address, CC# etc...)
3. Send back the result of the transaction.

In LAMP and Rails one would have web pages that implement the logic of connecting to the database, validating the information, managing the session, and so forth. Basically all the logic is in the web page.

In a multi-tier environment, you have separate processes that manage all of that. You have a web server that sends out the web page, you have an application server that handles the logic of your session and validating values, and you have a presistance layer that handles the logic of connecting to your database. Each layer can service any other application as well. You build the logic and use it in every application where it is needed.

This simplifies management because now you can take a project and break it into many smaller parts, instead of passing around one large PHP file with about a dozen includes.

It makes sense to break your large projects into smaller more manageable chunks. It's nice to know that you can write and execute common code once, instead of writing 30 or so include file and having who knows how many threads of execution going over the same include file. With a multi-tier platform one can manage the ever increasing demand of constantly growing flat file systems, add new features without major code surgery, and reduce the amount of covering the same ground (not only in code, but in CPU cycles as well).

Giving credit where credit is due, RoR is really starting to mature in the MVC realm of web frameworks, but it still has many short comings like reducing number of threads doing the exact same thing, or rich messaging between processes (however they do have a nice RESTful services API, but so does Java and dotNet).

In the end, modern web application frameworks provide robust one shot solutions to many problems, but as your demands grow managing those applications becomes harder and harder. Multi-tier applications make it easy to scale to large deployments with a little investment up front. Modern multi-tier has come a long way since the days of spending months on each single layer, frameworks have become more compact and interchangeable, providing quick application development, testing, and deployment.

Java EE 5:
I'm really big into Java. I know a ton of people boo Java because they think it is slow or some other reason. I'm here to tell you that Java is very prevalent and very useful. Many websites are powered by Java EE and with good reason.

Over the years Sun and the Java Community have added really exciting technologies to the Java Platform. Some have seen their day come and go, but many have really useful corner cases. However, the best platform I've seen in some time is the Java EE 5 platform.

Java EE is one of the few multi-tier application platforms still in town. The really hot craze right now is your good old LAMP stack or RoR. However, these approaches return to the days of monolithic hosting of network applications. This approach is nice for small to medium deployments, but without some serious modifications, do not scale well in large deployments. This is one of the reasons why LAMP has taken off so much, the stack is completely open source, so modifications can be done on the code easily to adjust to large deployments.

Multi-tiered software was made to scale. It has lost favor since it takes a lot of resources to get started at first (due mostly from configuring and creating the first bits of each layer.) Java and .NET have taken steps to address this large problem, how do we make multi-tiered APIs but still make it easy for small deployments?

Java EE 5 and the future EE 6 bring a lot to the table to make it easy to stop boiler plating things and start deploying services to meet your customers demands. I know it sound a lot like a big commercial.

Multi-tier software has gotten a bad rap from things like DCOM and CORBA. But if you sit down and try Java EE 5, I'm sure you'll see that multi-tier has come a long way from where it was.