This book from O’Reilly provides “Expert Tips & Tricks for Java Enterprise Programmers”. Apart from pure EJB stuff, the book covers tips for servlets, JDBC, XML, etc. I’ll be wrapping up the tips in a few short notes, espcially those I’ve seen/read around. First I discuss EJB tips.
Use ValueObjects for bulk data transfer.
Instead of making a get call for each property in your remote object, use a session bean to grab all necessary properties in a single call (thus also using the session facade)
Handle Exception in EJB Code Correctly.
My opinion about this is you should handle exceptions correctly EVERYWHERE! This involves understanding of when to throw, catch or wrap an exception. For EJB the logic is:
RemoteException: declared on all remote interfaces exposed by EJB. Used to indicate a network problem. You should not throw it yourself. If you call another remote object and receive a remote exception, wrap it in an EJBException.
EJBException: Thrown by developer and caught by container. Indicates major error to signal container to perform a transactional rollback. Like a NullPointerException, it’s a runtime exception and should not be caught by a developer. A common use is wrapping SQLExceptions into EJBException.
Application-level Exception: Should be thrown/caught by developer as part of application logic. Must be serializable (the exception will travel across the network). Do remember Exception Basics: Don’t use exceptions to indicate normal flow.
Using Business Delegates for Clients
This may look like pure redundancy to new-to-EJB programmers, however this cleanly separates client logic and EJB logic. One way to see this problem is when importing EJB packages in servlet classes. If the back end changes to non-EJB or the front end changes to non-webbased you get a problem. By introducing another layer into the already-many-layers you improve scalability and maintainability of your application (theoratically).
Create a Build Environment.
Even if you have a fantastic IDE that can automatically do all these for you, it’s useful to be able to make small changes to your app and re-building it without firing up and twiddling with the (likely-heavy) IDE. This is even more useful if you really understand your deployment. (and useful for people to learn about the actual deployment)