“Before you speak, listen. Before you write, think. Before you spend, earn. Before you invest, investigate. Before you criticize, wait. Before you pray, forgive. Before you quit, try. Before you retire, save. Before you die, give.”

Tuesday, October 13, 2009

Scheduling solutions Timer Service in EJB3.0 vs. Quartz

As a developer you have to choose the best tool for the task at hand (no religious decisions based on vendors should be taken).
When I started to work with Spring Framework in 2006 I learned to implement jobs running at a certain interval by using quartz.As at the time I had only learned EJB 2.0 it seemed a huge feature for me.
The Spring Framework docs shows how you can do this. You can use cron expressions to set a time for execution , a repeat interval and whatever cron under Linux allows you to do.
The problem with this is that it is a bit more complicated and non-standard.

The EJB3 solution is to use the TimerService and call a method on a session bean(or message driven bean) whenever the timer expires. You use the @Timeout annotation for that method.
Here is an example for this. Although it is very easy to set some triggers without much pre-configuration (that's why you have a EJB3 container) it lacks some of the flexibility of Quartz.
I found a copy of EJB3 in Action at work and the author suggests using Quartz for more complicated tasks instead of the EJB3 scheduling support.
I agree on this issue.



Which one would I choose for a new system ? The answer is (consultant fashion): it depends.
Of course if you only have a servlet container (say Tomcat) you will need to go with the Spring/Quartz support (as non standard as it might be) but for a fully blown EJB3 container you can start with the TimerService and replace it as required as the customer requirements change(as non-standard or unprofessional as it might seem to do it).

Wednesday, October 7, 2009

Technologies I never used

As I am trying to prepare for part 2 of my SCEA certification I am trying to get an (practical)understanding of JMS.
As I have a SCBCD certification (and passed first part of SCEA) I have some theoretical knowledge but theoretical knowledge does not always help.
I wrote a simple application to test the concepts of JMS client and Message Driven Bean.
The application consists of a
1) Client - message sender (Java console application)
2)On a Glassfish server I deployed two MDB's one would process the message from the queue and using a stateless session bean get a result to send back to another queue.
3) Also on the Glassfish server I use another MDB to process the response.
This worked out finally (took some 2h to figure out errors) but as I wrote the code I made a stupid copy/paste error : I wrote back a message to the same queue that I read from..
The result of this on a synchronous process would have been a StackOverflow error (no connection to the site) but in this case I just got a huge log file and the messages processed nicely.
Got to love the power of JMS. I discovered even a whole list of patterns (besides the famous GoF and Core J2EE Patterns.) These patterns can be found on Enterprise Integration Patterns and the acompanying book.
Unfortunately in my so far 5 years Java developer career I rarely wrote Message Driven Beans and even more rarely JMS clients so this is definetely an issue if I am trying to say architect a huge B2B JEE application.
How do you get enough experience to say pass a certification or get a job if you don't ever use these technologies ? I have been into plenty of places were Tomcat would be enough and even in a full JEE container people would not play with JMS to interact with external systems so one is forced to get into big companies to get experience with this kind of systems and then become an architect.
My next technology on the list is JCA (never used that either though I do work with JBoss which uses it to connect to the database).
At some point you have to choose between JCA , JMS and webservices to make connection to external systems. I think this article makes a good point about what to choose when.