I'm an OCE JEE6 1Z0-895 Certified!

I've passed the exam for 1Z0-895 Java Platform, Enterprise Edition 6 Enterprise JavaBeans Developer Certified Expert with 83%!

My training materials were:

1. Enterprise JavaBeans 3.1 (the most recommended book, ignore JPA chapters, this is the Bible from where to learn all the exam topics, but it's incomplete concerning the deepness of needed knowledge - complete the knowledge from the EJB 3.1 specification!)
Andrew Lee Rubinger, Bill Burke
O'Reilly Media; Sixth Edition edition (September 24, 2010)

2. EJB 3 in Action (EJB 3.0, ignore JPA chapters, I don't remember what I learned from this book that I didn't learned with the O'Reilly book. Be aware that in version 3.0 there are no singletons, so this book does not mention it)
Debu Panda, Reza Rahman, Derek Lane
Manning Publications Co.; 1st Edition

3. Head First EJB (EJB 2.0, just for the basic concepts, like the EJB Roles and how to understand the "equals" between EJBs - ignore EJB 2.0 specific stuff)
Kathy Sierra, Bert Bates
O'Reilly


4. OCP JavaEE 6 EJB Developer Study Notes by Ivan A Krizsan (very complete! Read it! Learned the structure of an .ear and .jar from here and also the Exceptions tree structure for distinguishing between Application Exceptions and System Exceptions)

5. Frits Walraven OCPEJBD 6 EJB3.1 (a very good short study notes! I became aware of the "equals" questions between EJBs from here. If you know all the topics mentioned here, then you should be prepared for the exam)

6. JSR-000318 Enterprise JavaBeansTM 3.1 Final Release (The EJB 3.1 specification: it has all the needed information but it is really hard to read, but it must be read to complement the knowledge)

7. Interceptors 1.1 (The EJB 3.1 Interceptors specification: It's very quick to read!)

8. Enthuware 1Z0-895 exams (some questions are very similar to the real exam, really good software for practice! I was getting around 80% in this software and I got 83% in the real exam!)

After all this study, if you are passing in Enthuware exams, then you should pass on the real exam!
Good luck!

EJB 3.1: Transactions and Exceptions

It confuses me a bit how transactions and exceptions get together in the EJB specification.
It always depends on the transaction type (CMT or BMT), the type of the bean (Session or MDB), and the type of the exception (Application or System Exception).

The O'Reilly Enterprise JavaBeans 3.1 book summarizes this into some tables. I hope that this can help you like it has helped me about how to think about the transactions and exceptions.

For Session and Entity Beans:

For MDBs:

EJB 3.0: Mapping between annotations and XML elements

This table is not specific for EJB 3.1, it misses some new stuff like the Singleton annotation, but it is pretty cool to have an idea of the mapping between XML elements and annotations.

Source: EJB 3 in Action, First Edition, Manning

EJB 3.1 Timer Service

We can inject the Timer Service using:

@Resource TimerService timerService;

Then we create the Timer and we can attach an object to it:

public void doSomething(SomeObject obj){
//...
timerService.createTimer(15*60*1000, 15*60*1000, obj);
}

The createTimer can have 4 different signatures. In the used signature, the first parameter represents the time after which the timeout should be triggered, after the method invocation. The second parameter represents the repetition period and at last, the last parameter is the object that can be attached to this timeout (it must be a Serializable object) The other signatures concerns to a single-event timer with no repetition, by receiving a long value (in miliseconds) or a Date object, and the other concerns to a timer event with repetition, but the first parameter is a Date instead of a long.

When the timer is triggered, it calls the method that is annotated with the @Timeout annotation.

@Timeout
public void methodName(Timer timer){
SomeObject obj = (SomeObject) timer.getInfo();
//...
}

The signature for the method annotated with the @Timeout annotation must have the following signature:

void <METHOD NAME>(Timer timer)

Accessing the Timer Service
Instead of injecting the Timer Service, we can retrieve it from the Session Context:

@Resource SessionContext ctx;
//...
TimerService service = ctx.getTimerService();

EJB 3.1 Interceptors

Interceptors implementation can be found where @AroundInvoke annotation is declared. The @Interceptors annotation should be used to say where it could be found the interceptor(s) implementation and to where should be applied (could be at class level or method level).
E.g
@Interceptors(Impl.class)

The method where @AroundInvoke is applied, should have the following signature:
Object <METHOD>(InvocationContext) throws Exception

The @AroundInvoke method should contain a invocationContext.proceed() invocation, in order to allow the execution chain to go on.

A default interceptor can be declared (only at the deployment descriptor file):
<assembly-descriptor>
  <interceptor-binding>
    <ejb-name>*</ejb-name>
    <interceptor-class>actionbazaar.buslogic.ActionBazaarLogger</interceptor-class>
  </interceptor-binding>
</assembly-descriptor>

The default interceptor can be disabled, at the class or method level, using the @javax.interceptor.ExcludeDefaultInterceptors
The class interceptor can be disabled, at the method level, using the @javax.interceptor.ExcludeClassInterceptors

EJB 3.1 Exceptions

SessionContext is used for Session Beans.
MessageDrivenContext is used for Message Driven Beans.

EJB 3.1 Message Driven Bean Lifecycle

MDB Lifecycle, from book "Oreilly Enterprise Javabean 3.1, 6th Edition"

EJB 3.1 Component Types

EJB 3.1 component types are:

1. Session Beans
1. Stateless Session Beans (SLSB)
2. Stateful Session Beans (SFSB)
3. Singleton Session Beans
2. Message Driven Beans (MDB's)
3. Entity Beans

• The Stateless Session Bean does not preserve conversational state.
• The Stateful Session Bean preserves conversational state and there is one instance of the session bean per client.
• The Singleton Session Bean is new to the EJB 3.1 Specification. There is only one instance of this bean type.
• The Message Driven Bean acts as an event listener. It cannot be called from the client.

For each Bean, there are lifecycle callbacks that must follow the pattern void <METHOD>().

EJB 3.1: Stateful Session Bean lifecycle

SFSB Lifecycle, from book "Oreilly Enterprise Javabean 3.1, 6th Edition"

Lifecycle events:
@PostConstruct
@PreDestroy
@PrePassivate
@PostActivate

With SessionSynchronization:

SFSB Lifecycle with SessionSynchronization, from book "Oreilly Enterprise Javabean 3.1, 6th Edition"

Programming Rules for Stateful Session Beans:

• The Stateful Session Beans maintain conversational state, so the instance variables must be Java primitives or Serializable objects.
• Since the SFSBs cannot be pooled like the SLSBs, there can be the risk of accumulating too many of them. So the client can explicitly request the removal of a bean by calling a method annotated with the @Remove annotation.

EJB 3.1: Asynchronous Methods

New to EJB 3.1, by using the @javax.ejb.Asynchronous annotation, we can achieve fire and forget invocations, useful when having long time processing methods. When the client needs to use the result, it can take use of the facilities provided by the java.util.concurrent.Future
We can use the @Asynchronous annotation on class level, so all the methods are asynchronous, or we can use the @Asynchronous annotation at the method level.

A void method can also be marked with the @Asynchronous annotation, but in this case, no exceptions will be delivered to the client.

@Asynchronous
public Future<String> doStuff(final String input){
    // do stuff and return
    return new AsyncResult<String>("myResult");
}

If the asynchronous method has a return type Future<V> and it throws an exception, the the client will get an ExecutionException when trying to retrieve the result.

Cancel a request:
The client can request a cancel on the Future<V> invocation, using
Future<V>.cancel(boolean mayInterruptIfRunning)

where the boolean parameter represents if the asynchronous method can see if the cancel was requested.
The asynchronous method can check if cancel was called by the client, by using the SessionContext.wasCancelCalled()

Retrieving the results:
final Future<String> futureTask= myEjbProxyReference.doStuff(input);
final String result= futureTask.get(10,TimeUnit.SECONDS); //should catch the TimeoutException

Please notice the if the get() method is called with no arguments, then the get() will block until the result is available. To be assure that the result is retrieved after an undefined amount of time, then the Future<V>.isDone() method should be called, to check if the asynch result processing was already finished.

EJB 3.1 Stateless Session Bean lifecycle

The SLSB (StateLess Session Bean) has a lifecycle with only 2 phases, the "Does Not Exist" and the "Method-Ready Pool" phase, because it does not preserve conversational state, which is the big characteristic of this EJB.

SLSB Lifecycle, from book "Oreilly Enterprise Javabean 3.1, 6th Edition"

Life-cycle Events
@PostConstruct
@PreDestroy

When going from the "Does Not Exist" to the "Method-Ready Pool", the no-argument constructor is called by the contained; next the container proceeds with code injection where applicable and the calls the method that is annotated with the @PostConstruct annotation. It is not mandatory the presence of this method, but if it exists, then it can be called with a what-so ever name, but it need to be void, have no arguments and must not throw checked exceptions.

In the "Method-Ready Pool", the bean is ready to attend the execution of the business methods.

When the container decides to destroy the bean, the bean goes back to the "Does not Exist" state and the method annotated with @PreDestroy is called, if it exists. Like the @PostConstruct method, it follows the same rules: can have anyname, needs to be void, have no arguments and must not throw checked exceptions.