EJB 3
- Which of the beans available in EJB 3 are only called by clients ?
Session and Singleton (EJB 3.1) beans are the ones who encapsulate the business logic which is why it is the only bean which is called by clients. Other beans like MDB and Entity beans are called by session and singleton beans to complete the business requirement. - Why is it so to make the session beans into two parts one with interface and the other as impl to the interface ? Or why session beans should be used through business interface ? ( EJB 3.0 Specific ).
This approach promotes loose coupling since implementation classes can easily be swapped out without a lot of code changes.But in recent EJB 3.1 specification you don't need to implement a business interface for faster development. - What is business interface ?
An interface through which a client invokes the bean is called a business interface. There are three types of business interfaces available in EJB 3 : Local, Remote and WebService. - Now in latest version of EJB the dependency injection is available , Do we still need JNDI lookups for getting the business interface ?
Yes, Our so called dependency Injection is actually a wrapper over JNDI lookups. The Injected object is actually JNDI looked up by the container and injected to the desired place. What happens inside, is that the same old JNDI lookup (which is done by the container) for our convenience.
There are places where you will have to use JNDI lookup , where container is not available. Means that, if the container is not there then how would you get the remote object ? The only answer is JNDI. - What are the criteria for a method to be a life cycle method ?
A life cycle method can be of any name and any specifier , a return type void and no argument ex : private void cleanup();
Appropriate annotation should be used. ex: @PostConstruct, @PreDestory in case of stateless beans and additional @PrePassivate and @PostActivate for stateful session beans.
It is not necessary to have a life cycle method declared in the business interfaces.Only implementation in the business implemented classes (ie Bean classes) is required.
The method should not throw any checked exception. - How do you invoke EJB 3.0 from Servlet and JSP ?
In Servlet the @EJB annotation or alternatively JNDI look up (old way) can be used to get hold of can be EJB objects. The following code snippet shows how to do it through EJB injection.
EJB Injection through @EJB
public class MyEjbServlet extends HttpServlet {
@EJB
private HelloUserLocal helloUser;
public void doGet(HttpServletRequest request,HttpServletResponse response) throws ServletException, IOException {
//use the injected resource
helloUser.sayHello();
....
...
}
}
JSP however is not supported to inject. And moreover one should not call/invoke EJB in JSP , since it violates design principles.But if one must then , following code should help :
<%@ page import="javax.naming.*, javax.rmi.PortableRemoteObject,
foo.HelloWorldLocal" %>
<%!
//declare a "global" reference to an instance of the home interface of the session bean
HelloWorldLocal helloUser=null;
public void jspInit()
{
//obtain an instance of the home interface
InitialContext cntxt = new InitialContext( );
Object ref= cntxt.lookup("java:comp/env/ejb/HelloWorldLocal");
helloUser = (HelloWorldLocal)PortableRemoteObject.narrow(ref,HelloWorldLocal.class);
}
%>
<%
//call the object
helloUser.sayHello("SomeName);
%> - Can we maintain state with a stateless session bean ?
The answer is NO. Not at least the EJB way. EJB doesn't retain information in stateless session bean. However you can trick the container by using external class serialized with state information and stored in the file system and upon the next call to the method ( where in you are expecting state of earlier call) you can read the serialized data back.Also you need to make sure the data consistency between client calls and so many other things. With this trick you will end up doing what EJB container does for a stateful beans. If you still feel this trick is a good idea, be my guest . - Can we have instance fields in Stateless session bean ?
Yes. A stateless session bean can have instance field, BUT not for storing state information as opposed to Stateful beans. There may be a need of storing certain shareable resources like data source , JMS source etc, which will be used in the exposed method. So it is perfectly safe to have instance fields in the Stateless session beans - Can you inject Stateful beans into stateless session bean or Servlet ?
Yes!!. No body stops you to inject Stateful beans into stateless session bean or a Servlet. Lets take a Servlet and inject (definitely as a field in Servlet) a Stateful bean; What happens ? Container creates a single instance of a Servlet, so the instance field of Servlet ( which is a Stateful Bean ) injected , is shared among clients.It will lead to drastic data inconsistency ( stored in Stateful bean ) being shared by clients. And this is no different for a Stateful bean injected into stateless bean.So you must AVOID injecting into stateless beans and Servlets. Please don't ask how do you access or make use of Stateful bean in Stateless or Servlet.The answer is JNDI inside the methods of Stateless and doGet() or doPost() of Servlet. - What could be wrong if instead of doing JNDI look up or EJB injection of a Bean named UserRemoteBean I created the instance of the same in the follwing way UserRemoteBean urb=new UserRemoteBean(); and started using it in the client application?
- Can you pool stateful session beans ? Justify your answer.
- Why can't you have a stateful bean marked as @WebService ?