This week's book giveaway is in the OCAJP 8 forum. We're giving away four copies of OCA Java SE 8 Programmer I Study Guide and have Edward Finegan & Robert Liguori on-line! See this thread for details.
I'm working on my part 2 and I need to design a component that allows the integration with an external JMS system.
- is not transactional.
- doesn’t need to be remotely invoked.
- is a lightweight component and its construction isn’t costly.
I'm planning to design it as a POJO.
It's less "modular" and less "service oriented" but I don't think I need an EJB.
What's your opinion ?
Do you think it can impact the scalability or other system quality ?
This clearly isn't a persistent object, so no JPA is in use.
So, it really must be designed as a POJO. From there, we can provide a Java Enterprise Edition 5 annotation on the bean so it can take advantage of some EJB container services. Which ones might this bean benefit from? Perhaps multi-threaded control? Perhaps the ability to apply security attributes to certain methods? Does this bean need to control any transactional attributes of JPA beans that it invokes? If so, perhaps using an annotation to characterize it as a session bean, and then slapping some declarative transactional attributes on it might be helpful.
There's always huge benefits to using an EJB. But, at the same time, one of the biggest downfalls of J2EE development over the past five years has been the overdesign of components. Too many people have overdesigned components into EJBs, causing huge problems.
But the SCEA exam isn't a place to be asserting any personal beliefs about application design. It's a place to be demonstrating that you know how to use JEE5 components. Sometimes it's not as important to design these things according to what you think might be the best approach in your day-to-day job, but instead, according to what you think the examiners want to see in your final project.