The factors that will help to decide on local or remote access are:

1. 1. Tight or loose coupling of related beans : Tightly coupled beans depend on one another. Tightly coupled beans are good candidates for local access.  Because they fit together as a logical unit, they typically call each other often and would benefit from the increased performance that is possible with local access.

2. 2. Type of client : If an enterprise bean is accessed by application clients (Java SE clients), it should allow remote access. If an enterprise bean’s clients are web components or other enterprise beans (Java EE clients), the type of access depends on how you want to distribute your components.

3. 3. Component distribution :  Java EE applications are scalable because their server-side components can be distributed across multiple machines. In distributed scenario, the enterprise beans should allow remote access.

4. 4. Performance : Owing to such factors as network latency, remote calls may be slower than local calls. On the other hand, if you distribute components among different servers, you may improve the application’s overall performance. Both of these statements are generalizations; performance can vary in different operational environments.

If you aren’t sure which type of access an enterprise bean should have, go for remote access. This decision gives you more flexibility. Although it is uncommon, it is possible for an enterprise bean to allow both remote and local access.

Stateful session beans are appropriate if any of the following conditions are true:

1. The bean’s state represents the interaction between the bean and a specific client.
2. The bean needs to hold information about the client across method invocations.
3. The bean mediates between the client and the other components of the application, presenting a simplified view to the client.
4. Behind the scenes, the bean manages the work flow of several enterprise beans.

For example, a shopping cart in an online shopping application can be represented as a stateful session bean. A user can add several items to shopping cart one by one and then call checkout. The shopping cart instance represents the conversational state of the person shopping who is the client; it can be discarded when the client completes the purchase of the shopping cart contents and it is emptied. Its state is the current contents.

Singleton session beans are appropriate in the following circumstances:

1. State needs to be shared across the application.
2. A single enterprise bean needs to be accessed by multiple threads concurrently.
3. The application needs an enterprise bean to perform tasks upon application startup and shutdown.

An application hit counter is a good example of Singleton session bean. Loading a global daily price list that will be the same for every user might be done with a singleton session bean, since this will prevent the application having to do the same query to a database over and over again.

A message-driven bean is an enterprise bean that allows Java EE applications to process messages asynchronously. This type of bean normally acts as a JMS message listener, which is similar to an event listener but receives JMS messages instead of events. Message driven beans are used to receive messages asynchronously.

For example, in an on-line shopping application, where the process of taking an order from a customer results in a process that issues a purchase order to a supplier, the supplier ordering process could be implemented by a message-driven bean. While taking the customer order always results in placing a supplier order, the steps are loosely coupled and asynchronous because it is not necessary to generate the supplier order before confirming the customer order.

The EJBContext interface provides an instance with access to the container-provided runtime context of an enterprise bean instance.This interface is extended by the SessionContext, EntityContext, and MessageDrivenContext interfaces to provide additional methods specific to the enterprise interface bean type. EJBContext objects provide the bean class with information about its container, the client using the bean and the bean itself.

Although technically it is legal, static initializer blocks are used to execute some piece of code before executing any constructor or method while instantiating a class. Static initializer blocks are also typically used to initialize static fields – which may be illegal in EJB if they are read/write. In EJB this can be achieved by including the code in either the ejbCreate(), setSessionContext() methods.

The EJB specification assigns to the EJB container the responsibility for managing threads. Allowing enterprise bean instances to create and manage threads would interfere with the container’s ability to control its components’ lifecycle.

Thread management is not a business function, it is an implementation detail, and is typically complicated and platform-specific. Letting the container manage threads relieves the enterprise bean developer of dealing with threading issues.

Containers deny enterprise beans the privilege to manage threads for three basic reasons: Resource management, security, and thread-sensitive storage.

There are two phases in the life cycle of a JSP:

1. Translation and Compilation Phase
2. Execution Phase

During the translation and compilation phase the container creates a servlet for the JSP from the source file. A JSP page services client requests as a servlet. When a request is mapped to a JSP page, the web container first checks whether the JSP page’s servlet exists and if it exists, whether it is older than the JSP page. If the servlet is older, the web container translates the JSP page into a servlet class and compiles the class. During this phase, the container interprets the scripting elements, directives and actions, and the custom actions referencing tag libraries used in the page.

During the execution phase the JSP container executes the servlet generated from the JSP page. If an instance of the JSP page’s servlet does not exist, the container:

1. Loads the JSP page’s servlet class
2. Instantiates an instance of the servlet class
3. Initializes the servlet instance by calling the jspInit method

The container invokes the _jspService method, passing request and response objects. If the container needs to remove the JSP page’s servlet, it calls the jspDestroy method.

The elements in JSP are:

1. JSP Scripting Elements : JSP scripting elements are written inside <% %> tags. The code inside <% %> tags are processed by the JSP engine during the translation phase of the JSP. There are three forms:
   1. Expression – <%= Java expression %>, the expression is evaluated and inserted into output
   2. Scriptlet – <% code %>, which goes into the service method of the servlet generated
   3. Declarations – <%! code %>, the code is inserted into the body of the servlet class outside of the methods

2. JSP Comments : Used to write a comment in JSP page. The comments are hidden and removed during the translation phase. Represented in the form <%– This is a comment –%>. An alternative way to place a comment in JSP is to use the comment mechanism of the scripting language in the form <% /** This is a comment … **/ %>

3. JSP Directives : JSP Directives are used to give special instruction to container for translation of JSP to Servlet code. JSP Directives are placed between <%@ %>. JSP provides three directives:
   1. page directive – <%@ page …. %>
   2. include directive –  <%@ include …. %>
   3. taglib directive-  <%@ taglib …. %>

4. Standard Action Tags : JSP specification provides a set of standard JSP tags for use within JSP pages. These tags are used to eliminate the usage of scriptlet and simplify JSP page development and maintenance.  All the standard actions in JSP has a default prefix “jsp”.

5. Custom Action Tags : JSP technology provides a mechanism for encapsulating other types of dynamic functionality in custom tags, which are extensions to the JSP language. User defined tags in JSP are known as custom action tags or custom tags. Custom tags increase productivity because they can be reused in more than one application. Custom tags are distributed in the form of a tag library.

In JSP, some objects are created implicitly. The implicit objects are available for use within scriptlets and scriptlet expressions. Each implicit object  has a class or interface type defined in a core Java technology or Java Servlet API package.

Implicit objects available in JSP are:

1. request – An object of javax.servlet.http.HttpServletRequest associated with the request
2. response – An object of javax.servlet.http.HttpServletResponse associated with the response to the client
3. pageContext – An object of javax.servlet.jsp.PageContext which represents the context for the JSP page. Provides access to various objects of the page.
4. session – An object of  javax.servlet.http.HttpSession associated with the client.
5. application – An object of  javax.servlet.ServletContext that represents the servlet context obtained from the servlet configuration object
6. out – An object of  javax.servlet.jsp.JspWriter that writes into the output stream
7. config – An object of javax.servlet.ServletConfig  associated with this JSP page
8. page – An object of java.lang.Object which represents the instance of the current page’s implementation class processing the current request
9. exception – An object of java.lang.Throwable represents the uncaught Throwable that resulted in the error page being invoked