Featured White Papers

• Measuring Risk to Improve Java Software Quality
• Do You Really Get Classloaders?
• Pragmatic Continuous Delivery with Jenkins, Nexus, and LiveRebel
• Your Next Java Web App: Less XML, No Long Restarts, Fewer Hassles
• Coding with JRebel, Java Forever Changed
• 2012 Developer Productivity Report: Java Tools, Tech, Devs, and Data

Sponsored Links

• Graph databases are 1000x faster than relational.

  Learn More!

• Career opportunities at Harman- Careers That'll Rock Your Socks Off.

  Learn More!

• Developer-friendly Java PDF libraries by Qoppa Software

  Live Demos

• Stop blaming your app! Diagnose Java performance issues.

  Free tool >

• UrbanCode: Go From Continuous Integration to
  Continuous Delivery

  Learn More!

Sponsored Links

Optimize with a SATA RAID Storage Solution
Range of capacities as low as $1250 per TB. Ideal if you currently rely on servers/disks/JBODs

Simplify enterprise Java development with EJB 3.0, Part 1

Use annotations to develop POJO services

By Michael Juntao Yuan, JavaWorld.com, 08/15/05

Page 2 of 6

• Verbosity: XML configuration files are known for their verbosity. To configure the code, XML files must duplicate a lot of information, such as class names and method names, from the code. Java annotations, on the other hand, are part of the code and specify configuration information without external reference to the code.
• Robustness: The duplicated code information in the XML configuration files introduces multiple points of potential failures. For example, if you misspell a method name in the XML file, the application would fail at runtime. In other words, XML configuration files are less robust than annotations, which are checked by the compiler and processed with the rest of the code.
• Flexibility: Since the XML files are processed separately from the code, the XML-based configuration data is not "hard-coded" and can be changed later. The deploy time flexibility is a great feature for system administrators.

Annotations are easy to use and prove sufficient for most application needs. XML files are more complex and can be used to address more advanced issues. EJB 3.0 allows you to configure most application settings via annotations. EJB 3.0 also supports XML files for overriding default annotation values and configuring external resources such as database connections.

In addition to replacing and simplifying XML descriptors, annotations also allow us to do away with the rigid component model that plagued EJB 1.x and 2.x.

POJO versus rigid components

EJB components are container-managed objects. The container manipulates the behavior and internal state of the bean instances at runtime. For this behavior to occur, the EJB 2.1 specification defines a rigid component model the beans must conform to. Each EJB class must inherit from a certain abstract class that provides callback hooks into the container. Since Java supports only single inheritance, the rigid component model limits a developer's ability to build complex object structure using EJB components. That is especially a problem for mapping complex application data in entity beans, as you will see in Part 2 of this series.

In EJB 3.0, all container services can be configured and delivered to any POJO in the application via annotations. In most cases, special component classes are not needed.

Let's check out how annotations are used in EJB 3.0 POJO applications via the JBoss EJB 3.0 TrailBlazer.

Develop loosely coupled service objects

One of the most important benefits of enterprise middleware, such as Java EE, is that it allows developers to build applications with loosely coupled business components. The components are only coupled via their published business interfaces. Hence, the component implementation classes can be changed without affecting the rest of the application. That makes the application more robust, easier to test, and more portable. EJB 3.0 makes it easy to build loosely coupled business components in POJO.

Session beans

In EJB 3.0 applications, loosely coupled service components are typically implemented as session beans. A session bean must have an interface (i.e., the business interface), through which other application components can access its services. The code that follows provides the business interface for our example investment calculator service. It has only one method to calculate total investment return given the start and end age of the investor, the fund growth rate, and the monthly saving amount.