EJB Home Interface & Remote Interface

EJB Home Interface

• The EJBHome object must implement the home interface.
• This interface contains the methods used by the clients to create and remove the instances of the EJB.
• The home interface is the client’s initial point of contact with your EJB components.
• For the client to access the EJB , an instance of the EJB is created from one or more create() methods of the Home interface.
• The ejbCreate() methods defined in the EJB must also be declared with matching signatures in the Home interface.
• Returns a reference to a EJB by creating or finding it.

EJB Remote Interface

• The EJBObject class must implement the remote interface.
• Once the client has used the home interface to gain access to EJB ,it uses this interface to invoke the business methods defined in the EJB class.
• Clients can never get a reference to the EJBs class , only the EJBObject class.
• The EJB container uses the remote interface for your bean to generate both the client-side stub and server-side proxy object that passes client calls to your EJB object.

Read more...

Java Deployment Descriptor

• The deployment descriptor objects are used to establish the runtime service settings for an enterprise bean
• This object defines the enviromental properties , along with the enterprise bean class name, the
• JNDI namespace,the home and remote interface name
• It has two types depending on the requirements,Session descriptor and entity descriptor
• The deployment descriptor also contains detailed inforamtion about how the bean should execute regarding transaction and security
• The deployment descriptor provides the full description of all files in the ejb jar
• Deployment descriptor is defined in a XML based format having some standard tags and attributes

Read more...

Entity Bean's Ready State & Pooled State

The idea of the “Pooled State” is to allow a container to maintain a pool of entity beans that has been created, but has not been yet “synchronized” or assigned to an EJBObject. This mean that the instances do represent entity beans, but they can be used only for serving Home methods (create or findBy), since those methods do not relay on the specific values of the bean.

All these instances are, in fact, exactly the same, so, they do not have meaningful state. It can be looked at it this way

If no client is using an entity bean of a particular type there is no need for caching it (the data is persisted in the database). Therefore, in such cases, the container will, after some time, move the entity bean from the “Ready State” to the “Pooled state” to save memory. Then, to save additional memory, the container may begin moving entity beans from the “Pooled State” to the “Does Not Exist State", because even though the bean’s cache has been cleared, the bean still takes up some memory just being in the “Pooled State".

Read more...

Entity Bean Method Types

Entity bean is used to represent data in the database. It provides an object-oriented interface to data that would normally be accessed by the JDBC or some other back-end API. More than that, entity beans provide a component model that allows bean developers to focus their attention on the business logic of the bean, while the container takes care of managing persistence, transactions, and access control.

An entity bean consists of 4 types of methods

create() methods

To create a new instance of a CMP entity bean, and therefore insert data into the database, the create() method on the bean's home interface must be invoked. They look like this: EntityBeanClass ejbCreateXXX(parameters), where EntityBeanClass is an Entity Bean you are trying to instantiate, ejbCreateXXX(parameters) methods are used for creating Entity Bean instances according to the parameters specified and to some programmer-defined conditions.

A bean's home interface may declare zero or more create() methods, each of which must have corresponding ejbCreate() and ejbPostCreate() methods in the bean class. These creation methods are linked at run time, so that when a create() method is invoked on the home interface, the container delegates the invocation to the corresponding ejbCreate() and ejbPostCreate() methods on the bean class.

finder() methods

The methods in the home interface that begin with "find" are called the find methods. These are used to query the EJB server for specific entity beans, based on the name of the method and arguments passed. Unfortunately, there is no standard query language defined for find methods, so each vendor will implement the find method differently. In CMP entity beans, the find methods are not implemented with matching methods in the bean class containers implement them when the bean is deployed in a vendor specific manner.

The deployer will use vendor specific tools to tell the container how a particular find method should behave. Some vendors will use object-relational mapping tools to define the behavior of a find method while others will simply require the deployer to enter the appropriate SQL command.

There are two basic kinds of find methods: single-entity and multi-entity. Single-entity find methods return a remote reference to the one specific entity bean that matches the find request. If no entity beans are found, the method throws an ObjectNotFoundException . Every entity bean must define the single-entity find method with the method name findByPrimaryKey(), which takes the bean's primary key type as an argument. The multi-entity find methods return a collection ( Enumeration or Collection type) of entities that match the find request. If no entities are found, the multi-entity find returns an empty collection.

remove() methods

These methods (you may have up to 2 remove methods, or don't have them at all) allow the client to physically remove Entity beans by specifying either Handle or a Primary Key for the Entity Bean.

home() methods

These methods are designed and implemented by a developer, and EJB specification doesn't have any requirements for them except the need to throw a RemoteException is each home method.

Read more...

(EJB) Entity Beans in brief

What is an Entity Bean?

An Entity bean represents a business object in a persistent storage mechanism. An entity bean typically represents a table in a relational database and each instance represents a row in the table. Entity bean differs from session bean by persistence, shared access, relationship and primary key. There are two types of entity beans available.

• Container Managed Persistence (CMP)
• Bean Managed Persistence (BMP)

CMP / Container Managed Persistence

A The term container-managed persistence means that the EJB container handles all database access required by the entity bean. The bean's code contains no database access (SQL) calls. As a result, the bean's code is not tied to a specific persistent storage mechanism (database). Because of this flexibility, even if you redeploy the same entity bean on different J2EE servers that use different databases, you won't need to modify or recompile the bean's code. So, your entity beans are more portable.

BMP / Bean Managed Persistence

A Bean managed persistence (BMP) occurs when the bean manages its persistence. Here the bean will handle all the database access. So the bean's code contains the necessary SQLs calls. So it is not much portable compared to CMP. Because when we are changing the database we need to rewrite the SQL for supporting the new database.

Read more...

Stateless Session Beans

A Stateless session beans are of equal value for all instances of the bean. Session bean will execute a client request and return a result without saving any client specific state. This means the container can assign any bean to any client, making it very scalable. Stateless session beans does not retain client specific state from one method invocation to the next.

Bean instance can be reassigned to serve a method invocation from another client once current method invocation is done. Value of instance variables of a bean instance is not preserved between calls. Container transparently reuses bean instances to serve different clients. Load-balancing & Failover is easier since no state needs to be preserved. High scalability since a client call can be Served by any EJB server in a clustered architecture.

A stateless session bean is an enterprise bean that provides a stateless service to the client. Conceptually, the business methods on a stateless session bean are similar to procedural applications or static methods; there is no instance state, so all the data needed to execute the method is provided by the method arguments. The stateless session bean is an EJB component that implements the javax.ejb.SessionBean interface and is deployed with the declarative attribute "stateless".

Stateless session beans are called "stateless" because they do not maintain conversational state specific to a client session. In other words, the instance fields in a stateless session bean do not maintain data relative to a client session. This makes stateless session beans very lightweight and fast, but also limits their behavior. Typically an application requires less number of stateless beans compared to stateful beans.

Read more...

Stateful Session Beans

A Stateful session bean maintain the state of the conversation between the client and itself. When the client invokes a method on the bean the instance variables of the bean may contain a state but only for the duration of the invocation.

Stateful session bean will retain client specific state (session state) from one method invocation to the next, her bean instances are to be maintained for each client. A stateful session bean is an enterprise bean (EJB component) that acts as a server-side extension of the client that uses it. The stateful session bean is created by a client and will work for only that client until the client connection is dropped or the bean is explicitly removed.

A stateful session bean is an enterprise bean (EJB component) that acts as a server-side extension of the client that uses it. The stateful session bean is created by a client and will work for only that client until the client connection is dropped or the bean is explicitly removed. Stateful session beans are usually developed to act as agents for the client, managing the interaction of other beans and performing work on behalf of the client application.

The stateful session bean is EJB component that implements the javax.ejb.SessionBean interface and is deployed with the declarative attribute "stateful". Stateful session beans are called "stateful" because they maintain a conversational state with the client. In other words, they have state or instance fields that can be initialized and changed by the client with each method invocation. The bean can use the conversational state as it process business methods invoked by the client.

Read more...

EJB Session Beans

Session Beans in EJB

Session beans are Java components that run in either stand-alone EJB containers or EJB containers that are part of standard Java Platform, Enterprise Edition (Java EE) application servers. A Session bean represents a single client inside the J2EE server. To access the application deployed in the server the client invokes methods on the session bean. The session bean performs the task shielding the client from the complexity of the business logic.

These Java components are typically used to model a particular user task or use case, such as entering customer information or implementing a process that maintains a conversation state with a client application. Session beans can hold the business logic for many types of applications, such as human resources, order entry, and expense reporting applications.

Session bean components implement the javax.ejb.SessionBean interface. Session beans can act as agents modeling workflow or provide access to special transient business services. Session beans do not normally represent persistent business concepts.

Types of Session Beans:

There are two types of session beans, namely: Stateful and Stateless session beans.

Stateful session beans maintain conversational state when used by a client. Conversational state is not written to a database, it’s state that is kept in memory while a client uses a session.Maintaining conversational state allows a client to carry on a conversation with an enterprise bean.

Stateless session beans do not maintain any conversational state. Each method is completely independent and uses only data passed in its parameters.

A session bean corresponds to a client server session. The session bean is created when a client requests some query on the database and exists as long as the client server session exists.

Read more...

Message Driven Bean

What is Message Driven Bean ?

Message driven beans will provide asynchrony to EJB based applications by acting as JMS message consumers. A message bean is associated with a JMS topic or queue and receives JMS messages sent by EJB clients or other beans.

Message driven beans are the latest addition to the family of component bean types defined by the EJB specification. The original bean types include session beans, which contain business logic and maintain a state associated with client sessions, and entity beans, which map objects to persistent data.

Unlike entity beans and session beans, message beans do not have home or remote interfaces. Instead, message driven beans are instantiated by the container as required. Like stateless session beans, message beans maintain no client-specific state, allowing the container to optimally manage a pool of message-bean instances. Clients send JMS messages to message beans in exactly the same manner as they would send messages to any other JMS destination. This similarity is a fundamental design goal of the JMS capabilities of the new specification.

To receive JMS messages, message driven beans implement the javax.jms.MessageListener interface, which defines a single "onMessage()" method. When a message arrives, the container ensures that a message bean corresponding to the message topic/queue exists (instantiating it if necessary), and calls its onMessage method passing the client's message as the single argument. The message bean's implementation of this method contains the business logic required to process the message. Session beans and entity beans are not allowed to function as message beans.

Read more...

Enterprise Java Beans (EJB)

Enterprise Java Beans:

Enterprise JavaBeans (EJB) technology is the server-side component architecture for Java Platform, Enterprise Edition (Java EE). EJB technology enables rapid and simplified development of distributed, transactional, secure and portable applications based on Java technology.

Bean can be called as a reusable component. Enterprise Java Bean is a bean designed to run inside an EJB server. EJB is supplemented by a deployment descriptor, an XML file which provides the container with information about how the bean is to be deployed.

EJB Roles:

Enterprise Bean Provider - application domain expert who writes the Java code and the deployment descriptor. Work product is ejb jar files.

Application Assembler - assembles beans into larger units and with other components such as JSP..etc and also producing jar files.

Deployer - installs the jar files in specific environment

Server provider - provides the environment to run EJBs in different servers such as BEA, IBM, Sun. etc.

Container provider - provides the thing the server runs in.

EJB class will interact with other EJBs via interfaces.

Different Types of EJB's:

Session Beans -- represent an interaction or work process which lies on behalf on the client.

Stateless Session Beans - No information will be retained by the object between method calls

Stateful Session Beans - Data will be retained by the object

Entity Beans - represent persistence objects, typically stored in a database.
They are of two types.

Container managed persistence -- Mean the server generates the necessary SQL to insert/update/delete data.

Bean managed persistence -- Programmer writes the necessary code

Message Beans -- process Java Message Service (JMS) messages

Interfaces in EJB:

Entity and Session Beans can support two kinds of client interfaces

Home interfaces Used to create, find and destroy bean instances this will be Obtained via a name (JNDI)

Business interface Provides business logic API, Obtained from home interfaces

Interface versions:

Remote interfaces can be used anywhere and are most flexible.

Local interfaces can only be used inside the EJB server but these are more efficient

Bean class have to implement SessionBean or EntityBean interfaces.

Remote interface will extend javax.ejb.EJBObject class

Home interface will extend javax.ejb.EJBHome class

Archive files:

Java archive (jar) files are used to package data for deployment
ear - Enterprise Archive file
war - Web archive file
rar - resource adapter

Read more...