David is a systems architect who has been developing software professionally since 1991. He started programming in Java way back with Java 1.0 developing desktop applications and applets. Since 2001 he has been developing enterprise applications using both Java standards and open source solutions. David is the author of "Building SOA-Based Composite Applications using NetBeans 6" and "Seam 2.x Web Development". David is a DZone MVB and is not an employee of DZone and has posted 22 posts at DZone. You can read more from them at their website. View Full User Profile

Quick Look at EJB 3.1 on JBoss AS 6

01.08.2011
| 11528 views |
  • submit to reddit

Now that JBoss AS 6.0 has been released with full support for the Java EE 6 Web Profile, lets take a quick look at some of the new features of EJB 3.1 that are available.

Three of the main features of EJB 3.1 are:

  1. EJB’s can be deployed as part of a WAR file and do not need to be is a separate EJB JAR file.
  2. EJB’s can be developed with no business interface.
  3. EJB’s can be deployed as Singletons.

Let’s take a look at each of these in turn.

1. EJB’s can be deployed as part of a WAR file.

Not much to look at here I’m afraid! The thing to notice is that now with NetBeans (I’m using NB 7 Beta), you can create a simple Java EE 6 Web Project and create EJB’s within the web project.  If you are developing a web project, there is no longer any need for an additional JAR to deploy any EJB’s that you use.

2. EJB’s can be developed with no Business Interface

Creating an EJB without a Business Interface is as simple as creating a POJO, which in fact the EJB is!  In it’s simplest form, an EJB could be defined as:

package com.davidsalter.ejb31test;
import javax.ejb.Stateless;
@Stateless
public class HelloSessionBean {
    public String sayHello() {
        return "Hi there !!";
    }
}

The only difference here from a POJO is that the class is annotated with @Stateless, declaring it as a Stateless Session Bean.

When the WAR file containing this EJB is deployed to JBoss, we get a message on the JBoss console stating that the EJB has been deployed:

21:08:29,653 INFO  [org.jboss.ejb3.nointerface.impl.jndi.AbstractNoInterfaceViewBinder] Binding the following entry in Global JNDI for bean:HelloSessionBean

        HelloSessionBean/no-interface -> EJB3.1 no-interface view

Invoking an EJB within a web project is similarly straightforward.  The EJB can be injected into a Servlet using the @EJB annotation.

public class HelloServlet extends HttpServlet {
    @EJB
    HelloSessionBean helloSessionBean;
    ...

    PrintWriter out = response.getWriter();
out.println(helloSessionBean.sayHello());

3. EJB’s can be deployed as Singletons

Finally, EJB’s can easily be declared as Singletons via use of the @Singleton annotation. Used in conjunction with the @PostConstruct and @PreDestroy annotations, any initialization and clean up can easily be performed on the Singleton. The method annotated with @PostConstruct is invoked after the singleton is first constructed, for example when a calling servlet is first loaded or when a JSF backing bean that calls the singleton is first instantiated. The method annotated with @PreDestroy is called immediately before the Singleton is destroyed and is therefore a perfect place to perform any tidy up operations.

Defining Singletons in this way can be a useful technique for storing data that may be required across multiple clients of an application.

package com.davidsalter.ejb31test;

import java.util.Date;
import javax.annotation.PostConstruct;
import javax.annotation.PreDestroy;
import javax.ejb.Singleton;

@Singleton
public class SingletonSessionBean {

private String creationDate;

@PostConstruct
public void init() {
System.out.println("Initialize singleton");
creationDate = new Date().toString();
}

@PreDestroy
public void shutdown() {
System.out.println("Shutting down singleton");
}

public String getDate() {
return creationDate;
}
}

Again, invoking the Singleton is as easy as invoking the Session Bean we defined earlier.

    @EJB
SingletonSessionBean singletonSessionBean;

The sample code and application used for this post are available from my Subversion repository on Google Code at:

http://code.google.com/p/java-ee-samples/

To run the sample application, check the code out from subversion, build and deploy in NetBeans to JBoss AS 6 and access http://localhost:8080/EJB31Test/HelloServlet

From http://davidsalter.co.uk/blog/?p=476

Published at DZone with permission of David Salter, author and DZone MVB.

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)

Tags:

Comments

Venkateswara Ra... replied on Sat, 2011/01/08 - 9:15am

Thanks, You helped me in understanding EJB3.1

Jonathan Fisher replied on Sat, 2011/01/08 - 2:48pm

Stateless makes a ton of sense if your code is already threadsafe! But, I've seen horrible implementations of stateless code with parameter chains a mile long and overuse of the 'new' operator for local non thread safe objects like simpledateformat. If your code requires use of non threadsafe jdk objects like sdf, hashmap, cipher, digest then SLSB is the best route for memory performance. If you find yourself writing functions with more than 3-4 parameters to make it threadsfe, then SLSB is the answer for cpu performance. Overall, this is an excellent tool that was long needed. I can see this having many uses in my code!

now I just wish the java jmx api was annotatin based and i'd REALLY be happy!

David Salter replied on Sun, 2011/01/09 - 11:40am in response to: Venkateswara Rao Desu

Hi, I'm pleased the post helped. :)

Sivaprasadreddy... replied on Mon, 2011/01/10 - 11:33am

EJBs can be deployed in WAR....wow... :-)

I hope with this EJB development will become much more simpler.

David Salter replied on Mon, 2011/01/10 - 12:32pm in response to: Sivaprasadreddy Katamreddy

EJB development is so much simpler now than in previous years. In most cases you can get away with no XML and just one implementation file.

David Salter replied on Mon, 2011/01/10 - 12:35pm in response to: Jonathan Fisher

Hi Jonathan, As with all implementations, they can be misused. I firmly believe both Stateless and Stateful session beans have a place in Java EE. Developers need to be aware of the differences and use the appropriate one for the appropriate case.

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.