Lessons from a Dummy: First look over J2EE
For the last year or so since I started working with Java everything seemed quite straight-forward. Spring is a nice, simple framework and even though I knew it has servlets, web filters and other JEE mojo behind I didn’t really care much about it. Thus, you can understand my sense of relaxation when I heard in the first year of my master degree I was going to learn Java Technologies. Easy Peasy.
With my cocky Java-developer attitude, I started reading over the courses. JSP, Servlets(“Ok, good to know.”), Listeners, Web Filters (“Ooh, nice! Advanced stuff”),GlassFish, JBoss (“mm..what’s that?”), JNDI, JMS (“That’s it, I’m out! I’m sure they’re just technologies used by Medieval Devs!”), EJB (“I swear to God! If I see one more J-Library I’m gonna quit this awful course! You hear me?”)
Time has passed and, fortunately, I also passed the course. I found all the information quite intriguing. However, my dissapointment was that most of the information I read over the internet was somehow hard to digest.
So that’s why I made an abstract dummy-proof J2EE overview to help you (and also myself) to have a wider view over it.
I apologize from now if I’m going to say something silly. Some of the things I’m going to talk about I haven’t had the chance to actually use in a real project. But hey, this is internet and everybody should have an opinion!
*For this to go smoother I’ll use a Image Saving Service case. Basically, our imaginary app would save images you upload online. Quite basic, huh?
What everyone uses
Servlets & JSP
This is the interface for handling HTTP Responses and Requests. Servlets are mostly stateless. They can handle any HTTP verb(GET, POST, PUT, DELETE and so on). Here you can do all the traditional stuff like handling Cookies, Sessions, change everything you like in the HTTP header or body and so on.
After you’ve done doing whatever you want to, you return e response that can be either plain text, a JSON or even a HTML file generated by concatenating Strings.
By concatenating strings? Ugh..That’s it, I’m going back to PHP.
That’s why JSP was created. It’s almost an HTML file but..wait, for it.. you can write Java snippets inside of it. *mindblowing*.You can actually do all that you could do in a servlet. However, it’s recommended to keep it at a minimum (Separation of concerns). It also has special tags where you can simulate a for-each, an if or even connect to a database.
How would we use it?
So now, when you’d enter “myCrazyImageUploader.com” in the URL input, a GET request would be sent to index.jsp. It will return you the hello-page you needed and maybe set some cookies while at it.
When you’ll drag&drop your picture over our page and press “Upload”, a POST request will be sent to a servlet (ImageUploader.java). After sending further your multipart file (the image in our case), will return you a success.jsp.
In other words, that’s what we have now:
Listeners & Filters
For everything you do with a session, servlet context or servlet request we also have access to specific Listener interfaces.
Besides that, you can use Filters to intercept every request before getting to the servlets and to modify every response before getting to the client. It avoids duplicating code. Beautiful.
Patching up our app
Let’s assume we only accept requests from our known friends. I’ll give every one of them the token Authorization:“Let me in!” in the HTTP header.
I could just check inside every JSP and servlet if it’s there but it’s a lot of duplicated code. Thus, we’ll prefer writing only one AuthorizationFilter.Java to check every request on every future servlet we’ll create. This header was a “Cross-Cutting concern”, we would say. Check more on Bing! Or even better, on Google!
The last thing I not only knew, but used quite often is JPA(Java Persistence API). JPA is just an interface, being implemented by libraries such as Hibernate or EclipseLink. It consists of a layer over JDBC. This could make things slower sometimes but it’s features are gold. Actually no, they’re more like chocolate. Chocolate with bacon:
- ORM — Object Relational mapping. It maps tables to objects so no direct acces to database is needed. That’s also great because you could migrate from one database type to another with almost no effort
- Transaction Management.
- JPQL — A specific way to write queries so that they work directly with the entity objects, instead of old school SQL queries
I would definetly recommend a read from here.
Now our app can have a database
For example, having a database that looks like this : (ID, image_url, user_id) we won’t care anymore how it looks inside the Java code. That’s because we’ll operate with an Entity Class MyImage.java with attributes Double id, String imageUrl, User user. Ain’t that clean and cuddly?
If we want to get all the images for a certain user we’ll make a JPQL query that looks like this :”SELECT i from Image i where i.user = :user”. But that’s just a teaser, I’m gonna let you dig for more after you finish reading this amazing article I’m writing right now just for you.
The hidden gems
Everything went smooth for now. But why I haven’t heard about the others? Well, Java has application servers such as GlassFish or JBoss that are much more powerful than what I’ve previously had experience with. That meaning me copying my war in the /webapps folder of Tomcat or using some deploy automation someone had setup before.
These overpowered servers have a complex dashboard that allows you to do lots of delicious stuff, from creating DataSource pools to serving LDAP directories and even more. More info further down in the article :D.
How do we access this information? JNDI is the answer. Java Naming and Directory Interface. That’s the method to lookup our resources. Inside our container it’s a simple Naming — Object relationship.
For our small app, that would mean, the connection with the database would not be made in Java. It’s created inside the GlassFish dashboard and named “ImageDBConnection”. All the dev has to do is make a lookup using this new name. Easy, right?
But EJB (Entity Java Beans) comes with the real powerful stuff. They are like small Java scripts that are reusable by many Java Web Modules.
They can be Stateful, Stateless or Singleton. The container knows when to construct and destroy them for every request made. For example, a Singleton will only be instanced when the server starts up. On the other hand, a Stateless EJB will get created once for each call is made to it.
Their real power comes when used in a distributed scalable system as they are highly reusable and easy to replicate. EJBs are located inside the Application Server and called by name, preferably by using JNDI.
They are then compiled inside a jar. They get combined with the actual Java Module that can be compiled in a war. If used together they get inside a EAR (Enterprise Archive). Don’t forget, they work only on more powerful application servers such as GlassFish or JBoss.
What could we use it for?
We could make our very own EJB that creates thumbnails from a picture. We’ll put it on our container so that every other service that would need this nice little functionality could later use it.
It would be request scoped, since we need no state whatsoever. That would mean the Bean would be instanced once every request. Explicit name, right?
Now we can communicate from our module to the application server, but how do we get to other modules on different servers? Java to Java module have a specific way to do this, using JMS(Java Messaging System). It has two ways of doing this :
- Point-To-Point Model, sending messages to a queue, that are then consumed by the other client.
- Publish/Subscribe Model. Here a topic can have many consumers. The messages persist even after reading from the queue.
In case in which the other modules are not Java we can use the classic SOAP or REST paradigms. Another alternative is using RPC.
What I like & What I …meh
The new information we got in these 10 minutes is great. At first I thought I’m gonna lose my time learning some old-school libraries but it wasn’t the case. I love that :
- EJBs are highly scalable, easy to use in a distributed system and reusable.
- Separation of concerns. You don’t need previous information before creating the application server resources. If you write the servlets someone else can create the JDBC DataSource, or User Credentials without having access to your code.
- JNDI makes it really easy to access any kind of resources.
- JMS is faster then REST or even SOAP. Being special for java has it’s strong points.
However, I still have second thoughts when it comes to using it in practice. That’s because:
- You need to use GlassFish or JBoss that are bigger on resources. There is no sense in using them for an easy application.
- Extra layer. You need to work with an extra layer. We usually have the Database, the Back End and the Front End. Now we also have the resources and the extra Java code (EJBs) on the actual server. Something doesn’t smell right in this for me.
- Still haven’t figured out whether JMS is better then RPC.
- Why configuring everything inside GlassFish when I can define it in a properties file and then set it up inside java? It’s still kind-of separate, right?
- If we need to put something inside an EJB wouldn’t it make more sense if we’d create another separate micro-service?
- Shoot! I thought I had finally figured it out X(
Well, I don’t know how enlightened we are now. But the good news is people still use J2EE. And if you want to be a big fish in the programming game you need to have a certain knowledge of stuff like this, even if you won’t use it at a daily basis!
I hope I managed to make a clear, simple presentation of all these new concepts. Now you can add all these funky new acronyms to your CV and sound smarter!