EJB Interview Questions And Answers for freshers and experienced

EJB is a standard for building server side components in JAVA. It specifies an agreement between components and application servers that enables any component to run in any application server. EJB components are deployable and can be imported in to an application server which hosts these components. EJB are not intended for client side they are server side components. They are specially meant for complex server side operations like executing complex algorithms or high volume business transactions.

Above is the most popular architecture in software industry. Three tier architecture has many advantages but the most important of them is that you can change any layer with least changes. For instance you can change the business logic with out making changes to UI or the database side. EJB provides the application layer logic. Application layer logic is also called as middle tier. EJB provides a standard specifications-based way to develop and deploy enterprise-class systems. It’s like moving towards an actually thought JAVA dream that we can run on any vendor platform. This is in contrast to the vendor-specific way we used to develop where each application server had its own way of doing things and where the developer was tied up to a application server.

There are three kinds of EJB’s:-

Session beans
Session beans are construct in EJB. They represent business logic of an application. They represent a group of logical related functionality. For instance you can have a customer session bean which can have functionality like customer interest calculation, customer reporting, customer tax calculation etc. But as these functionalities logically belong to customer they will be included in the customer session bean. In short session bean has business logic.
There are two types of session beans:-
Stateless: - they do not maintain state across method calls. So every time client makes a call it’s like a new object from scratch. Stateful— These beans can hold client state across method invocations. This is possible with the use of instance variables declared in the class definition. Every time the client calls it they can get there previous states. Stateless session bean provide greater scalability as EJB container does not have to maintain state across method invocations. Storing state for EJB container is huge activity.

Entity beans
Entity bean represent persistent data in an EJB application. They provide object-oriented abstraction to a relational database. When Session bean needs to access data it called the entity beans. Entity beans do read, write, update and delete from tables. For instance you have a customer table then you will have customer entity bean which maps to the table and can do the CRUD (Create, Read, Update and Delete) operation to the customer table. From architecture angle you can think entity bean as the data access layer of a system.

Message-driven beans
There are situations in project where you would like to communicate asynchronously with some other systems. This is achieved by using message-driven beans. For instance when user places order you would like to submit it asynchronously to the order system and then move ahead with some other work. You would then later comeback after sometime to see if the order is completely or the order system will notify you about the completion of the order.

Session beans should only implement business logic and work flow.
Entity beans are data objects and represent persistent data. They are only responsible to do database activities like add, update and delete
Message-driven beans are used for receiving asynchronous messages from other systems.

Bean Interface
Client uses the Bean interface to communicate with the session bean which resides on the EJB application server. The Bean interface extends the EJBObject interface of the javax.ejb package. This interface has all the methods, functions which the final session bean has.
Home Interface
In order the client gets a reference to the Bean interface it must call the Beans home interface. The Home interface extends EJBHome interface of the javax.ejb package. Home Interface of a bean is responsible for creating the object and giving the reference of the Bean interface.

Local objects implement local interface rather than using remote interface. Just to have a comparison below are the steps how the local object works. JAVA client calls the local object. Local object does connection pooling, transactions and security. It then passes calls the bean and when bean completes its work it returns the data to the Local object who then passes the same to the end client. You can understand from the above steps we have by passed completely marshalling and de-marshalling. .

Local object only work if you are calling beans in the same process. Second they marshal data by ref rather than by Val. This may speed up your performance but you need to change semantics for the same. So finally it’s a design and the requirement decision. If you are expecting to call beans remotely then using local object will not work.

When we are dealing with stateful session beans we need to store the client conversation of the bean so that it can be available in client’s next request. But when we talk about server it has limited resources. If the conversation of the bean is large then the server can run out of resource. So in order to preserve resources EJB server swaps this conversational data in memory to hard disk thus allowing memory to be reclaimed. This process of saving the memory data to hard disk is called as “Passivation”. Now when the client comes back the conversational data is again swapped from the hard disk to the bean. This process is called as “Activation”. The container informs the bean that its about to passivate or activate using the "ejbPassivate()" and "ejbActivate()" methods.

NO

Most servers use the (LRU) Last Recently Used time as a strategy. Which mean passivate the beans which have been called recently.

Bean conversational data is saved in the disk as serialized object. This is possible because “javax.ejb.EnterpriseBean” implements “java.io.Serializable” interface. So during passivation time it converts the bean conversational data to a bit-blob and during activation it just reverses the process.