J2EE

JAVA

What is J2EE

The Java 2 Platform, Enterprise Edition (J2EE) is the Java architecture for developing multitier enterprise applications. As part of J2EE, JSP pages have access to all J2EE components, including JavaBeans and Enterprise JavaBeans components and Java servlets. JSP pages are actually compiled into servlets, so they have all of the benefits of these flexible, server-side Java applications. The J2EE platform containers manage the complexities of enterprise applications, including transaction management and resource pooling.

JSP pages have access to all of the standard J2EE services, including:

Java Naming and Directory InterfaceTM API

JDBCTM API (communicating with relational databases)

JavaMailTM (classes supporting Java-based mail and messaging applications)

JavaTM Message Service (JMS)


Through J2EE, JSP pages can interact with enterprise systems in many ways. J2EE supports two CORBA-compliant technologies: Java IDL and RMI-IIOP. With Enterprise JavaBeans technology, JSP pages can access databases using high-level, object-relational mappings.

Finally, because JSP technology was developed through the Java Community Process, it has wide support from tool, Web server and application server vendors. This enables users and partners take a best-of-breed approach, selecting the best tools for their specific applications while protecting their investment in code and in personnel training.

The 3-Tier/n-tier Architecture

The three tier architecture evolved to solve the problems faced in 2-tier architecture.

J2EE Application Architecture Overview

A J2EE- based application (or any distributed system for that matter) can in general be classified into a set of
layers as shown below:

J2EE Platform

J2EE is one of the best solutions that we have had so far for meeting the demand of today’s enterprise. J2EE
specifies both the infrastructure for managing your applications, and the service API’s for building your
application. It Provides:
• A set of Java extension APIs to build applications. These API’s define a programming model for J2EE
applications.
• A run-time infrastructure for hosting and managing applications. This is the server runtime in which your
applications reside. This is also known as container.

J2EE APIs
These are some of the APIs supported by the J2EE platform:
• JDBC (Java Data Base Connectivity)
• EJB (Enterprise Java Bean)
• Java Servlet
• JSP (Java Server Pages)
• JMS (Java Messaging Services)
• JTA (Java Transaction API)
• Java Mail
• JAXP (Java API for XML Parsing/Processing)
• JCA (Java Connector Architecture)
• JAAS (Java Authentication and Authorization Service)
• RMI-IIOP (RMI – Internet Inter ORB Protocol)
• JNDI (Java Naming and Directory Interface)

J2EE Server/Container Architecture (container centric)
A J2EE container is a runtime to manage application components developed according to the API
specifications, and to provide access to the J2EE API’s. It is container centric i.e. components are managed by
the container.

Container Architecture:
 

Intro Web Application

Java Application Types

This section reviews different types of Java applications before moving on to Servlets.
Java can be used to develop different types of applications:
• Standalone Applications
• Applets
• Web Applications
• Distributed Applications

Standalone Applications
A standalone application is a program that runs on your computer. It is more or less like a C or C++ program.

Applets
An applet is an application designed to travel over the Internet and to be executed on the client machine by a
Java-Compatible web browser like Internet Explorer or Netscape. Applets are also Java programs but they
reside on the servers. An applet can not be executed like standalone application. Applet can be executed only
by embedding it into an HTML page like an image or sound file. To run an applet you need to access an HTML
page which has applet embedded into it. When the web browser downloads such an HTML page, it
subsequently loads the executable file, which contains Applet and then executes it on the local machine.

Web Applications
Web applications run on the Web Server. Web applications are accessed through web clients i.e. web browsers
like Internet Explorer or Netscape. Whenever you access some web site by specifying the URL (Universal
Resource Locator), you are accessing some web application. The main components of a web application written
in Java are:

Java Servlets
Java Server Pages (JSP), and
HTML

Java Servlets are also Java programs, which run on the Server and then send the result/response to the client.
JSP pages can be thought of as a combination of HTML and Java Code. The Web Server converts JSP pages
into Java Servlets before execution.

You access the web application by specifying the URL. If the URL corresponds to an HTML page the web
server simply returns the HTML page to the client, which then displays it. If the URL corresponds to the Servlet
or JSP then it is executed on the Server and the result/response is returned to the client, which is then displayed
by the client.

Distributed Applications
Java application can be divided into a number of modules/components (Java programs), which can run on
different machines. The Java programs/applications running on different machines can communicate with each
other. To be more precise the Java Objects on one machine can invoke methods on the Java Objects running on
another machine. Thus Java has the support for the distributed processing in the language itself.

Introduction to Web-Application

Almost everyone has accessed a web-site. A web application is nothing but a web-site. A web application can
be thought of as a collection of two types of resources:
• Static Resources
• Dynamic Resources
Web applications are deployed on the web servers (web-containers) and are normally accessed through the Web
Clients, which is normally a web browser. The communication between web client and web server takes place
through HTTP protocol.




Static Resources
These are normally non-executable resources. In some cases static resources may also be the executable
resources but they do not execute on the server.
A typical web application might have following types of static resources:
• HTML
• Images, Audio and Video files
• Applets
• Documents
• Spreadsheets
• Text files
A web client can ask for any static resource by just specifying the URL. Web server simply returns the specified
resource to the client without doing any processing. The client decides what to do with the static resource. The
most common static resource is the HTML page. The web browser parses the HTML page and displays in the
browser window. For other type of static resources the action taken may differ from browser to browser. The
browser either displays the contents of the resource on its own or with the help of software corresponding to the
static resource. For example, Internet Explorer may open a .doc file using MS-Word software. The browser
prompts for saving the contents in case it is not able to display/process the contents.

Dynamic Resources
These are executable resources. A web application can have following type of dynamic resources:
• Servlets
• Java Server Pages
The dynamic resources are also accessed by directly or indirectly specifying the URL. But the action taken by
web server is different in case of dynamic resources. The dynamic resources are Java programs. The server
executes the appropriate component and then returns the result to the client normally as HTLM using HTTP
protocol.

Servlets
Java servlets are small, platform independent server side programs that programmatically extend the
functionality of the web server. The java Servlet API provides a simple framework for building applications on
such web servers.

Java Server Pages
Java Server Pages is an extension of the Java servlets technology. However, in contrast to servlets, which are
pure Java programs, JSP pages are text-based documents. A JSP page contains two parts:
• HTML for the static content
• JSP tags and scriptlets written in java to encapsulate the logic that generates the dynamic content.
Since a JSP page provides a general representation of content that can produce multiple views depending on the
result of JSP tags and scriptlets, a JSP page acts like a template for producing content

Web Client (Thin Client)
In web client based architectures, the user interaction layer is separated from the traditional client layer. Web
browser manages the user interaction but leaves the rest to applications on the server side, including the logic
for driving the user interface, interacting with components in the middle-tier, and accessing databases.
Features of Web Clients
• A browser or a similar application to manage user interaction. For an end-user this is the client layer.
• HTML is normally used as the means of user interface definition.
• HTTP(s) is used as the information exchange protocol between the Web-Clients and Web Applications. The
Web Application programs on the web server side execute the application logic on behalf on browser
Clients.

Web Server and the Web Container
The web applications are deployed on the web servers. The web server handles all the communication between
web client and the web application. As discussed earlier a web application is simply collection of static and
dynamic resources. Any resource belonging to a web application is identified by a URL. The client can access
any resource by just specifying the URL. Web server might have some common resources, which do not belong
to any web application. Such resources are normally static resources. If client asks for some resource not
belonging to any application, the web server can directly send resource to the client.
If the client asks for some resource belonging to web application then it is not served directly by the web server.
Web server passes the request to the web container, which is a component responsible for running the web
applications.
If the resource is static then web container simply passes the resource to the web server and then web server
send the resource to the web container. On the other hand if the resource is dynamic then the web container
executes the resources and receives the result normally in the from of HTML and then passes the result to the
web server which then passes it to the web client.

The HTTP Protocol

The HTTP is an application – level protocol (generally implemented over TCP/IP Connection). The HTTP is a
stateless protocol based on requests & responses. In this paradigm, client application (such as your web
browser) sends request to the server (such as the web server of an online store) to receive info (such as
downloading a catalog) or to initiate specific processing on the server (such as placing an order).

HTTP Request Methods
As an application-level protocol, HTTP defines the types of request that clients can send to servers and the
types of response that servers can send to clients.
• The Get Request Method
• The Post Request Method

The Get Request MethodThe Get Request is the simplest & most frequently used request method for accessing static resources such as
HTML documents, image etc. The GET method is used when the resource is accessed by specifying the URL in
the web browser or by clicking on a hyperlink.
Get request can also be used to retrieve dynamic information by using additional query parameters in the
request URL of a dynamic resource.
http://www.domain.com?name=sumit
The data is transmitted as the part of URL if GET method is used.
Sometimes we employ GET method even when accepting data from the client using the form. In this case any
data provided in the form is appended to the URL as query parameters before sending to the server.

The Post Request Method
Post requests are used when we need to send large amount of complex information to the server. The Post
request allows the encapsulation of multi-part message into the request body. For example, you can use post
request to upload text & binary files.
Normally we send data using Post method through form by specifying “POST” as the method.
The data is transmitted as part of the body. So it is possible to send the large amount of data when using Post
request.

The Differences between Get & Post Requests
With get request, the request parameters are transmitted as a query string appended to the request URL. In the
case of post request, the request parameters are transmitted within the body of the request.

This has two ramifications:
• Firstly since a Get request contains the complete request info appended to the URL itself, it allows browser
to bookmark the page & revisit later. Depending on the type & how sensitive the request parameters are this
may or may not be desirable.
• Secondly some servers might pose restrictions on the length of request URL. This limits the amount of info
that can be appended to the request URL.
Note: The HTTP/1.1 does not impose any upper limit on the length. However server/clients complying only
with HTTP/1.0 may not support unreasonably long length.

Key Feature of HTTP
• HTTP is a very simple and lightweight protocol.
• In this protocol, the clients always initiate requests. The Server can never make a Callback Connection to
the Client.
• The HTTP requires the clients to establish connections prior to each request and the servers to close the
connection after sending the response. This guarantees that the client cannot hold on to a connection after
receiving the response. Either the client or the server can prematurely terminate the connection.

The Requirements for Developing & Hosting Web Applications
The following are the most essential requirements for developing and hosting web applications:
(i) A Programming Model and an API - for development of applications.
(ii) Server-side Runtime Support - This includes support for network services and a runtime for executing
the applications.
(iii) Deployment Support – Deployment is the process of installing the application on the server.
Deployment could also include customizing the application.

For building and running web applications, the J2EE provides the following to meet each of the above
requirements:

(i) Java Servlets & Java Server Pages
These are the building blocks for developing web Applications in J2EE. Java servlets & JSP pages are
called the Web Components.
(ii) Web Container for Hosting Web Applications
The web container is essentially a java runtime providing an implementation of the java servlets API and
other facilities for JSP pages. The Web container is responsible for initializing, invoking and managing
the life cycle of java servlets and Java Server pages.
(iii) Packaging Structure & Deployment Descriptor
The J2EE specification defines a packaging structure for web applications. The specification also
defines a deployment descriptor for each web application. The deployment descriptor is an XML file
that lets you customize the web application at deployment time.

          -----------------------------------------------------------------------------------