As we all know, JavaTM EE 5 brought a great level of simplicity to the Enterprise JavaBeansTM programming model with the introduction of annotation and the configuration-by-exception concept. The Java EE 6 specification continued in the simplicity path with the introduction of many features in the EJB 3.1 programming model. Read about the following EJB 3.1 enhancements that the WebSphere Application Server included in its alpha release:
1) Singleton Session Beans:
In addition to the stateful and stateless session bean types, the EJB 3.1 specification introduced a third kind of session beans called singleton beans. As the name implies one instance of a singleton session bean exists per application and remains for the life of the application. Using singleton session beans is an efficient way to share data by the application. Whenever sharing of data happens, concurrency becomes a concern, therefore, the EJB3.1 specification introduced two kinds of concurrency control:
i) Container Managed Concurrency:
Allows the container to manage the concurrency based on input from the application developer. The developer marks the singleton methods with @Lock(LockType.READ) or @Lock(LockType.WRITE) and the container manages the concurrency.
ii) Bean Managed Concurrency.
As the name implies, the container is not involved here. Instead, the application, itself, manages its own concurrency with the use of synchronized blocks and other means.
The user of singleton session beans can also declare dependencies between singleton session beans and mark singleton session beans to start so that they are initialized first when the application starts.
Important: Singleton session beans exist in a single Java Virtual MachineTM (JVM). Hence, in a clustered application, each cluster member will have its own instance of singleton session beans. Data is not shared across JVM instances.
2) Non-persistent EJB timers
The EJB timers are not new in the EJB programming model. What is new in the EJB3.1 specification, however, is the introduction of non-persistent timers. Although persisting a timer to allow for replay of any missed timers is valuable, situations exist where you do not need a replay of missed timers after the server is back up after a server shutdown. For example, a timer is created to refresh a web page once every hour. You most likely do not want the page to refresh 5 times when the server is back up, if the server was down for 5 hours.
When installing an application that has non-persistent timers in a clustered environment, each JVM will have its own non-persistent timer.
3) Automatically created timers
This feature simplifies the creation and deletion of timers. As the name implies, automatically created timers are automatically created by the container when the application is first started and are removed when the application is un-installed. Automatically created timers can be persistent or non-persistent. The container handles persistent and non-persistent, automatically created timers differently when they are part of an application that is installed in a clustered environment:
i) Non-persistent case: Each JVM has its own timer.
ii) Persistent case: Only one timer exists per application.
4) Calendar-based timer expression:
The specification added a valuable simplification in this area by allowing developers to declare timers using calendar-based syntax that is modeled after the UNIX Cron facility. That means, developers are no longer forced to declare duration-based timers. Instead, developers now have the choices between duration based and calendar based. The calendar-based timer expressions were added to both the new, automatically created timers and the old programmatically created timers. See the following example of creating an automatically created timer that fires every hour on the first day of every month:
5) Asynch method invocation
EJB 3.1 applications can scale better now with the introduction of Asynchronous method invocation feature. Developers can easily mark EJB methods as asynchronous. There are two types of asynchronous methods:
i) Fire and forget: When a method that returns void is made asynchronous.
ii) Fire and return results: When a method that returns something other than void is made asynchronous. In this case, a Future object is returned that the application can use to monitor the progress of the asynchronous method, attempt to cancel the methods, retrieve the results of the asynchronous method, and more.
6) No-interface local view
This feature moves the EJB programming model a step closer to the POJO concept. With this feature, the enterprise bean no longer needs to declare a business interface. Instead, an enterprise bean can be a simple POJO that does not implement any interfaces. The no-interface local view is a new view that exposes all public non-final methods on the concrete bean class. There are two ways to declare a no-interface local view:
i) Create an enterprise bean that does not expose any other client view (Local, Remote, 2.x Remote Home, 2.x Local Home, Web Service), and its implements clause is empty.
ii) Add @LocalBean (or the XML equivalent) to any enterprise bean regardless of the client views exposed on it.
7) Embeddable container:
This feature is one of the most exciting new features in the EJB3.1 specification. The embeddable container is targeted for developers and allows for an easy way to unit test EJB business logic without the need for an application server. Developers can now unit test their business logic in a Java 2 Platform, Standard Edition (J2SE) environment with the IBM embeddable EJB container JAR file, which is roughly 14 MB in size. EJB container supports what is called EJB lite, which is a new concept introduced by the EJB 3.1 specification. The following list is the minimum of features required for EJB lite:
a) Stateless, Stateful and Singleton session beans.
b) Java Persistence API (JPA)
c) Local and no-interface view (no remote views)
e) Transactions (both container managed and bean managed)
f) Declarative and programmatic security
Use these EJB 3.1 specification features to simplify developer tasks for your applications that run on this version of WebSphere Application Server. The WebSphere Info center contains a lot of details on the above features.
Pinned topic Feature Focus Week: Enterprise Java Bean (EJB) 3.1
Answered question This question has been answered.
Unanswered question This question has not been answered yet.
Updated on 2011-04-27T15:55:56Z at 2011-04-27T15:55:56Z by bkail
ramesh.s 0600002B1D1 Post
Re: Feature Focus Week: Enterprise Java Bean (EJB) 3.12011-04-27T09:16:29ZThis is the accepted answer. This is the accepted answer.Hi,
We are using IBM WAS 7.0 on Mainfram Z/OS which doesn't support EJB 3.1, Hence we can't us e the Singleton Session Bean. Is there any other way to have this feature in (WAS 7.0 for Z/OS - EJB 3.0). We have the following requirement
1. During the start of the application, load the VSAM file records into EJB Object (cache)
2. This instance needs to be active during the whole day and available for the other stateless session beans to refer instead of reading from VSAM file.
3. Refresh the EJB Object through other session bean, if there is any change in the vsam file.
i | Nautix Technologies India Pvt. Ltd.
Tracy-B. 270003JPJ31 Post
Re: Feature Focus Week: Enterprise Java Bean (EJB) 3.12011-04-27T15:52:12ZThis is the accepted answer. This is the accepted answer.
- ramesh.s 0600002B1D
More information about Startup beans can be found here:
To insure that the Startup bean is initialized before any other EJB in the application is accessed, I'd recommend using a module level Startup bean defined in a separate module within the application, with a starting weight that allows it to start prior to other EJB modules.
More information about starting weight for EJB modules can be found here:
bkail 120000PS1Y8 Posts
Re: Feature Focus Week: Enterprise Java Bean (EJB) 3.12011-04-27T15:55:56ZThis is the accepted answer. This is the accepted answer.
- ramesh.s 0600002B1D
You'll need to store the data in a properly synchronized data structure and periodically refresh it. Per the spec, EJBs aren't supposed to use synchronization primitives because they can cause problems if used incorrectly; if done properly, it should work in practice.