EJB3 communication mechanism

Question

I'm new to Java EE and got confused about EJB. As I understand @remote EJBs are using RMI and JNDI for communication. Before EJB3.0 beans needed to implement Remote interface through EJBHome interface - that way I understand how RMI was used. But now I only need to put @remote annotation, which can be substituted by properties in ejb-jar.xml.

So, the question is: how is it possible to use JNDI without Serializible interface and RMI without Remote interface?

Please correct me if some of my assumptions are wrong.

Answer 1

1. EJB3 still uses RMI underneath except the application container will take care of generating and using RMI stubs and remote interfaces automatically for you and map them to your EJB3 classes.

2. You are still required to use Serializible in certain cases. See this :

Clustered Session Beans (SLSB & SFSB)

First of all, clustered EJB3 SLSBs or SFSBs do not need to implement Serializable. In fact, it's recommended that they don't. In the case of clustered SLSBs, no state replication occurs, so their instance variables do not even need to be Serializable. With clustered SFSBs though, the same serialization rules used for SFSB passivation apply to SFSB state replication. In other words, all non-transient instance variables that are not references to beans, sessions contexts or user transactions must be serializable, or null at replication time. For further information on the SFSB passivation (and by extension replication because in both cases the SFSB bean context needs to be serialized), please check section 4.2.1 of the EJB3 core specification.

Clustered Entity Beans

These only need to be marked Serializable if the clustered entity instances are to be passed by value as a detached object (eg, through a remote interface). Otherwise, there's no need to mark them as Serializable.

Answer 2

EJB uses RMI, but it's not exactly equal to RMI. The container generates classes and interfaces at runtime that conform to the RMI spec, and hide them from you. This is why in a EJB project your remote client usually needs to include in its classpath a bunch of libraries specific to the container. In this regard, EJB 2.0 was more transparent to the fact that it uses RMI under the hood, and thus, more complicated.