Enterprise Beans

Enterprise Beans

Enterprise beans are Java EE components that implement Enterprise JavaBeans (EJB) technology. Enterprise beans run in the EJB container. The EJB container provides system-level services, such as transactions and security, to its enterprise beans

What Is an Enterprise Bean?

An enterprise bean is a server-side component that encapsulates the business logic of an application. The business logic is the code that fulfils the purpose of the application.

For Example :

In an ecommerce site the enterprise beans might implement the business logic in methods called checkOut and orderProduct. By invoking these methods, clients can access the services provided by the application.

Benefits of Enterprise Beans

Enterprise beans simplify the development of large, distributed applications.

• The EJB container provides system-level services to enterprise beans, the bean developer can concentrate on solving business problems. The EJB container, rather than the bean developer, is responsible for system-level services, such as transaction management and security authorization.
• The beans contain the application’s business logic, the client developer can focus on the presentation of the client. The client developer does not have to code the routines that implement business rules or access databases. As a result, the clients are thinner, a benefit that is particularly important for clients that run on small devices.
• Enterprise beans are portable components, the application assembler can build new applications from existing beans. Provided that they use the standard APIs, these applications can run on any compliant Java EE server.

When to Use Enterprise Beans

• The application must be scalable.
• Transactions must ensure data integrity. Enterprise beans support transactions, the mechanisms that manage the concurrent access of shared objects.
• The application will have a variety of clients. 

There are two types of enterprise beans.

• Session Beans : Performs a task for a client; optionally, may implement a web service
• Message-driven Beans : Acts as a listener for a particular messaging type, such as the Java Message Service API

JSP Lifecycle

JSP Lifecycle

The lifecycle of a JSP is the entire process from its creation till the destruction which is similar to a servlet life cycle with an additional step, which translates the JSP into a Servlet.

Following are the JSP Lifecycle phases.

1.     Translation of JSP to Servlet code.

2.     Compilation of Servlet to bytecode.

3.     Loading Servlet class.

4.     Creating servlet instance.

5.     Initialization by calling jspInit() method

6.     Request Processing by calling _jspService() method

7.     Destroying by calling jspDestroy() method

JSP Lifecycle

JSP Translation and Compilation

When a user request for a JSP, the JSP engine first checks to see whether it needs to compile the page. If the page has never been compiled, or if the JSP has been modified since it was last compiled, the JSP engine does the following

1.   Parse the JSP

2.   Transforms the JSP to a Servlet

3.   Compile the Servlet (.java) file to a class file.

JSP Initialization

Before servicing any request the web container loads the JSP and invokes jspInit() method. Initialization is performed only once, just as with servlets init() method. If you need to perform any JSP-specific initialization, you need yo override the jspInit() method.

JSP Service

Once the JSP page has been loaded and initialized, the JSP engine invokes the _jspService() method in the JSP.

The _jspService() method takes an HttpServletRequest and an HttpServletResponse as its parameters.

The _jspService() method of a JSP is invoked once per request and is responsible for generating the response for that request.

JSP Destruction

The destruction phase of the JSP life cycle represents when a JSP is being removed from use by a container.

The jspDestroy() method is the JSP similar to the destroy method for servlets. We need to Override jspDestroy() method when we need to perform any cleanup operation, such as releasing database connections or closing files which were opened.

Difference Between Servlet and JSP

This post highlights the difference between JSP and Servlet technologies.

Java Servlet technology and JavaServer Pages (JSP pages) are server-side technologies that become the standard way to develop web applications.

Most importantly, if used effectively by following best practices, servlets and JSP pages help separate presentation from content.

Servlets support a request and response programming model. When a client sends a request to the server, the server sends the request to the servlet. The servlet then constructs a response that the server sends back to the client. When a client request is made, the service method is called and passed a request and response object. The servlet first determines whether the request is a GET or POST operation. It then calls one of the following methods: doGet or doPost. The doGet method is called if the request is GET, and doPost is called if the request is POST.

Adding more, Servlets are Java classes that can generate dynamic HTML content using print statements.

out.println("<html><head><title>"+thisIsMyMessage+"</title></head>");

So, you can embed HTML code into Java code.

A JSP page is basically a web page with traditional HTML and bits of Java code. The file extension of a JSP page is .jsp rather than .html or .htm, which tells the server that this page requires special handling that will be accomplished by a server extension. When a JSP page is called, it will be compiled (by the JSP engine) into a Java servlet.

Importantly, we can add dynamic content or Java Code inside an HTML Tag using JSP’s Scriplets.

And scriptlets, this is code fragments like:

<% String message = "Hello !"%>

<H2> Welcome and  <%=message%>! </H2>

So, you can embed Java code into HTML code.

SERVLET	JSP
A servlet is a server-side program and written purely on Java.	JSPs are HTML pages with .jsp extension. JSP’s are extension of servlets to minimize the effort of developers to write User Interfaces using Java programming.
Executes inside a Web server, such as Tomcat	A JSP program is compiled into a Java servlet before execution. Once compiled into a servlet, it's life cycle will be same as of servlet. But, JSP has it's own API for the lifecycle.
Servlets run faster than JSP	JSP runs slower because it has the transition phase for converting from JSP page to a Servlet file.
Servlet has the life cycle methods init(), service() and destroy()	JSP has the life cycle methods of jspInit(), _jspService() and jspDestroy()
Difficult to write as one has to write HTML tags within quotes(“<HTML>”) in Java. Mixing HTML content inside Java is tedious.	Easier to write than servlets as it is similar to HTML
Written in Java, with a few additional APIs specific to this kind of processing. Since it is written in Java, it follows all the Object Oriented programming techniques.	One of the key advantage is we can build custom tags using JSP API ,  which can be available as the re-usable components with lot of flexibility
In MVC architecture Servlet acts as controller.	In MVC architecture JSP acts as view.
Servlet advantages include: ·  Performance: get loaded upon first request and remains in memory indefinitely. ·  Simplicity: Run inside controlled server environment. ·  Session Management : overcomes HTTP's stateless nature ·  Java Technology : network access, Database connectivity, j2ee integration	JSP Provides an extensive infrastructure for: ·         Tracking sessions. ·         Managing cookies. ·         JSP is Extensible: Can create custom tags to extend the JSP functionality. ·         Separation of roles: Clearly identifies separation of roles for Developers, Content Authors/ Graphic Designers/ Web Masters.

What is the difference between doGet () and doPost ()?

While using doGet() or doPost() prefer using doPost() because it is secured and it can send much more information to the server.

GET or doGet()

GET is the simples HTTP method, and its main purpose is to ask a server to get a resource and send it back. The resource can be an HTML page, an image , a PDF etc.

• The request parameters are transmitted as a query string appended to the request.
• All the parameters get appended to the URL in the address bar.
  http://example.com/search?emp_name=sanjay 
• Allows browser bookmarks but not appropriate for transmitting private or sensitive information. 
• In an HTML you can specify as follows:
  <form name=”myForm” method=”GET” >
• GET was originally intended for static resource retrieval.
• GET is not appropriate when large amounts of input data are being transferred.

POST or doPost()

HTTP Post request is more powerful and used by the browser to make complex requests on the server. For example the user fills up a form and submit the data , which is then supposed to be inserted into a database.

The request parameters are passed with the body of the request.

More secured. In HTML you can specify as follows:

<form name=” myForm” method=”POST” >

POST was intended for form submits where the state of the model and database are expected to change.

Since POST sends information through a socket back to the server and it won’t show up in the URL address bar, it can send much more information to the server.

Unlike doGet(), it is not restricted to sending only textual data. It can also send binary data such as serialized Java objects.

What is MVC architecture in J2EE

MVC stands for Model-View-Controller architecture. It promotes loose coupling between components by separating the functionality of displaying and maintaining of the data. It is often used by applications that need the ability to maintain multiple views like HTML, WML, Swing, XML based Web service etc. Multiple views and controllers can interface with the same model. Even new types of views and controllers can interface with a model without forcing a change in the model design.

To summarize the MVC does the following

• Separation of Model from View components makes it possible to implement several user interfaces that reuse the common core business logic.
• Duplication of low-level Model code is eliminated across multiple UI implementations.
• Decoupling of Model and View code results in an improved ability to write unit tests for the core business logic code.
• Modularity of components allows core logic developers and UI developers to work simultaneously without affecting the other.

  

A model represents the core business logic and state. A model commonly also maps to data the database and will also contain core business logic.

• Manages the app data and state
• Not concerned with UI or presentation
• Often persists somewhere
• Same model should be reusable, unchanged in different interfaces

  

A view renders the contents of a model. A view accesses the data from the model and adds display logic to present the data. 

• Present the Model to the user in an appropriate interface
• Allows user to manipulate data
• Does not store any data.
• Easily reusable & configurable to display different data

A controller acts as the glue between a model and a view. A controller translates interactions with the view into actions to be performed by the model. User interactions in a Web application appear as GET and POST HTTP  requests. The actions performed by a model include activating business processes or changing the state of the model. Based on the user interactions and the outcome of the model actions, the controller responds by selecting an appropriate view.

• Intermediary between Model & View
• Updates the view when the model changes
• Updates the model when the user manipulates the view

MVC pattern decouples how data is manipulated from how data is displayed or stored. MVC is a way of developing apps by keeping the data (model) used in the program, and the visual (view) component separate from one another, each interacting only with a controller containing the logic. The view and the model interact only with the controller NEVER with each other.

MVC