Browse DevX
Sign up for e-mail newsletters from DevX


Getting Started with EJB 3.0 and Enterprise Bean Components : Page 3

The time is ripe to give the EJB 3.0 spec, which was engineered to offer big gains in productivity, a test drive. Learn how to start using JBoss and Maven to develop EJB 3.0 enterprise bean components.




Building the Right Environment to Support AI, Machine Learning and Deep Learning

Stateful Session Beans
Stateful session beans have very similar requirements to stateless session beans. Like stateless beans, they must have at least one business interface. Appropriately, however, they are annotated with the @Stateful annotation instead. So in the music store example the user's shopping cart has been modeled as a stateful session bean since it represents a stateful conversation between a user and the server:

@Stateful public class ShoppingCart implements IShoppingCart { ... }

As in EJB 2.x, invocations on the same reference to a stateful session bean are handled by the same EJB instance, making it important to store this reference in a location that can be repeatedly read by the client. In the case of the music store, this reference is stored in the user's HttpSession.

Message Driven Beans
Message Driven Beans (MDBs) also implement a business interface and are annotated to indicate their bean type. In this case, though, the business interface does not come from the domain but is an appropriate listener interface for the type of messaging system being used. In the case of JMS this is javax.jms.MessageListener. The music store’s order processor provides an example:

@MessageDriven public class OrderProcessor implements MessageListener { public void onMessage(Message message) { ObjectMessage objectMessage = (ObjectMessage) message; try { Order order = (Order) objectMessage.getObject(); System.out.println("Products Ordered:"); for (Product p : order.getProducts()) { System.out.println(p.getTitle()); } } catch (JMSException e) { e.printStackTrace(); } } }

Just as with EJB 2.x, you may supply additional information to the deployer about how the MDB is to be configured. This information can now be provided through the activationConfig element of the @MessageDriven annotation. For example, to define that the OrderProcessor activates only for JMS messages arriving on the orders queue you could annotate the class as follows:

@MessageDriven(activateConfig = { @ActivationConfigProperty(propertyName = "destinationType", propertyValue = "javax.jms.Queue"), @ActivationConfigProperty(propertyName = "destination", propertyValue = "queue/orders") }) public class OrderProcessor implements MessageListener { ... }

But as with previous versions of EJB, the deployer still carries the responsibility to associate an MDB with a destination or endpoint.

Packaging and Deployment
Packaging in EJB 3.0 bears many similarities to packing in previous versions of EJB. Just as with previous versions, the enterprise bean classes must be packaged in a .JAR file. The biggest difference is that with the EJB 3.0 release the deployment descriptor becomes optional. If one is supplied, however, then it must exist in its usual place (META-INF/ejb-jar.xml).

The example program illustrates building an EJB3.0 EJB-JAR and bundles this JAR along with the web application (WAR) in an Enterprise Archive (EAR). This build uses Maven 2.0; see the attached source bundle for more information.

Author's Note: In JBoss EJB 3.0 jars have the extension .ejb3—a JBoss convention and not a requirement of the specification.

To deploy the sample application, simply copy the resultant .EAR file to the deploy directory of a JBoss 4.0.3 server configured with the JBoss AOP 1.3.4 deployer. The attached source bundle also contains installation instructions.

Welcoming a Simplified Model
The public draft of EJB 3.0 reveals a drastically simplified model for writing enterprise components. This new paradigm serves to simplify development and introduces very little new functionality beyond what was previously available. Still, the simplifications offered by EJB 3.0 should significantly enhance a team's productively. It will be interesting to see how this new lighter-weight implementation will fare against other lightweight frameworks such as Spring and Hibernate.

Stay tuned for my next article exploring entity persistence in EJB 3.0.

Rod Coffin is an agile technologist at Semantra, helping to develop an innovative natural language ad hoc reporting platform. He has many years of experience mentoring teams on enterprise Java development and agile practices and has written several articles on a range of topics from Aspect-Oriented Programming to EJB 3.0. Rod is a frequent speaker at user groups and technology conferences and can be contacted via his home page.
Thanks for your registration, follow us on our social networks to keep up-to-date