Figure 1 depicts the basic architecture of EJB-based client/server enterprise applications. The client side of an EJB architecture contains the EJB interfaces needed for invoking business-specific methods on an EJB, as well as for managing handles to server-side objects. The server side of an EJB architecture contains the instances of the actual EJB component implementation, as well as the container code that maps calls to and from clients and EJBs after appropriate service-management infrastructure logic has been executed. RMI remote interface semantics are currently implied by these interfaces and thus enable RMI/JRMP, RMI/IIOP, and RMI-to-CORBA IDL mappings to be used as the interface mechanism.
Figure 1 The EJB architecture.
The primary components of the application-specific elements of an EJB architecture, as depicted in Figure 1, are listed here:
EJB clientsEJB client applications utilize the Java Naming and Directory Interface (JNDI) to look up references to home interfaces and use home and remote EJB interfaces to utilize all EJB-based functionality.
EJB home interfaces (and stubs)EJB home interfaces provide operations for clients to create, remove, and find handles to EJB remote interface objects. Underlying stubs marshal home interface requests and unmarshal home interface responses for the client.
EJB remote interfaces (and stubs)EJB remote interfaces provide the business-specific client interface methods defined for a particular EJB. Underlying stubs marshal remote interface requests and unmarshal remote interface responses for the client.
EJB implementationsEJB implementations are the actual EJB application components implemented by developers to provide any application-specific business method invocation, creation, removal, finding, activation, passivation, database storage, and database loading logic.
Container EJB implementations (skeletons and delegates)The container manages the distributed communication skeletons used to marshal and unmarshal data sent to and from the client. Containers also may store EJB implementation instances in a pool and use delegates to perform any service-management operations related to a particular EJB before calls are delegated to the EJB implementation instance.