New features in ejb3.1 (Part 2)

Author: Reza Rahman Source: www.theserverside.com

In the first article, I urged you to provide feedback directly to
JCP at jsr-318-comments@jcp.org as well as CCing me
Rrahman@tripodtech.net. Before going farther, I wocould like to thank
Everyone who took the time to send in comments! I hope you will
Continue to send in your thoughts as I write more articles in this
Series. I am also very grateful for all of the encouraging comments on
The series itself.

It's time for timer service features

Scheduling is an important part of your applications for tasks such
As report generation, database maintenance, generating OLAP summaries
Or data synchronization. If you have used the EJB timer service in its
Current form, you know that it is useful, but pretty limited.
Biggest limitations of the current EJB timer service are that it is not
All that flexible and scheduled jobs can only be created
Programmatically, not declaratively. Some of these weaknesses were
Outlined by Richard Monson-haefel In the EJB 2.x time-frame. This
Theserverside article outlines Richard's views: http://www.theserverside.com/tt/articles/article.tss? L = MonsonHaefel-Column4.

Let's take a super-quick look at the timer service as supported in EJB 3.0. Here is an example from EJB 3 in action:

@ Stateless <br/> public class placebidbean implements placebid {<br/> @ resource timerservice; <br/> Public void addbid (BID bid) {<br/>... code to add the bid goes here... <br/> timerservice. createtimer (15*60*1000, 15*60*1000, bid); <br/>}< br/> @ timeout <br/> Public void monitorbid (timer) {<br/> bid = (BID) timer. getinfo (); <br/>... code to monitor the bid goes here... <br/>}< br/>

The stateless Session Bean above creates a timer that is triggered
Every distributeen minutes, starting with a distributeen minute delay when a bid
Is created in the addbid method. Every time the trigger fires,
Monitorbid method annotated with the @ timeout annotation is invoked
See if the bidder was outbid.

While this functionality is fine for what placebidbean does, imagine
A slightly different scenario-a beginning-of-the-month Newsletter
Mailing for all actionbazaar MERs. Implementing this in terms
Millisecond intervals through the current programmatic timerservice
Interface wocould be a hazard at best. You'll also have to write some
Pretty Awkward code so that the timer is created when the application
Starts up. There are several existing mechanisms in place today
Achieve this kind of flexible declarative schedules in Java ee. You can
Use a popular open source schedlike like quartz, you can use
Commercial tool like flux or you can use scheduling services specific
To your application server such as the ones available for WebLogic or
Sybase EAServer. The problem with these solutions is that they tend
Be pretty cumbersome if all you really need is a declarative equivalent
Of UNIX cron in Java ee. All these solutions are also vendor-specific.
Enter the timer service enhancements in EJB 3.1.

The most important one in this set of enhancements is the ability
Declaratively create Cron-like schedules to trigger EJB methods (there
Are more advanced features; feel free to check them out when the spec
Draft comes out). For example, all you wowould have to do Is annotate
EJB method with the @ schedule annotation to implement
Beginning-of-the-month actionbazaar newsletter like so:

@ Stateless <br/> public class newslettergeneratorbean implements newslettergenerator {<br/> @ schedule (second = "0", minute = "0", hour = "0 ", <br/> dayofmonth = "1", month = "*", year = "*") <br/> Public void generatemonthlynewsletter () {<br/>... code to generate the monthly news letter goes here... <br/>}< br/>The following table describes the attributes of the @ schedule annotation as well as default values:

 

Attribute	Allowable values	Default
Second	[0, 59]	0
Minute	[0, 59]	0
Hour	[0, 23]	0
Dayofmonth	[1, 31]	*
Month	[1, 12] or {"Jan", "FEB", "Mar", "APR", "may", "Jun", "Jul", "Aug ", "Sep ", "Oct", "Nov", Dec "}	*
Dayofweek	[0, 7] or {"sun", "mon", "Tue ", "Wed", "Thu", "fri", "sat "}	*
Year	A four-digit calendar year	*

Note any of the attributes support the cron-style "*" wildcard
Represent all values, a comma separated list (such as "Jan, Feb, Mar"
For the month attribute) or a dash-separated range (such as "Mon-fri"
For the day of week attribute). shocould the expression syntax support
The "/" operator as well? How about supporting fully expanded
Abbreviations such as "January" instead of "Jan "? Also, shoshould
Compact, full Cron-expression format be supported as well? Our little
Example cocould be expressed:

@ Schedule (expression = "0 0 0 1 ***")

Some folks argue that this "Pure cron style expression" is way too
Cryptic, while others point out that a lot of developers are so used
It that it shoshould be supported in EJB. New methods were added to
Timerservice interface to support the programmatic version of Cron-like
Scheduling. The programmatic version supports defining the activation
And deactivation dates for a given schedule. For example, our
Newsletter cocould become active at a predetermined time in the future
Instead of being active as soon as the timer is created. shoshould similar
Support be added to the @ schedule annotation? How about supporting
Defining a finite number of occurrences a Cron-based trigger will fire?
Can you think of any other features?

Stripped down EJB Packaging

Making XML deployment descriptors optional in EJB 3.0 has
Significantly simplified packaging and deployment of Java EE
Applications. However, Java EE packaging is still clearly oriented
Towards strict modularization. Namely, you must create separate jar
Files for Web and EJB modules. In a typical Java EE deployment
Scenario, an ear file will contain in a war archive and a separate EJB
Jar. Figure 1 depicts the current Java EE packaging scheme. Roughly,
The idea is that the EJB jar represents "modularized" Business Services
That are consumed by the "client" web module. While modularization is
Very important, the problem is that it is overkill for simple web
Applications where business services are unlikely to be shared using SS
Clients in multiple other Java EE modules.

Figure 1: Current Java EE packaging.

Simplified EJB packaging for Web applications is aimed at addressing
This issue. In the new scheme, there is no need to create a separate
EJB jar module. Rather, ejbs (especially in the form of annotated
Pojos) can be directly dropped into the WEB-INF/classes directory and
Deployed as part of the war. In a similar vein, the ejb-jar.xml
Deployment descriptor, if you happen to be using one, can be placed
Into the WEB-INF directory along with the Web. xml file. It may also be
Possible to place an EJB jar into the WEB-INF/lib directory (Do you
Think this is important ?). The new packaging scheme is depicted in
Figure 2.

 

Figure 2: Simplified EJB packaging for Web applications.

For me, a very interesting implication of this is that the simplified
Packaging scheme makes ejbs much more agnostic of the rigidly defined
Structure of Java EE ear files. There is another really nice
Side-effect for those of us that still live in the land of occasional
Xml configuration and JNDI look-ups instead of 100% annotations and Di.
All EJB references, resource references or environment entries defined
Anywhere in the war can now be shared. This is because the entire war
File has only one local component environment (bound to the JNDI
Java: COMP/ENV namespace). Let's say you define a data source reference
In the Web. xml file like so:

<Resource-ref> <br/> <description> my data source </description> <br/> <res-ref-Name> JDBC/mydb </RES-ref-name> <br/> <res-type> javax. SQL. datasource </RES-type> <br/> <res-auth> container </RES-auth> <br/> </resource-ref> <br/>You can now do a lookup like the following not only in Web Container
Components like servlets but also inside ejbs packaged inside the war:

// Looking up my data source. <br/> datasource DS = (datasource) envctx. Lookup ("Java: COMP/ENV/jdbc/mydb"); <br/>What are your thoughts on this? There is one more reason I really like
The simplified packaging enhancement-It goes hand-in-hand with EJB
Lite. EJB Lite is a very minimal sub-set of EJB features designed
Use in stripped-down applications. I'll talk more about EJB Lite in
Later article in the series. One interesting possibility is that week
Vendors will likely start implementing EJB Lite on top of Servlet
Containers like tomcat or jetty, with ejbs directly deployable to war
Files, completely by-passing Java EE ears. I see JBoss as express,
Glassfish express or Tomcat + openejb as possibilities that are difficult
To ignore, especially given Java EE 6 profiles. What do you think
These possibilities?

More to come

Believe it or not, the features discussed in the first and second
Parts of this series are still just the tip of the iceberg. Here are
Some of the more interesting ones I'll cover in this series:

1. EJB support in minimal containers in the form of EJB lite.
   This wocould be similar to what is already available in the Open Source
   World in the form of embedded JBoss, openejb and easybeans plugging in
   On top of Tomcat.
2. Support for asynchronous Session Bean invocation.
3. Support for stateful Web services via stateful Session Bean web service endpoints.
4. The standardization of JNDI mapping instead of keeping it for vendors to decide is being preliminarily discussed.

Something else I am intending to discuss in the series is using EJB
Through web beans. As you might already know, Web beans is a very
Powerful integration framework that makes it possible to use some very
Interesting di features with EJB, an area Java ee has been criticized
By a number of folks. The web beans specification is being led by Gavin
King and inspecates ideas from JBoss Seam and Google guice ("crazy"
Bob Lee of guice fame is working on webbeans too). Until then, wish
Expert group luck and keep the feedback rolling!

References

1. JSR 318: Enterprise JavaBeans 3.1, http://jcp.org/en/jsr/detail? The id = 318.
2. JSR 299: Web beans, http://jcp.org/en/jsr/detail? The id = 299.

As per Linux conventions, either 0 or 7 can be used to represent Sunday.