The EJB Object
and the EJB Container Interceptor
In
RMI, our client called a stub, which marshalled data and sent it across
the network to the server. The server unmarshalled that data and
called the appropriate method on the implementation class. EJBs add
another level. The call is intercepted by the EJB Object on
the server side, and the middleware does its work before passing the call
on to the implementation. Such services include:
- Transaction management, which ensures data integrity in a distrubuted system.
- Security. This is automatic and taken for granted with EJB, but would have to be implemented with custom sockets in RMI.
- Resource management for threads, beans, sockets, and database connections.
- Persistence, or storing object data to the persistence mechanism (database).
- Remote accessibility, which makes your components network-aware.
- Automatic thread support.
- Location transparency, so that your client does not care where the actual implementation is. It is only concerned with the location of the services that connect you to your server implementation.
- Monitoring and meta-information gathering for analysis.
- EJB Objects are container specific. The container vendor generates the EJB Object automatically. They handle the middleware functions above, and they replicate and expose the methods of the bean itself.
- glue-code tools are provided by the EJB container vendor to integrate your beans into the container. They generate the stubs, skeletons, and other classes required for integration. So you can think of it as container-specific rmic.