EJB 3.1 - A Significant Step Towards Maturity

Sky-Tiger

Each Schedule annotation for persistent timers corresponds to a single timer, regardless the number of JVMs across which the application is distributed. This has a tremendous impact on the way timers are used in clustered environments. Lets assume that an application needs to keep an active timer pointing to the next active event. This timer gets updated as soon as new events are submitted. Before EJB 3.1 this would be quite easy to achieve by using the Timer Service, unless the application got deployed in a container distributed in more that one JVM. In that case, whenever a timer got created in one JVM it would not visible in the remaining JVMs. That means that it must have been adopted a strategy which allows the existing timers to be visible in all JVMs. The code becomes aware of the environment where it gets deployed, which leads to bad practices. With EJB 3.1 the developer does not have to care if the application being developed is going to be deployed across multiple JVMs, such task is left up to the container.

An automatically created non-persistent timer gets a new timer created for each JVM across which the container is deployed.

The signature of the timeout callback method can be one of two options- void <METHOD> (Timer timer) or void <METHOD> ().

In terms of timer scheduling there were major improvements. The callback schedule can be expressed using a calendar-based syntax modeled after the UNIX cron. There are eight attributes which can be used in such expressions:

Attribute
       

Allowable Values
       

Example

second
       

[0, 59]
       

second = "10"

minute
       

[0, 59]
       

minute = "30"

hour
       

[0, 23]
       

hour = "10"

dayOfMonth
       

- [1, 31] - day of the month

- Last - last day of the month

- -[1, 7] - number of days before end of month

- {"1st", "2nd", "3rd", "4th", "5th", ..., "Last"} {"Sun", "Mon", "Tue", "Wed", "Thu", "Fri", "Sat"}- identifies a single occurrence of a day of the month
       

dayOfMonth = "3"

dayOfMonth = "Last"

dayOfMonth = "-5"

dayOfMonth = "1st Tue"

month
       

- [1, 12] - month of the year

- {"Jan", "Feb", "Mar", "Apr", "May", "Jun", "Jul", "Aug", "Sep", "Oct", "Nov", "Dec"}- month name
       

month = "7"

month = "Jan"

dayOfWeek
       

- [0, 7]- day of the week where both 0 and 7 refer to Sunday

- {"Sun", "Mon", "Tue", "Wed", "Thu", "Fri", "Sat"}- day's name
       

dayOfWeek = "5"


dayOfWeek = "Wed"

year
       

Four digit calendar year
       

year = "1978"

timezone
       

Id of the related timezone
       

timezone = "America/New_York"

The values provided for each attribute can be expressed in different forms:

Expression Type
       

Description
       

Example

Single Value
       

Constraints the attribute to just one value
       

dayOfWeek = "Wed"

Wild Card
       

Represents all possible values for a given attribute
       

month = "*"

List
       

Constraints the attribute to two or more allowable values, separated by a comma
       

DayOfMonth = "3,10,23"

dayOfWeek = "Wed,Sun"

Range
       

Constraints the attribute to an inclusive range of values
       

year = "1978-1984"

Increments
       

Defines an expression x/y where the attribute is constrained to every yth value within the set of allowable values, beginning at time x.
       

second = "*/10" - every 10 seconds

hour = "12/2"- every second hour starting at noon

Every Tuesday at 7.30am
@Schedule(hour = "7", minute = "30",  dayOfWeek = "Tue")

From Monday to Friday, at 7, 15 and 20
@Schedule(hour = "7, 15, 20", dayOfWeek = "Mon-Fri")

Every hour on Sundays
@Schedule(hour = "*", dayOfWeek = "0")

Last Friday of December, at 12
@Schedule(hour = "12", dayOfMonth = "Last Fri", month="Dec")

Three days before the last day of the month, for every month of 2009, at 8pm
@Schedule(hour = "20", dayOfMonth = "-3", year="2009")

Every 5 minutes of every hour, starting at 3pm
@Schedule(minute = "*/5", hour = "15/1")

The TimerService interface has been enhanced in order to allow programatically created timers to make use of cron alike expressions. Such expressions can be represented by an instance of the class ScheduleExpression, which can be passed as parameter during the timer creation.

Sky-Tiger

JB Lite

An EJB container which is compliant with the specification must make available a set of APIs. This set is now divided in two categories- minimum and complete. The minimum set is designated as EJB 3.1 Lite, and provides a subset of features which can be used by applications (EJB 3.1 Lite applications) which do not need the full range of APIs provided by the spec. This brings several advantages:

    * Increases the performance. By reducing the number of APIs the container becomes lighter and therefore can provide its services in a more performant way.
    * Facilitates the learning curve. Learning how to be an EJB developer is not a simple task, forcing developers to learn an extensive number of matters. In order to develop EJB Lite applications, developers will now have to deal with a smaller and easier learning curve, increasing their productivity.
    * Reduces licensing cost. A complain that is often heard is the fact that the container's license price is the same regardless the number of APIs the application uses. An application having few simple stateless beans runs on the same container than an application making full use of all EJB APIs, and therefore gets charged with similar licensing fees. By having EJB Complete and EJB Lite versions, vendors can introduce different licensing prices. An application can now pay for what it really uses.

EJB 3.1 Lite includes the following features:

    * Stateless, stateful and singleton session beans. Only local and no-interface views and only synchronous invocations.
    * Container-Managed Transactions and Bean-Managed Transactions.
    * Declarative and programmatic security.
    * Interceptors.
    * Deployment descriptors.

Sky-Tiger

Simplified EJB Packaging

An ejb-jar file is a module intended to package enterprise beans. Before EJB 3.1 all beans had to be packaged in such file. Since a considerable part of all Java EE applications is composed by a web front-end and a EJB back-end it means that the ear containing the application will have to be composed by two modules, a war and an ejb-jar. This is a good practice in the sense that structures the separation between front-end and back-end. But it is too much for simple applications.

Sky-Tiger

EJB 3.1 allows enterprise beans to be packaged in a war file. The classes can be included in the WEB-INF/classes directory or in a jar file within WEB-INF/lib. A war can contain at most one ejb-jar.xml, which can be located in WEB-INF/ejb.jar.xml or in META-INF/ejb-jar.xml in a WEB-INF/lib jar file.

It must be stressed that this simplified packaging should only be utilized in simple applications. Otherwise it should still be used the traditional approach with war and ejb-jar files.

Sky-Tiger

Embeddable EJB Containers

EJBs are traditionally associated to heavy Java EE containers, making it difficult to use them in certain contexts:

    * It is hard to unit test beans.
    * A simple standalone batch process cannot benefit from the use of EJBs unless there is a Java EE container providing the necessary services.
    * Complicates the use of EJBs in desktop applications.

One of the EJB 3.1 most significant features consists of the support for embeddable containers. A Java SE client can now instantiate an EJB container that runs within its own JVM and classloader. The embeddable container provides a set of basic services which allows the client to benefit from the use of EJBs without requiring a Java EE container.

The embeddable container scans the classpath in order to find EJB modules. There are two ways to qualify as an EJB module:

    * An ejb-jar file.
    * A directory containing a META-INF/ejb-jar.xml file or at least one class annotated as an enterprise bean.

The environment where a bean gets executed is totally transparent, that is, the same bean runs the same exact way on an embeddable container or in a Java EE standalone container, no change in the code is required.

An embeddable container ought to support the EJB 3.1 Lite subset of APIs. Vendors are free to extend such support and to include all EJB 3.1 APIs.

The class EJBContainer plays a central role in the use of embeddable containers. Provides a static method createEJBContainer which allows to instantiate a new container. Provides the method close which triggers the shutdown of the container, causing all PreDestroy callbacks to be executed. Last but not least, it provides the method getContext which returns a naming context that allows the client to lookup references to session beans deployed in the embeddable container.

@Singleton
@Startup
public class ByeEJB {
   
    private Logger log;
   
    @PostConstruct
    public void initByeEJB() {
        log.info("ByeEJB is being initialized...");
        (...)
    }

    public String sayBye() {
        log.info("ByeEJB is saying bye...");
        return "Bye!";
    }

    @PreDestroy
    public void destroyByeEJB() {
        log.info("ByeEJB is being destroyed...");
        (...)
    }
}

public class Client {

    private Logger log;

    public static void main(String args[]) {
        log.info("Starting client...");
        EJBContainer ec = EJBContainer.createEJBContainer();
        log.info("Container created...");
        Context ctx = ec.getContext();
        //Gets the no-interface view
        ByeEJB byeEjb = ctx.lookup("java:global/bye/ByeEJB");
        String msg = byeEjb.sayBye();
        log.info("Got the following message: " + msg);
        ec.close();
        log.info("Finishing client...");
    }

}

Log output
Starting client...
ByeEJB is being initialized...
Container created...
ByeEJB is saying bye...
Got the following message: Bye!
ByeEJB is being destroyed...
Finishing client...

Sky-Tiger

Best of the Rest

Besides the big new features, there are few minor improvements which simplify or leverage existing functionalities. From those, the following are the most relevant:

    * A stateful can now use the annotations AfterBegin, BeforeCompletion and AfterCompletion instead of implementing the SessionSynchronization interface.
    * It can now be specified a timeout for a stateful bean, which consists of the amount of time a stateful bean can remain idle before being removed by the container. The StatefulTimeout annotation was created for such effect.
    * A container is required to serialize invocations to stateless and stateful beans. By default, it is allowed to have concurrent calls to stateful beans, and it is up to the container to serialize them. The developer can now use the ConcurrencyManagement(CONCURRENCY_NOT_ALLOWED) annotation in order to indicate that a stateful bean does not support concurrent requests. In that case, whenever a stateful bean is processing a client invocation, and a second one arrives (from the same client or from a different one), the second invocation will get a ConcurrentAccessException.
    * The annotation AroundTimeout can be used to define interceptor methods for timer's timeout methods.

Sky-Tiger

Conclusions

Java EE 6 is now about to be finalized, and most of the technologies which exist in its universe are getting close to their final versions, and fulfilling almost all expectations. 2009 will definitely be a strong year for Java EE.

Few of the most exciting new features are coming with EJB 3.1. EJB 3.1 provides architects and developers with a rich set of new functionalities, allowing to extend the number of design and implementation challenges that can be covered by the technology. This release is very mature and complete, and will make the position of Java on the server side more solid than ever.

Since the technology is getting more and more complete, it is getting harder to come with missing features. Here are few ideas which can be used in next releases:

    * Support for specifying the minimum and maximum number of instances for a certain bean.
    * Support for application life cycle classes which handle events like pre-start, post-start, pre-stop and post-stop.
    * Enhance JMS in order to support features which are popular among messaging systems like message grouping and message ordering.
    * Support for JAX-RS.

We ought to congratulate the team working on this spec, which has put a tremendous effort, achieving a high quality result.

justforregister

啥时候出啊