Enterprise applications solve business problems. This involves the safe storage, retrieval, and manipulation of business data. Java 2 Platform, Enterprise Edition, has sets of libraries developed by Sun Microsystems and the Java Community Process that represent uniform Application Programming Interface (API). J2EE is a Multi-tier architecture.

Enterprise applications are inherently complex. Thus, it is imperative to understand the characteristics of a good enterprise application. These characteristics may vary based on the domain of the application.

The characteristics of a good enterprise application are:

Reliability and Availability: The application should guarantee zero downtime to the enterprise. In other words, the application should run continuously without failure. Additionally, it should ensure that all transactions are processed completely and accurately.

Security: Since most business information is confidential and critical, software security is a vital part of any enterprise application.

Scalability: As a business grows, the number of users and consequently the demands on the application increase. Enterprise applications need to address these expanding needs by being scalable. The application must be able to handle the increase in usage with the optimum utilization of resources.

Based on their functional and non-functional requirements, enterprise applications can be modeled in different ways. The enterprise application models can be divided into the following three types:

·         2-tier architecture

·         3-tier architecture

·         n-tier architecture

2-tier architecture: In the 2-tier architecture, the presentation and business logic of an application is loaded in the client PC. The server acts as a data provider. The required data for a business process is obtained from the server and processed in the client. Typical 2-tier architecture is represented in Figure shown below.

Figure 1

                       

 

 

The 2-tier architecture has the following drawbacks:

Application performance is affected due to limited resources of the PC.

Network traffic will be greater because data required for processing should be fetched from data source on server side.

Even a small change in business logic should be updated in all client PCs, which could be difficult to carry out in a large enterprise.

3-tier architecture: In the 3-tier architecture the application is divided into three different logical layers. The first tier, referred to as the presentation layer, contains the GUI part of the application. The middle tier, known as the application layer or business layer, consists of the business logic of the application. The third tier or the bottom tier, referred to as the data layer, contains data required for the application. In a typical scenario the business and data layers are available in the server side, whereas the presentation layer is in the client side. The Figure illustrates the 3-tier architecture.

Figure 2  

n-tier architecture: In the n-tier architecture the application logic is divided based on the functionality performed. The n-tier architecture can be divided into the following categories:

Client tier

The client tier or the tier-O consists of the user interface. It deals with the different type of clients interacting with the application. The user may be a browser client accessing the server-side application through a firewall or a desktop Java client accessing it from within a firewall.

Middle tier

The middle tier consists of the following components.

Presentation logic: It deals with dynamic content to the clients, user requests, and responses.

Business logic: It deals with business rules and business processes of an application.

Infrastructure services: It provides additional functionalities required by the application components such as messaging and transaction.

Data tier

The data tier consists of the data layer which provides data for the application.

J2EE architecture is essentially a distributed architecture for developing multi-tier enterprise applications. Here, applications are divided into multiple tiers: the client-tier to provide a user interface, middle-tier modules to provide services and business logic, and backend EIS to provide data management. Figure illustrates the typical J2EE environment.

Figure 3

In the above figure the client tier could consist of various client types such as web clients, Standalone Java clients, PDAs, and hand held PCs. The client can access the application from inside or outside the corporate firewall.

The middle tier provides services to the client through the web tier or the EJB tier.

The web tier is used to connect web clients or Java clients from outside the firewall to the EIS.

EJB tier is used to connect Java clients inside the firewall and web clients (through the web tier) to the EIS.

The complete J2EE architecture is illustrated below.

Figure 4

 

 

J2EE offers the following benefits:

Simplified architecture and development

Scalability

Choice of tools for developing, testing and deploying J2EE applications

Integration with existing EIS’s

Flexible security model

 

J2EE platform specifies technologies to support multi-tier enterprise application. These technologies fall into the following three categories:

·         Component technologies

·         Service technologies

·         Communication technologies

We will now discuss the above technologies in detail.

Component technologies are used by developers to create essential parts of the enterprise application, namely user interface and business logic. In addition to JavaBeans, which are part of the J2SE platform, the J2EE platform supports different type of components that can be classified as client-side components and server-side components.

Client-side Components

Client-side components are developed by the application developers to provide user interface for enterprise application clients. These components can be classified as follows:

·         Application clients

·         Browser-based clients

Application clients are Java programs that execute on desktop computers. They are often referred to as standalone applications because they run on their own JVM. J2EE specification refers to application clients as GUI components.

J2EE must support application components and provide a container to run the application clients. However, an application client runs on the client machine and not on The J2EE server. The application client container is required to provide runtime support for standalone applications.

Brower-based clients are developed by the application developers to provide user interface for web clients. Web client applications are generally developed using simple HTML pages, although applets are also used at times.

Browser-based clients do not have an associated J2EE container. In order to access enterprise resources, web clients should communicate through the web container of the J2EE server. Applets embedded in HTML pages are deployed and managed on the J2EE server, although they run on client machines.

Server-Side Components

Server-side components are used for providing dynamic user interface and business logic. Server-side components are deployed in the J2EE server. Based on the functionality provided by server-side components, they are classified as:

·         Web components

·         EJB components

Web components are software entities that provide responses to requests. A web component typically generates the dynamic user interface for web-based clients. J2EE specifies two types of web components. They are as mentioned below:

Servlet

Servlet is a Java program that extends the functionalities of a web server. They dynamically generate and send responses to the requests received from the client.

 

JSP

JSP provides an extensible way to generate dynamic content for a web client. It is a text-based document, containing information on creating a response for a request.

EJB components are developed by application developers to provide business logic for the enterprise application. J2EE provides an EJB specification for developing and deploying EJB components. EJB components, termed enterprise beans, are scalable, transactional (i.e., they participate in a transaction) and provide multi-user support. There are two types of beans:

Session Bean

It is created to provide service on behalf of a client and usually exists only for the duration of a single client-server session.

Entity Bean

It is a persistent object that represents data maintained in the data store; its focus is data-centric.

The EJB 2.0 specification introduces a new bean called Message Driven Bean (MDB), which is used for messaging.

Service Technologies

Since most enterprise applications require access to existing EISs, J2EE supports APls that provide access to database, transaction and JNDI services. J2EE service technologies allow applications to access these services in a uniform manner.

Database Access

J2EE provides database access to applications based on the JDBC specification. An application's components can use JDBC to handle data from relational databases.

JDBC APls provide database-independent connectivity between wide ranges of relational data sources. JDBC APls can also be divided into two parts, an application level interface used by components for accessing databases and a service provider interface to attach providers to the platform.

J2EE requires JDBC 2.0 core APls and extension APls, which provide row sets, connection naming via JNDI, connection pooling, and distributed transaction support. The JDBC drivers use the connection pooling and distributed transaction to co-ordinate with the J2EE server.

Java Naming and Directory Interface (JNDI)

This API allows the J2EE components to lookup other remote objects that they may need to access. Using JNDI, an application can store and retrieve any type of named.

Java objects. The JNDI API was designed to standardize access to a variety of naming and directory interfaces and has two parts. They are as follows:

An application-level interface used by the application components to access naming and directory services.

A service provider interface used to attach a provider of a naming and directory services to the J2EE platform.

Transaction Service

Transaction services in J2EE environment is based on Java Transaction API (JTA) and Java Transaction Service (JTS).

JTA provides a way for J2EE components and clients to manage their own transactions. It allows multiple components to participate in a single transaction. JTA specifies standard Java interfaces between the transaction manager and the parties involved in a distributed transaction system, such as the application which needs transaction support.

Communication Technologies

Communication technologies provide mechanisms for communication between client and server and between collaborating objects hosted by different servers. J2EE specification requires support for the following protocols and APls under communication technologies:

·         HTTP

·         HTTP (S)

·         Remote Method Invocation (RMI)

·         Object Management Group (OMG)

·         JMS

·         JavaMail/JAF

·         Connector architecture

J2EE Containers

The J2EE specification defines a container as being responsible for providing the runtime support for the application components. The container acts as an intermediary between the J2EE application and the services provided by the J2EE server, to give a federated view of APls for the application components. The container provides the APls to application components for accessing services. It also handles security, resource pooling, and state management.

Figure shown below illustrates the container architecture.

Figure 5

 

In the J2EE container architecture, the developers provide the following information:

 

Application Components: J2EE application components include Java Servlets, JSPs, and EJB components.

Deployment Descriptor: It is an XML file containing information about application components and additional services required by the application components.

The J2EE container provides the following APls and services to support application components in the J2EE environment:

Component Contract: In order to maintain the application components in the J2EE environment, the container provides a set of APls that should be extended and implemented by the application components. The web application components, for example, should follow Java Servlet APls and JSP APls and EJB application components should follow EJB APls.

Container Service APls: The J2EE container provides a service level abstraction of APls specified in Java standard edition. These APls allow access to JBDC, JNDI. or JTS or JMS services within the container. These services are implemented by the application server.

Declarative Services: These services are handled by the J2EE container on behalf of application components such as transaction management in accordance with the requirements of application components. It is specified in the deployment descriptor.

Other Container Services: This includes life cycle management of components such as the creation, initialization and destruction of components. They also take care of connection pooling and resource pooling.

J2EE provides specification for the following containers:

·         Application client  Applet

·         Web

·         EJB

Next, we discuss each of these containers in detail.

Application client container supports application client components. It must provide access to a set of services required by J2EE, but is not required to manage transactions. The application client container is required to provide runtime support for standalone application.

Figure 6

             

 

Applet Container

The applet container includes support for the applet-programming model. Typically, a J2SE compatible execution environment acts as a container. The Java plug-in may be added to the browser to obtain such a container.

Web Container

The web container provides the runtime environment for web components (a web component is a Java Servlet or JSP) and services such as security, concurrency, life cycle management, and transaction.

EJB Container

The EJB container manages EJBs at runtime. EJBs reside in the EJB container. This container provides transaction, security and persistence services to the deployed EJBs. The EJB specification establishes the contract between the EJB components and the EJB containers.

J2EE Packaging and Deployment Descriptor Overview

J2EE enables developers to create different parts of their application as reusable components. All related components are grouped together into a module and all modules are grouped into an application. The application is installed and configured to an operational environment. This process is called packaging and deployment.

Packaging is the process of assembling components into modules and modules into an application.

Deployment is the process of installing and customizing an application in an operational environment.

To customize and configure an enterprise application in an operational environment, the server should provide a standard mechanism. J2EE provides facilities to make the packaging and deployment process simple. In J2EE application, the modules and applications are packaged into a Java Archive (JAR) file. The customization of modules and application are defined in XML-based deployment descriptors.

Types of packaging for J2EE Applications

J2EE components can be grouped into the following J2EE modules based on the type of components:

·         EJB module

·         Web module

·         Application client module

An EJB module is a collection of reusable enterprise bean components (session and entity beans). The EJB module is packaged into an EJB JAR file with jar as the extension. This JAR file contains Java classes for enterprise beans, supporting classes and an EJB deployment descriptor.

A web module is a collection of web components and web resources (e.g., servlets and JSP are web components; HTML and images are web resources). Web modules are packaged into Web Archive (WAR) file with war as the extension. This war file contains Servlets and JSP classes, HTML, images, sound files, applets (if any), and a deployment descriptor.

The WAR file format and JAR file format are not the same. Classes in a WAR file are not usually loadable by the class loader if the war file is added to the Java classpath.

 

An Application client module contains the Java client components. This module is packaged into JAR file with a jar extension. Jar contains Java class that implements the client and application client deployment descriptor.

All the modules discussed above can be grouped into a J2EE application. A J2EE application is packaged using the JAR file format into Enterprise Archive (EAR) file. This file has ear as the extension. This ear file contains one or more J2EE modules and a J2EE application deployment descriptor.

J2EE Deployment Descriptor (DD)

J2EE DD is an XML file describing the environment for modules and their components. Each module in a J2EE application has an associated DD. The J2EE application itself is associated with a DD. DDs can be created either automatically by tools or manually.

The DDs in the different J2EE modules are as given below:

EJB DDs are stored in ejb-jar. xml file

Web DDs are stored in web. xml file

J2EE application DDs are stored in application. xml file

Here I have delved into the J2EE architecture, explaining the characteristic of an Enterprise Application, Different Enterprise Application Models such as 2-tier architecture, 3-tier architecture & n-tier architecture. I have discussed in detail about J2EE Architecture Overview, benefits of J2EE, the J2EE Platform Technologies such as Component Technologies, Service Technologies & Communication Technologies. I have also discussed t J2EE Packaging and Deployment Descriptor.