Middleware Technologies [MCA II Yr, Anna University] by Roy Antony Arnold

The EJB Home Interface

• All home interfaces must extend the EJBHome Interface.
  

public interface javax.ejb.EJBHome extends java.rmi.Remote

{

public abstract EJBMetaData getEJBMetaData();

public abstract void remove (Handle handle);

public abstract void remove (Object primaryKey);

}

• The home interface serves as the initial point of contact for a client. When the client uses a naming service to lookup an EJB bean, the naming service returns a reference to an object that implements the bean’s home interface.
  
• The home interface requires implementation of three methods namely, getEJBMetaData(), remove(Handle handle) and remove(Object primarykey).
  

getEJBMetaData()

• This call returns a reference to an object that implements the EJBMetaData interface.
  

public interface javax.ejb.EJBMetaData

{ public abstract EJBHome getEJBHome();

public abstract Class getHomeInterfaceClass();

public abstract Class getPrimaryKeyClass();

public abstract Class getRemoteInterfaceClass();

public abstract boolean isSession();

}

• Builder tools can use the information in the EJBMetaData class to generate wrapper classes to invoke methods on the bean.
  

remove(Handle handle)

• This method removes an EJB object using a Handle, which is a serializable reference to a particular bean.
  

remove(Object primaryKey)

• This method removes an EJB object by its primary key. (Only an Entity bean can have a primary key)
  

The EJBHome interface does not provide any methods by which a client can create new beans or look up existing ones. Instead, the EJB bean developer must write the method signatures for these tasks in their own interfaces.

• A client uses a naming service to look up an EJB, getting a reference to an object that implements its home interface to get a reference to the bean’s remote interface.
  

The EJBObject Interface

All remote interfaces extend the EJBObject interface:

public interface javax.ejb.EJBObject extends java.rmi.Remote

{

public abstract EJBHome getEJBHome();

public abstract Handle getHandle();

public abstract Object getPrimaryKey();

public abstract boolean isIdentical (EJBObject obj);

public abstract void remove();

}

getEJBHome()

• This method returns a reference to an object implementing the EJB object’s home interface.
  

getHandle()

• This method returns a handle, which is a serializable reference to the object.
  
• The Handle interface specifies one method, getEJBObject(), which can be used to recreate a remote reference from the handle.
  

getPrimaryKey()

• This method returns the primary key used by the EJB object. Although it exists on the interfaces for both session and entity beans, it really makes sense to use this method only on an entity bean; session beans do not expose a primary key to the outside world, and indeed need not have a primary key at all.
  

isIdentical()

• This method provides a way to test whether two EJB object references refer to an identical object. It is mainly useful for Entity Beans.
  

Two Entity beans that are from the same home interface and have the same primary key are considered identical.

The two references in this method do not necessarily point to the same object in memory, but all of these instances are considered to have the same identity.

remove()

• This method allows the caller to remove the remote EJB object.
  

Note: To create a remote interface, simply create an interface that inherits from EJBObject and add the method signatures of the methods. And there is no need to implement this remote interface. Instead the container generates a proxy object that interacts with remote clients and passes their method calls to the bean.

The EnterpriseBean Interface

• The top-level type in the EJB Class hierarchy is the EnterpriseBean interface.
  

public interface javax.ejb.EnterpriseBean extends java.io.Serializable

{

}

• This merely serves as a common point of ancestry for the Session and Entity beans, and requires that its subinterfaces be serializable. The transaction attribute logically belong with the Enterprise Bean interface, even though they’re not associated directly with it. Either a Session or an Entity Bean can be assigned any of the six available transaction attributes.
  

EJB Containers

• It is an environment in which EJB execute.
  
• Its primary role is to serve as a buffer between an EJB and the outside world
  
• The container is having high degree of flexibility in servicing client requests.
  
• The container provides following services:
  
  • Support for transactions
    
  • Support for management of multiple instances
    
  • Support for persistence
    
  • Support for security
    
• The container generally provides support for managing and monitoring EJBs as well as for version management.
  

a) Support for transactions

• EJB container provides the beans with ACID properties.
  
• EJB supports transaction by having the transaction manager for ‘begin’ and ‘commit’ operations.
  
• It also provides another approach, called declarative transaction management.
  
• Here the author can specify the type of transaction support for that bean.
  
• When the bean is deployed, the container reads the deployment descriptor associated with that particular EJB Bean, and provides necessary transaction support automatically.
  
• EJB Provides six modes of transaction management
  

   

  1) TX_NOT_SUPPORTED
  

  2) TX_BEAN_MANAGED
  

  3) TX_REQUIRED
  

  4) TX_SUPPORTS
  

  5) TX_REQUIRES_NEW
  

  6) TX_MANDATORY
  

   

• TX_NOT_SUPPORTED means that the bean does not support any transactions, and can’t be used from within a transaction. If the client attempts to use the bean from within a transaction, the client’s transaction will remain suspended until the bean completes its operation; the client’s transaction will then resume.
  
• In TX_BEAN_MANAGED, the bean manages its own transaction. This option is the only type of transaction support in which the bean can directly manipulate the transaction.
  
• For TX_REQUIRED mode, if the client has a transaction open when it invokes the bean’s method, the bean runs within the client’s transaction context. Otherwise, the container starts a new transaction.
  
• TX_SUPPORTS means that if the client has a transaction in progress when it invokes the bean’s methods, the client’s transaction is used. Otherwise no new transaction is created.
  
• In TX_REQUIRES_NEW, the bean always starts a new transaction (even if a transaction is already in progress). If a transaction is underway, the container temporarily suspends it until the bean’s transaction finishes.
  
• For TX_MANDATORY, the bean requires that the client have a transaction open before the client attempts to use the bean. If no transaction is available, an error occurs.
  

b) Support for Management of Multiple Instances

• Normally stateless session beans are accessed by only one client.
  
• Other types of beans may be used concurrently by multiple clients
  
• The EJB container must ensure that each client’s requests are serviced in a timely manner.
  
• To accomplish this goal, the server performs several tasks behind the screen.
  

  i) Instance Passivation
  

  ii) Instance Pooling
  

  iii) Database connection pooling
  

  iv) Preached Instances
  

  v) Optimized method invocation
  

   

i) Instance Passivation

• It is the temporary swapping of an EJB bean out to storage.
  
• If a container needs resources, it may choose to temporarily swapout a bean.
  
• Both session & entity beans can be passivated.
  
• Passivation on session beans are performed only to free up space. But on the entity beans, also used to synchronize its state with the underlying data store.
  

ii) Instance Pooling

• This means that the container shares instances of EJB beans among multiple clients
  
• To increase the efficiency the container instantiate fewer copies of a given bean to service requests. This not possible in all the cases.
  
• Specially, the container must provide one session bean per client otherwise conversational state can’t be tracked by the containers.
  

iii) Database Connection Pooling

• It is a strategy commonly employed in middleware applications.
  
• When a component wishes to access a database, it does not create a new database connection; instead, it simply grabs a connection from a pool of available connections.
  
• This is beneficial for two reasons
  
  • It avoids the overhead of establishing a new database connection
    
  • Maintaining an open database connection consumes resources on the database. Connection pooling allows to limit the no. of simultaneous connections and reduces the overhead on performance.
    

iv) Precached instances

• This may be used when an EJB needs to load some state information from a database when it is created.
  
• EJB State information can be cached in some readily available place and this speeds up the loading process.
  

v) Optimized method invocations

• These are employed to combat overhead costs associated with remote invocation
  
• Whether the client of an EJB is a remote client or another EJB in the same container, the APIs used to gain access to it are always the same.
  
• A typical EJB interaction is as follows:
  
  • Use a naming service to locate the EJB’s home interface
    
  • Make a call on the EJB’s home interface to gain access to its remote interface.
    
  • Make calls to the business methods against the remote interface.
    
• Contain short circuit the remote protocol, when both the beans live in the same container.
  

c) Support for persistence

• Support for persistent EJBs (Entity Beans) is not mandatory in the 1.x version of the EJB specification, but it will become mandatory, but it will become mandatory in the 2.0 version.
  
• Persistence means that the state of an object is saved to some sort of persistent storage (typically a file or a database) allowing the object to be read in and used at some later time, instead of being recreated each time.
  
• The shifting of responsibility for transaction management, concurrency, security and persistence to the container means that the bean developer can concentrate on the business rules of his/her application.
  

d) Support for security

• The main mechanism used in EJB security is the access control list (ACL).
  
• An ACL is a list of persons or groups that are allowed to access particular pieces of functionality.
  
• Only those users who are included in the ACL will be able to access the ACL protected beans.