EJB 3 Transaction Management
In EJB 3, declarative transaction management is, as you might expect, one of the built-in features of session and message-driven beans. You configure transaction management using either Java 5 annotations or a more traditional EJB deployment descriptor. This means, for example, that the MoneyTransferService EJB shown in Listing 2 will automatically be transactional.

Now that we've looked at how to make POJOs transactional and persistent let's examine the dangers of using annotated POJOs.

Beware of Annotated POJOs
The examples in this article use both XML and annotations to configure POJOs. However, the trend in POJO programming is away from XML configuration files and towards annotations. Annotations are certainly convenient because they're physically next to the program element (class, field, method) that they configure. The metadata is more concise and easier to maintain. There's certainly nothing wrong with using application-specific annotations. But, the problem with framework-specific annotations is that they couple your application to the framework in the same way that an API call does (www.aspectprogrammer.org/blogs/adrian/2004/08/ when_is_a_pojo.html).

For example, if you use Spring's @Transactional attribute then your classes won't compile without Spring. Similarly, if you use EJB 3 annotations then your classes will be coupled to the EJB 3 framework. These annotations won't stop you from testing your code with simple JUnit tests, but are classes that use them still POJOs?

Moreover, other annotations such as EJB 3's @EJB annotation, which injects an EJB, let you write code that's difficult to test without running it in the EJB container.

class SomeServiceImpl {
    @EJB private AccountDAO accountDAO;...
}

The @ EJB annotation tells the EJB container to "magically" initialize the private field on creation. Not a very POJO-like operation. Similarly, other frameworks' annotations couple your code to the database schema.

These kinds of annotations are definitely handy but using them will couple your application to the framework. That makes it difficult to support multiple frameworks simultaneously. Migrating to a later version or to a new framework can be difficult because you might have to change all of the annotations. This isn't quite as bad as rewriting the code but you still have to change the Java source and most importantly, you have to recompile. If you want to decouple your application from evolving infrastructure frameworks then you might want to consider using pure POJOs and XML metadata.

Summary
Developing with POJOs and non-invasive frameworks such as Spring, Hibernate, JDO, and EJB 3 provide many benefits. POJOs simplify and accelerate development. They make it easier to test classes in isolation without deploying them in an application server, a process that often slows down the edit-compile-debug cycle. And because POJOs are decoupled from the infrastructure frameworks that provide services such as transaction management and persistence you can focus on developing the business logic and address those concerns later.

POJOs also make it easier to upgrade your application to newer version of a framework or switch to a different framework entirely. They give your application increased immunity from the problems caused by rapidly evolving infrastructure frameworks. POJOs enable us to build Enterprise Java applications that last.

References

• Acegi Security System, http://acegisecurity.sourceforge.net/
• Download the sample code from www.pojosinaction.com
• Colyer, A. www.aspectprogrammer.org/blogs/adrian/2004/08/when_is_a_pojo.html
• Fowler M. www.martinfowler.com/articles/injection.html
• Fowler M. www.martinfowler.com/bliki/POJO.html
• Richardson C. (2005). POJOs in Action. Manning
• Richardson C. 2002, www.theserverside.com/articles/article.tss?l=TwoLevelDomainModel
• Vinge, V. (2000). A Deepness in the Sky. Tor Books.