Basic Concepts

Before going into details about implementing EJBs, some basic concepts must be clarified. First of all, recall that a bean runs in a container. The container, which is part of the EJB server, provides a number of services to the bean. These include transaction services, synchronization services, and security.

To provide these services, the bean container must be able to intercept calls to bean methods. For example, a client application calls a bean method that has a transaction attribute that requires the bean to create a new transaction context. The bean container must be able to interpose code to start a new transaction before the method call, and to commit the transaction, if possible, when the method completes, and before any values are returned to the client.

For this reason and others, a client application does not call the remote bean methods directly. Instead, the client invokes the bean method through a two-step process, mediated by the ORB and by the container:

1. The client invokes the bean method off of the remote interface object.
   1. The client actually calls a local proxy stub for the remote method.

   2. The stub marshals any parameter data, and then calls a remote skeleton on the server.

2. The skeleton unmarshals the data, and upcalls to the bean container.

   This step is required because of the remote nature of the call. Note that this step is completely transparent both to the client application developer as well as to the bean developer. It is a detail that you do not need to know about to write your application code, either on the client or the server. Nevertheless, it is useful to know what is going on, especially when it comes to understanding what happens during bean deployment.

3. The bean container receives the skeleton upcall, then interposes whatever services are required by the context. These can include:
   • authenticating the client, on the first method call

   • performing transaction management

   • calling synchronization methods in the bean itself

   • identity checks and switch

4. The container delegates the method call to the bean.

5. The bean method executes.

6. When it returns, the thread of control returns to the bean container, which interposes whatever services are required by the context.

   For example, if the method is running in a transaction context, the bean container performs a commit operation, if possible, depending on the transaction attributes in the bean descriptor.

7. The bean container calls the skeleton, which marshals return data and returns it to the client stub.

These steps are completely invisible to client-side and server-side application developers. One of the major advantages of the EJB development model is that it hides the complexity of transaction and identity management from developers.

---