J2EE Architecture Explained

Enterprise components
Today, more and more developers want to write distributed transactional applications for the enterprise and
leverage the speed, security, and reliability of server-side technology. If you are already working in this
area, you know that in today's fast-moving and demanding world of e-commerce and information
technology, enterprise applications have to be designed, built, and produced for less money, faster, and
with fewer resources than ever before.
To reduce costs and fast-track enterprise application design and development, the Java 2 Platform,
Enterprise Edition (Java EE) technology provides a component-based approach to the design, development,
assembly, and deployment of enterprise applications. The Java EE platform gives you a multitiered
distributed application model, the ability to reuse components, a unified security model, and flexible
transaction control. Not only can you deliver innovative customer solutions to market faster than ever, but
your platform-independent Java EE component-based solutions are not tied to the products and APIs of any
one vendor.
Distributed Multitiered Applications
The Java EE platform uses a multitiered distributed application model. This means application logic is
divided into components according to function, and the various application components that make up a
Java EE application are installed on different machines depending on which tier in the multitiered Java EE
environment the application component belongs. Figure 1 shows two multitiered Java EE applications
divided into the tiers described in the bullet list below. The Java EE application parts shown in Figure 1 are
presented in Java EE Application Components.
 Client tier components run on the client machine
 Web tier components run on the Java EE server
 Business tier components run on the Java EE server
 Enterprise information system (EIS) tier software runs on the EIS server
While a Java EE application can consist of the three or four tiers shown in Figure 1, Java EE multitiered
applications are generally considered to be three-tiered applications because they are distributed over three
different locations: client machines, Java EE server machine, and the database or legacy machines at the
back-end. Three-tiered applications that run in this way extend the standard two-tiered client and server
model by placing a multithreaded application server between the client application and back-end storage.
Figure 1: Multitiered Applications

Java EE Application Components
Java EE applications are made up of components. A Java EE component is a self-contained functional
software unit that is assembled into a Java EE application with its related classes and files and
communicates with other components. The Java EE specification defines the following Java EE
components:
 Application clients and applets are client components.
 Java Servlet and JavaServer Pages (JSP) technology components are web components.
 Enterprise JavaBeans (EJB) components (enterprise beans) are business components.
Java EE components are written in the Java programming language and compiled in the same way as any
Java programming language program. The difference when you work with the Java EE platform, is Java
EE components are assembled into a Java EE application, verified that they are well-formed and in
compliance with the Java EE specification, and deployed to production where they are run and managed by
the Java EE server.
Client Components
A Java EE application can be web-based or non-web-based. An application client executes on the client
machine for a non-web-based Java EE application, and a web browser downloads web pages and applets to
the client machine for a web-based Java EE application.
Application Clients
An application client runs on a client machine and provides a way for users to handle tasks such as Java EE
system or application administration. It typically has a graphical user interface created from Project Swing
or Abstract Window Toolkit (AWT) APIs, but a command-line interface is certainly possible.
Application clients directly access enterprise beans running in the business tier. However, if the Java EE
application client requirements warrant it, an application client can open an HTTP connection to establish
communication with a servlet running in the web tier.
Web Browsers
The user's web browser downloads static or dynamic Hypertext Markup Language (HTML), Wireless
Markup Language (WML), or Extensible Markup Language (XML) web pages from the web tier. Dynamic
web pages are generated by servlets or JSP pages running in the web tier.
Applets
A web page downloaded from the web tier can include an embedded applet. An applet is a small client
application written in the Java programming language that executes in the Java VM installed in the web
browser. However, client systems will likely need Java Plug-in and possibly a security policy file so the
applet can successfully execute in the web browser.
JSP pages are the preferred API for creating a web-based client program because no plug-ins or security
policy files are needed on the client systems. Also, JSP pages enable cleaner and more modular application
design because they provide a way to separate applications programming from web page design. This
means personnel involved in web page design do not need to understand Java programming language
syntax to do their jobs.

Applets that run in other network-based systems such as handheld devices or car phones can render
Wireless Markup Language (WML) pages generated by a JSP page or servlet running on the Java EE
server. The WML page is delivered over Wireless Application Protocol (WAP) and the network
configuration requires a gateway to translate WAP to HTTP and back again. The gateway translates the
WAP request coming from the handheld device to an HTTP request for the Java EE server, and then
translates the HTTP server response and WML page to a WAP server response and WML page for display
on the handheld device.
JavaBeans Component Architecture
The client tier might also include a component based on the JavaBeans component architecture (JavaBeans
component) to manage the data flow between an application client or applet and components running on
the Java EE server. JavaBeans components are not considered components by the Java EE specification.
JavaBeans components written for the Java EE platform have instance variables and get and set methods
for accessing the data in the instance variables. JavaBeans components used in this way are typically
simple in design and implementation, but should conform to the naming and design conventions outlined in
the JavaBeans component architecture.
Java EE Server Communications
Figure 2 shows the various elements that can make up the client tier. The client communicates with the
business tier running on the Java EE server either directly, or as in the case of a client running in a browser,
by going through JSP pages or servlets running in the web tier.
Figure 2: Server Communications
Thin Clients
Java EE applications use a thin client. A thin client is a lightweight interface to the application that does not
do things like query databases, execute complex business rules, or connect to legacy applications.
Heavyweight operations like these are off-loaded to web or enterprise beans executing on the Java EE
server where they can leverage the security, speed, services, and reliability of Java EE server-side
technologies.
Web Components
Java EE web components can be either JSP pages or servlets. Servlets are Java programming language
classes that dynamically process requests and construct responses. JSP pages are text-based documents that
contain static content and snippets of Java programming language code to generate dynamic content. When
a JSP page loads, a background servlet executes the code snippets and returns a response.

Static HTML pages and applets are bundled with web components during application assembly, but are not
considered web components by the Java EE specification. Server-side utility classes can also be bundled
with web components, and like HTML pages, are not considered web components.
Like the client tier and as shown in Figure 3, the web tier might include a JavaBeans object to manage the
user input and send that input to enterprise beans running in the business tier for processing.
Figure 3: Web Tier and Java EE Application
Business Components
Business code, which is logic that solves or meets the needs of a particular business domain such as
banking, retail, or finance, is handled by enterprise beans running in the business tier. Figure 4 shows how
an enterprise bean receives data from client programs, processes it (if necessary), and sends it to the
enterprise information system tier for storage. An enterprise bean also retrieves data from storage,
processes it (if necessary), and sends it back to the client program.
There are three kinds of enterprise beans: session beans, entity beans, and message-driven beans. A session
bean represents a transient conversation with a client. When the client finishes executing, the session bean
and its data are gone. In contrast, an entity bean represents persistent data stored in one row of a database
table. If the client terminates or if the server shuts down, the underlying services ensure the entity bean data
is saved.
A message-driven bean combines features of a session bean and a Java Message Service (JMS) message
listener, allowing a business component to receive JMS messages asynchronously. This introduction
describes entity beans and session beans. For information on message-driven beans, see the Java Message
Service Tutorial.

Figure 4: Business and EIS Tiers
Enterprise Information System Tier
The enterprise information system tier handles enterprise information system software, and includes
enterprise infrastructure systems such as enterprise resource planning (ERP), mainframe transaction
processing, database systems, and other legacy information systems. Java EE application components
might need access to enterprise information systems for database connectivity, for example.
Java EE Architecture
Normally, thin-client multitiered applications are hard to write because they involve many lines of intricate
code to handle transaction and state management, multithreading, resource pooling, and other complex
low-level details. The component-based and platform-independent Java EE architecture makes Java EE
applications easy to write because business logic is organized into reusable components and the Java EE
server provides underlying services in the form of a container for every component type. Because you do
not have to develop these services yourself, you are free to concentrate on solving the business problem at
hand.
Containers and Services
Component are installed in their containers during deployment and are the interface between a component
and the low-level platform-specific functionality that supports the component. Before a web, enterprise
bean, or application client component can be executed, it must be assembled into a Java EE application and
deployed into its container.
The assembly process involves specifying container settings for each component in the Java EE application
and for the Java EE application itself. Container settings customize the underlying support provided by the
Java EE Server, which include services such as security, transaction management, Java Naming and
Directory Interface (JNDI) lookups, and remote connectivity. Here are some of the highlights:
 The Java EE security model lets you configure a web component or enterprise bean so system
resources are accessed only by authorized users.
 The Java EE transaction model lets you specify relationships among methods that make up a single
transaction so all methods in one transaction are treated as a single unit.
 JNDI lookup services provide a unified interface to multiple naming and directory services in the
enterprise so application components can access naming and directory services.
 The Java EE remote connectivity model manages low-level communications between clients and
enterprise beans. After an enterprise bean is created, a client invokes methods on it as if it were in
the same virtual machine.
The fact that the Java EE architecture provides configurable services means that application components
within the same Java EE application can behave differently based on where they are deployed. For
example, an enterprise bean can have security settings that allow it a certain level of access to database data
in one production environment and another level of database access in another production environment.
The container also manages non-configurable services such as enterprise bean and servlet life cycles,
database connection resource pooling, data persistence, and access to the Java EE platform APIs described
in Java EE APIs. Although data persistence is a non-configurable service, the Java EE architecture lets you
override container-managed persistence by including the appropriate code in your enterprise bean
implementation when you want more control than the default container-managed persistence provides. For
example, you might use bean-managed persistence to implement your own finder (search) methods or to
create a customized database cache.

Container Types
The deployment process installs Java EE application components in the following types of Java EE
containers. The Java EE components and container addressed in this tutorial are shown in Figure 5.
 An Enterprise JavaBeans (EJB) container manages the execution of all enterprise beans for one
Java EE application. Enterprise beans and their container run on the Java EE server.
 A web container manages the execution of all JSP page and servlet components for one Java EE
application. Web components and their container run on the Java EE server.
 An application client container manages the execution of all application client components for one
Java EE application. Application clients and their container run on the client machine.
 An applet container is the web browser and Java Plug-in combination running on the client
machine.
Figure 5: Java EE Server and Containers
Packaging
Java EE components are packaged separately and bundled into a Java EE application for deployment. Each
component, its related files such as GIF and HTML files or server-side utility classes, and a deployment
descriptor (DD), are assembled into a module and added to the Java EE application. A Java EE application
is composed of one or more enterprise bean, web, or application client component modules. The final
enterprise solution can use one Java EE application or be made up of two or more Java EE applications
depending on design requirements
A Java EE application and each of its modules has its own deployment descriptor. A deployment descriptor
is an Extensible Markup Language (XML) text-based file with an .xml extension that describes a
component's deployment settings. An enterprise bean module deployment descriptor, for example, declares
transaction attributes and security authorizations for an enterprise bean. Because deployment descriptor
information is declarative, it can be changed without modifying the bean source code. At run time, the Java
EE server reads the deployment descriptor and acts upon the component accordingly.
A Java EE application with all of its modules is delivered in an Enterprise ARchive (EAR) file. An EAR
file is a standard JAR file with an .ear extension. In the GUI version of the Java EE SDK application
deployment tool, you create an EAR file first and add JAR and WAR files to the EAR. If you use the

command line packager tools, however, you create the Java ARchive (JARs) and Web ARchive (WAR)
files first and create the EAR. The Java EE SDK tools are described in Tools.
 Each EJB JAR file contains its deployment descriptor, related files, and the .class files for the
enterprise bean.
 Each application client JAR file contains its deployment descriptor, related files, and the .class files
for the application client.
 Each WAR file contains its deployment descriptor, related files, and the .class files for the servlet or
.jsp files for a JSP page.
Using modules and EAR files makes it possible to assemble a number of different Java EE applications
using some of the same components. No extra coding is needed; it is just a matter of assembling various
Java EE modules into Java EE EAR files.
Development Roles
Reusable modules make it possible to divide the application development and deployment process into
distinct roles so different people or companies can perform different parts of the process.
The first two roles involve purchasing and installing the Java EE product and tools. Once software is
purchased and installed, Java EE components can be developed by application component providers,
assembled by application assemblers, and deployed by application deployers. In a large organization, each
of these roles might be executed by different individuals or teams. This division of labor works because
each of the earlier roles outputs a portable file that is the input for a subsequent role. For example, in the
application component development phase, an enterprise bean software developer delivers EJB JAR files.
In the application assembly role, another developer combines these EJB JAR files into a Java EE
application and saves it in an EAR file. In the application deployment role, a system administrator at the
customer site uses the EAR file to install the Java EE application into a Java EE server.
The different roles are not always executed by different people. If you work for a small company, for
example, or if you are prototyping a sample application, you might perform the tasks in every phase.
Java EE Product Provider
The Java EE product provider is the company that designs and makes available for purchase the Java EE
platform, APIs, and other features defined in the Java EE specification. Product providers are typically
operating system, database system, application server, or web server vendors who implement the Java EE
platform according to the Java 2 Platform, Enterprise Edition Specification.
Tool Provider
The tool provider is the person or company who makes development, assembly, and packaging tools used
by component providers, assemblers, and deployers. See Tools for information on the tools available with
Java EE SDK version 1.3.
Application Component Provider
The application component provider is the company or person who creates web components, enterprise
beans, applets, or application clients for use in Java EE applications.

Enterprise Bean Creation
A software developer performs the following tasks to deliver an EJB JAR file that contains the enterprise
bean:
 Writes and compiles the source code
 Specifies the deployment descriptor
 Bundles the .class files and deployment descriptor into an EJB JAR file
Web Component Creation
A web designer (JSP pages) or software developer (servlets) performs the following tasks to deliver a
WAR file containing the web component.
 Writes and compiles servlet source code
 Writes JSP and HTML files
 Specifies the deployment descriptor for the web component
 Bundles the .class, .jsp, .html, and deployment descriptor files in the WAR file
Java EE Application Client Creation
A software developer performs the following tasks to deliver a JAR file containing the Java EE application
client.
 Writes and compiles the source code
 Specifies the deployment descriptor for the client
 Bundles the .class files and deployment descriptor into the JAR file

J2EE Architecture Explained

More Related Content

What's hot

Similar to J2EE Architecture Explained

Recently uploaded

J2EE Architecture Explained