Mikalai Notes - Chapter 1

Page 1 of 45

Chapter 1: Application Design Concepts and

Principles
Explain the main advantages of an object oriented approach to
system design including the effect of encapsulation,
inheritance, delegation, and the use of interfaces, on
architectural characteristics.

There are three major features in object-oriented programming:

encapsulation, inheritance and polymorphism.

1. Encapsulation

Encapsulation enforces modularity.

Encapsulation refers to the creation of self-contained modules

that bind processing functions to the data.

These user-defined data types are called "classes," and one

instance of a class is an "object." For example, in a payroll
system, a class could be Manager, and Mikalai and Volha could
be two instances (two objects) of the Manager class.

Encapsulation ensures good code modularity, which keeps

routines separate and less prone to conflict with each other.

2. Inheritance

Inheritance passes "knowledge" down.

Classes are created in hierarchies, and inheritance allows the

structure and methods in one class to be passed down the
hierarchy.

That means less programming is required when adding

functions to complex systems.
 Mikalai Notes - Chapter 1
Page 2 of 45

If a step is added at the bottom of a hierarchy, then only the

processing and data associated with that unique step needs to
be added.

Everything else about that step is inherited. The ability to reuse

existing objects is considered a major advantage of object
technology.

3. Polymorphism

Polymorphism takes any shape.

Object-oriented programming allows procedures about objects

to be created whose exact type is not known until runtime.

For example, a screen cursor may change its shape from an

arrow to a line depending on the program mode. The routine to
move the cursor on screen in response to mouse movement
would be written for "cursor," and polymorphism allows that
cursor to take on whatever shape is required at runtime.

It also allows new shapes to be easily integrated.

 Mikalai Notes - Chapter 1
Page 3 of 45

Class Principles:

1. Open Closed Principle (OCP)

2. Liskov Substitution Principle (LSP)

3. Dependency Inversion Principle (DIP)

4. Interface Segregation Principle (ISP)

5. Composite Reuse Principle (CRP)

6. Principle of Least Knowledge (PLK)

Package Principles:

1. Package Dependency

2. Release Reuse Equivalency Principle (REP)

3. Common Closure Principle (CCP)

4. Acyclic Dependencies Principle (ADP)

5. Stable Dependencies Principle (SDP)

6. Stable Abstractions Principle (SAP)

 Mikalai Notes - Chapter 1
Page 4 of 45

Open Closed Principle (OCP)

Classes should be open for extension but closed for

modification.

The Open Closed Principle (OCP) is undoubtedly the most

important of all the class category principles. In fact, each of
the remaining class principles are derived from OCP.

OCP states that we should be able to add new features to our

system without having to modify our set of preexisting classes.

One of the benefits of the object-oriented paradigm is to enable

us to add new data structures to our system without having to
modify the existing system's code base.

One of the principle of OCP is to reduce the coupling between

classes to the abstract level.

Instead of creating relationships between two concrete classes,

we create relationships between a concrete class and an
abstract class, or in Java, between a concrete class and an
interface.

When we create an extension of our base class, assuming we

adhere to the public methods and their respective signatures
defined on the abstract class, we essentially have achieved
OCP.

Note: Read OCP article by Samudra Gupta: for complete

understanding.
 Mikalai Notes - Chapter 1
Page 5 of 45

Liskov Substitution Principle (LSP)

Subclasses should be substitutable for their base classes.

We mentioned that OCP is the most important of the class

category principles. We can think of the Liskov Substitution
Principle (LSP) as an extension to OCP.

In order to take advantage of LSP, we must adhere to OCP

because violations of LSP also are violations of OCP, but not
vice versa. In its simplest form, LSP is difficult to differentiate
from OCP, but a subtle difference does exist.

OCP is centered around abstract coupling. LSP, while also

heavily dependent on abstract coupling, is in addition heavily
dependent on preconditions and post conditions, which is LSP's
relation to Design by Contract, where the concept of
preconditions and post conditions was formalized.

A precondition is a contract that must be satisfied before a

method can be invoked. A post condition, on the other hand,
must be true upon method completion.

If the precondition is not met, the method shouldn't be invoked,

and if the post condition is not met, the method shouldn't
return.

The relation of preconditions and post conditions has meaning

embedded within an inheritance relationship that isn't
 Mikalai Notes - Chapter 1
Page 6 of 45

supported within Java, outside of some manual assertions or

non executable comments.

Because of this, violations of LSP can be difficult to find.

(So, we see LSP every where )

Refer Samudra Gupta article for complete understanding.

Dependency Inversion Principle (DIP)

Depend upon abstractions. Do not depend upon concretions.

The Dependency Inversion Principle (DIP) formalizes the

concept of abstract coupling and clearly states that we should
couple at the abstract level, not at the concrete level.

In our own designs, attempting to couple at the abstract level

can seem like overkill at times. Pragmatically, we should apply
this principle in any situation where we're unsure whether the
implementation of a class may change in the future.

But in reality, we encounter situations during development

where we know exactly what needs to be done. Requirements
state this very clearly, and the probability of change or
extension is quite low. In these situations, adherence to DIP
may be more work than the benefit realized.

At this point, there exists a striking similarity between DIP and

OCP. In fact, these two principles are closely related.
Fundamentally, DIP tells us how we can adhere to OCP. Or,
stated differently, if OCP is the desired end, DIP is the means
through which we achieve that end.

While this statement may seem obvious, we commonly violate

DIP in a certain situation and don't even realize it.
 Mikalai Notes - Chapter 1
Page 7 of 45

Abstract coupling is the notion that a class is not coupled to

another concrete class or class that can be instantiated.
Instead, the class is coupled to other base, or abstract, classes.

In Java, this abstract class can be either a class with the

abstract modifier or a Java interface data type.

Regardless, this concept actually is the means through which

LSP achieves its flexibility, the mechanism required for DIP, and
the heart of OCP.

Interface Segregation Principle (ISP)

Many specific interfaces are better than a single, general

interface.

The Interface Segregation Principle states that clients should

not be forced to implement interfaces they don’t use. Instead of
one fat interface many small interfaces are preferred based on
groups of methods, each one serving one sub module.

The Benefits

• This principle is important because it encourages two very

important ingredients of a good software design

• High cohesion – Keep all related methods together

• Low coupling – Keep dependence of one another to the

bare minimum

• Changes to fat interfaces tend to cause a ripple effect to

classes who shouldn’t have been affected in the first
place.
 Mikalai Notes - Chapter 1
Page 8 of 45

Composite Reuse Principle (CRP)

Composition over inheritance in object-oriented programming is

a technique by which classes may achieve polymorphic
behavior and code reuse by containing other classes which
implement the desired functionality instead of through
inheritance.

Basics:

An implementation of composition over inheritance typically

begins with the creation of various interfaces representing the
behaviors which the system must exhibit.

The use of interfaces allows this technique to support the

polymorphic behavior that is so valuable in object-oriented
programming. Classes implementing the identified interfaces
are built and added to Business Domain classes as needed.

Thus system behaviors are realized without inheritance. In fact,

business domain classes may all be base classes without any
 Mikalai Notes - Chapter 1
Page 9 of 45

inheritance at all. Alternative implementation of system

behaviors are accomplished by providing another class which
implements the desired behavior interface.

Any business domain class that containing a reference to the

interface can easily support any implementations of that
interface and the choice can even be delayed until run time.

Benefits:

Composition over inheritance can simplify the initial design of

Business Domain classes and provide a more stable business
domain in the long term.

Its advantage over inheritance is a more thorough isolation of

interests than can be described by a hierarchy of descendant
classes.

Additionally, inheritance models are often contrived during the

definition of business domain classes in order to make sense of
the information in the problem domain and do not necessarily
reflect the true relationship of various system objects.

Initial design is simplified by identifying system object

behaviors in separate interfaces instead of creating a
hierarchical relationship to distribute behaviors among business
domain classes via inheritance.

This approach more easily accommodates future requirements

changes that would otherwise require a complete restructuring
of business domain classes in the inheritance model.

Additionally, it avoids problems often associated with relatively

minor changes to an inheritance-based model that includes
several generations of classes.
 Mikalai Notes - Chapter 1
Page 10 of 45

Principle of Least Knowledge (PLK)

The Principle of Least knowledge, also known as The law of

Demeter, or more precisely, the Law of Demeter for
Functions/Methods (LoD-F) is a design principle which provides
guidelines for designing a system with minimal dependencies.

It is typically summarized as “Only talk to your

immediate friends.”
What this means is a client should only have knowledge of an
objects members, and not have access to properties and
methods of other objects via the members. To put it in simple
terms you should only have access to the members of the
object, and nothing beyond that.
 Mikalai Notes - Chapter 1
Page 11 of 45

Think if it like this: if you use more than 1 dot you are
violating the principle.
Example:

• Bad (Common):

inventory.SalesInfo.Items.Count = 2500;

• Good:

SalesInfo si = inventory.SalesInfo;

int salesItemsCount = si.GetSalesItemsCount();

I’m definitely guilty of violating this “law”.

I know via reading and experience that this idea does help
decouple your code. You are able to re-use and place your
code under test coverage more easily.

LoD brings out the basic OO principle of encapsulation, hence

the name “Principle of Least Knowledge”. With our current
IDEs out there today it is very easy to forget about not walking
a list of dots.

What I mean is, if you have more than 1 dot in your call (i.e.,
person.spouse.name (bad) instead of person.GetSpouseName()
(good)) you are most likely violating LoD.

One more example:

• Without principle :

public float applyForJob(){

 Mikalai Notes - Chapter 1
Page 12 of 45

Agency agency = company.getAgency();

return agency.searchJob();

Here we are dependent on Agency Class also

• With principle:

public float applyForJob(){

return company.searchJob();

This reduces the number of classes we are dependent on.

Primary benefit is that the calling method doesn't need to

understand structural makeup of the object it's invoking
methods upon.

The obvious disadvantage of using this principle is that we

must create many methods that only forward method calls to
the containing classes internal components. This can contribute
to a large and cumbersome public interface.

Package Dependency:

It isn’t uncommon to find that many developers haven’t

realized that relationships do exist among the packages within
a Java application. The dependencies between packages often
go unnoticed.

Logically, however, if a class contains relationships to other

classes, then packages containing those classes also must
contain relationships to other packages. These package
relationships can tell us a great deal about the resiliency of our
system.

In Figure, we see a class diagram depicting two packages, A

and B. Within each of these packages exist two classes.
 Mikalai Notes - Chapter 1
Page 13 of 45

Class Client exists in package A and class Service in B.

Simply stated, if class Client references in any way class

Service, then it must hold true that Client has a structural
relationship to class Service, which implies that any changes to
the Service class may impact Client.

Let’s examine this relationship from a different viewpoint. If the

contents of package A are dependent on the contents of
package B, then A has a dependency on B; and if the contents
of B change, this impact may be noticeable in A.

Therefore, the relationships between packages become more

apparent, and we can conclude the following:

If changing the contents of a package P1 may impact the contents of

another package P2, we can say that P1 has a package dependency on
P2.
 Mikalai Notes - Chapter 1
Page 14 of 45

Release Reuse Equivalency Principle (REP):

The granule of reuse is the granule of release

Whenever a client class wishes to use the services of another

class, we must reference the class offering the desired services.

If the class offering the service is in the same package as the

client, we can reference that class using the simple name. If,
however, the service class is in a different package, then any
references to that class must be done using the class’ fully
qualified name, which includes the name of the package.
 Mikalai Notes - Chapter 1
Page 15 of 45

We also know that any Java class may reside in only a single
package.

Therefore, if a client wishes to utilize the services of a class, not

only must we reference the class, but we must also explicitly
make reference to the containing package.

Failure to do so results in compile-time errors.

Therefore, to deploy any class, we must be sure the containing

package is deployed.

Because the package is deployed, we can utilize the services

offered by any public class within the package. Therefore, while
we may presently need the services of only a single class in the
containing package, the services of all classes are available to
us.

Consequently, our unit of release is our unit of reuse, resulting

in the Release Reuse Equivalency Principle (REP).

This leads us to the basis for this principle, and it should now be
apparent that the packages into which classes are placed have
a tremendous impact on reuse.

Careful consideration must be given to the allocation of

classes to packages.

Common Closure Principle (CCP)

Classes that change together, belong together.

The basis for the Common Closure Principle (CCP) is
rather simple.
Adhering to fundamental programming best practices
should take place throughout the entire system.
 Mikalai Notes - Chapter 1
Page 16 of 45

Functional cohesion emphasizes well-written methods

that are more easily maintained. Class cohesion
stresses the importance of creating classes that are
functionally sound and don't cross responsibility
boundaries. And package cohesion focuses on the
classes within each package, emphasizing the overall
services offered by entire packages.
During development, when a change to one class may
dictate changes to another class, it's preferred that
these two classes be placed in the same package.
Conceptually, CCP may be easy to understand;
However, applying it can be difficult because the only
way that we can group classes together in this manner
is when we can predictably determine the changes that
might occur and the effect that those changes might
have on any dependent classes.
Predictions often are incorrect or aren't ever realized.
Regardless, placement of classes into respective
packages should be a conscious decision that is driven
not only by the relationships between classes, but also
by the cohesive nature of a set of classes working
together.

Common Reuse Principle (CReP)

Classes that aren't reused together should not be
grouped together.
 Mikalai Notes - Chapter 1
Page 17 of 45

If we need the services offered by a class, we must

import the package containing the necessary classes.
As we stated previously in our discussion of REP
(Release Reuse Equivalency Principle), when we import
a package, we also may utilize the services offered by
any public class within the package. In addition,
changing the behavior of any class within the service
package has the potential to break the client. Even if
the client doesn't directly reference the modified class
in the service package, other classes in the service
package being used by clients may reference the
modified class. This creates indirect dependencies
between the client and the modified class that can be
the cause of mysterious behavior. Цe can state the
following:
If a class is dependent on another class in a different
package, then it is dependent on all classes in that
package, albeit indirectly.
This principle has a negative connotation. It doesn't
hold true that classes that are reused together should
reside together, depending on CCP. Even though
classes may always be reused together, they may not
always change together. In striving to adhere to CCP,
separating a set of classes based on their likelihood to
change together should be given careful consideration.
Of course, this impacts REP because now multiple
packages must be deployed to use this functionality.
Experience tells us that adhering to one of these
principles may impact the ability to adhere to another.
 Mikalai Notes - Chapter 1
Page 18 of 45

Whereas REP and Common Reuse Principle (CReP)

emphasize reuse, CCP emphasizes maintenance.
Acyclic Dependencies Principle (ADP)

The dependencies between packages must form no cycles

The problem with this code is that, because the classes in these
packages are coupled, the two packages become tightly
coupled, which has a tremendous impact on REP
 Mikalai Notes - Chapter 1
Page 19 of 45
 Mikalai Notes - Chapter 1
Page 20 of 45

Stable Dependencies Principle (SDP)

Depend in the direction of stability.

Packages likely to experience frequent change should be less

stable, implying fewer incoming dependencies and more
outgoing dependencies.

Packages likely to experience infrequent change may be more

stable, implying more incoming dependencies and fewer
outgoing dependencies.

Stable Abstractions Principle (SAP)

Stable packages should be abstract packages.

One of the greatest benefits of object orientation is the ability

to easily maintain our systems.

The high degree of resiliency and maintainability is achieved

through abstract coupling. By coupling concrete classes to
abstract classes, we can extend these abstract classes and
provide new system functions without having to modify existing
system structure.

Consequently, the means through which we can depend in the

direction of stability, and help ensure that these more
depended-upon packages exhibit a higher degree of stability, is
to place abstract classes, or interfaces, in the more stable
packages. We can state the following:

• More stable packages, containing a higher number of

abstract classes, or interfaces, should be heavily
depended upon.

• Less stable packages, containing a higher number of

concrete classes, should not be heavily depended upon.
 Mikalai Notes - Chapter 1
Page 21 of 45

Any packages containing all abstract classes with no incoming

dependencies are utterly useless. On the other hand, packages
containing all concrete classes with many incoming
dependencies are extremely difficult to maintain.

Describe how the principle of "separation of concerns" has been applied to

the main system tiers of a Java EE application.

Tiers include client (both GUI and web), web (web container), business
(EJB container), integration, and resource tiers.

The Java EE platform uses a distributed multitiered application

model for enterprise applications.

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 the tier in the multitiered Java EE environment to
which the application component belongs.

Figure below shows two multitiered Java EE applications divided

into the tiers described in the following list:

• 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.
 Mikalai Notes - Chapter 1
Page 22 of 45

Although a Java EE application can consist of the three or four

tiers, Java EE multitiered applications are generally considered
to be three-tiered applications because they are distributed
over three locations:

client machines, the 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.

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 that communicates with other components. The
Java EE specification defines the following Java EE components:

• Application clients and applets are components that run

on the client.
 Mikalai Notes - Chapter 1
Page 23 of 45

• Java Servlet, JavaServer Faces, and JavaServer Pages (JSP)

technology components are web components that run on
the server.

• Enterprise JavaBeans (EJB) components (enterprise beans)

are business components that run on the server.

Java EE Clients

1. Web Clients

A Web Client consists of two parts:

• Dynamic web pages containing various types of markup

language (HTML, XML, and so on), which are generated by
web components running in the web tier.

• Web browser, which renders the pages received from the

server.

A Web Client is sometimes called a thin client. Thin clients

usually do not query databases, execute complex business
rules, or connect to legacy applications.

When you use a thin client, such heavyweight operations are

off-loaded to enterprise beans executing on the Java EE server,
 Mikalai Notes - Chapter 1
Page 24 of 45

where they can leverage the security, speed, services, and

reliability of Java EE server-side technologies.

A web page received 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
virtual machine installed in the web browser.

However, client systems will likely need the Java Plug-in and
possibly a security policy file for the applet to successfully
execute in the web browser.

Web components (Servlets, JSF or JSP) are the preferred API for
creating a web client program because no plug-ins or security
policy files are needed on the client systems.

Also, web components enable cleaner and more modular

application design because they provide a way to separate
applications programming from web page design. Personnel
involved in web page design thus do not need to understand
Java programming language syntax to do their jobs.

2. Application Clients

An application client runs on a client machine and provides a

way for users to handle tasks that require a richer user
interface than can be provided by a markup language.

It typically has a graphical user interface (GUI) created from the

Swing or the Abstract Window Toolkit (AWT) API, but a
command-line interface is certainly possible.

Application clients directly access enterprise beans

running in the business tier. However, if application
requirements warrant it, an application client can open
an HTTP connection to establish communication with a
servlet running in the web tier.
 Mikalai Notes - Chapter 1
Page 25 of 45

Application clients written in languages other than Java can

interact with Java EE 5 servers, enabling the Java EE 5 platform
to interoperate with legacy systems, clients, and non-Java
languages.

Figure below 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.

Your Java EE application uses a thin browser-based client or

thick application client. In deciding which one to use, you
should be aware of the trade-offs between keeping functionality
on the client and close to the user (thick client) and off-
loading(delegate) as much functionality as possible to the
server (thin client).

The more functionality you delegate to the server, the

easier it is to distribute, deploy, and manage the
application;
however, keeping more functionality on the client can
make for a better perceived user experience.
 Mikalai Notes - Chapter 1
Page 26 of 45

Web Components
Java EE web components are either servlets or pages
created using JSP technology (JSP pages) and/or
JavaServer Faces technology.
Servlets are Java programming language classes that
dynamically process requests and construct responses.
JSP pages are text-based documents that execute as
servlets but allow a more natural approach to creating
static content.
JavaServer Faces technology builds on servlets and JSP
technology and provides a user interface component
framework for web applications.
Static HTML pages and applets are bundled with web
components during application assembly but are not
 Mikalai Notes - Chapter 1
Page 27 of 45

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.
As shown in figure below, the web tier, like the client
tier, might include a JavaBeans component to manage
the user input and send that input to enterprise beans
running in the business tier for processing.
 Mikalai Notes - Chapter 1
Page 28 of 45

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 below 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.
The enterprise information system (EIS) tier handles EIS
software and includes enterprise infrastructure systems
such as enterprise resource planning (ERP), mainframe
transaction processing, database systems, and other
legacy information systems.
For example, Java EE application components might
need access to enterprise information systems for
database connectivity.
 Mikalai Notes - Chapter 1
Page 29 of 45

Java EE Application
A Java EE application is packaged into one or more
standard units for deployment to any Java EE platform-
compliant system. Each unit contains:

• A functional component or components (enterprise

bean, JSP page, servlet, applet, etc.)

• An optional deployment descriptor that describes

its content
Once a Java EE unit has been produced, it is ready to
be deployed. Deployment typically involves using a
platform's deployment tool to specify location-specific
information, such as a list of local users that can access
it and the name of the local database. Once deployed
on a local platform, the application is ready to run.
 Mikalai Notes - Chapter 1
Page 30 of 45

A Java EE application is delivered in an Enterprise

Archive (EAR) file, a standard Java Archive (JAR) file
with an .ear extension. Using EAR files and modules
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 only a matter of
assembling (or packaging) various Java EE modules into
Java EE EAR files.
An EAR file contains Java EE modules and deployment
descriptors. A deployment descriptor is an XML
document with an .xml extension that describes the
deployment settings of an application, a module, or a
component.
Because deployment descriptor information is
declarative, it can be changed without the need to
modify the source code. At runtime, the Java EE server
reads the deployment descriptor and acts upon the
application, module, or component accordingly.
A Java EE module consists of one or more Java EE
components for the same container type and one
component deployment descriptor of that type. An
enterprise bean module deployment descriptor, for
example, declares transaction attributes and security
authorizations for an enterprise bean.
A Java EE module without an application deployment
descriptor can be deployed as a stand-alone module.
The four types of Java EE modules are as follows:
 Mikalai Notes - Chapter 1
Page 31 of 45

• EJB modules, which contain class files for

enterprise beans and an EJB deployment
descriptor. EJB modules are packaged as JAR files
with a .jar extension.

• Web modules, which contain servlet class files, JSP

files, supporting class files, GIF and HTML files, and
a web application deployment descriptor. Web
modules are packaged as JAR files with a .war
(Web ARchive) extension.

• Application client modules, which contain class

files and an application client deployment
descriptor. Application client modules are
packaged as JAR files with a .jar extension.

• Resource adapter modules, which contain all Java

interfaces, classes, native libraries, and other
documentation, along with the resource adapter
deployment descriptor. Together, these implement
the Connector architecture (J2EE Connector
Architecture) for a particular EIS. Resource adapter
modules are packaged as JAR files with an .rar
(resource adapter archive) extension.

Java EE 5 APIs
 Mikalai Notes - Chapter 1
Page 32 of 45

• Enterprise JavaBeans Technology

 Mikalai Notes - Chapter 1
Page 33 of 45

An Enterprise JavaBeans (EJB) component, or enterprise bean, is a body of

code having fields and methods to implement modules of business logic. You
can think of an enterprise bean as a building block that can be used alone or
with other enterprise beans to execute business logic on the Java EE server.

There are two kinds of enterprise beans: session 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. A message-
driven bean combines features of a session bean and a message listener,
allowing a business component to receive messages asynchronously.
Commonly, these are Java Message Service (JMS) messages.

In Java EE 5, entity beans have been replaced by Java persistence API entities.
An entity represents persistent data stored in one row of a database table. If the
client terminates, or if the server shuts down, the persistence manager ensures
that the entity data is saved.

• Java Servlet Technology

Java servlet technology lets you define HTTP-specific servlet classes. A servlet
class extends the capabilities of servers that host applications that are accessed
by way of a request-response programming model. Although servlets can
respond to any type of request, they are commonly used to extend the
applications hosted by web servers.

• JavaServer Pages Technology

JavaServer Pages (JSP) technology lets you put snippets of servlet code directly
into a text-based document. A JSP page is a text-based document that contains
two types of text: static data (which can be expressed in any text-based format
such as HTML, WML, and XML) and JSP elements, which determine how the
page constructs dynamic content.

• JavaServer Pages Standard Tag Library

 Mikalai Notes - Chapter 1
Page 34 of 45

The JavaServer Pages Standard Tag Library (JSTL) encapsulates core

functionality common to many JSP applications. Instead of mixing tags from
numerous vendors in your JSP applications, you employ a single, standard set of
tags. This standardization allows you to deploy your applications on any JSP
container that supports JSTL and makes it more likely that the implementation
of the tags is optimized.

JSTL has iterator and conditional tags for handling flow control, tags for
manipulating XML documents, internationalization tags, tags for accessing
databases using SQL, and commonly used functions.

• JavaServer Faces

JavaServer Faces technology is a user interface framework for building web

applications. The main components of JavaServer Faces technology are as
follows:

1. A GUI component framework.

2. A flexible model for rendering components in different kinds of HTML

or different markup languages and technologies. A Renderer object
generates the markup to render the component and converts the data
stored in a model object to types that can be represented in a view.

3. A standard RenderKit for generating HTML/4.01 markup.

The following features support the GUI components:

 Input validation

 Event handling

 Data conversion between model objects and components

 Managed model object creation

 Page navigation configuration

All this functionality is available using standard Java APIs and XML-based
configuration files.

• Java Message Service API

 Mikalai Notes - Chapter 1
Page 35 of 45

The Java Message Service (JMS) API is a messaging standard that allows Java
EE application components to create, send, receive, and read messages. It
enables distributed communication that is loosely coupled, reliable, and
asynchronous.

• Java Transaction API

The Java Transaction API (JTA) provides a standard interface for demarcating
transactions. The Java EE architecture provides a default auto commit to handle
transaction commits and rollbacks. An auto commit means that any other
applications that are viewing data will see the updated data after each database
read or write operation.

However, if your application performs two separate database access operations

that depend on each other, you will want to use the JTA API to demarcate
where the entire transaction, including both operations, begins, rolls back, and
commits.

• JavaMail API

Java EE applications use the JavaMail API to send email notifications. The
JavaMail API has two parts: an application-level interface used by the
application components to send mail, and a service provider interface. The Java
EE platform includes JavaMail with a service provider that allows application
components to send Internet mail.

• JavaBeans Activation Framework

The JavaBeans Activation Framework (JAF) is included because JavaMail uses

it. JAF provides standard services to determine the type of an arbitrary piece of
data, encapsulate access to it, discover the operations available on it, and create
the appropriate JavaBeans component to perform those operations.

• Java API for XML Processing

 Mikalai Notes - Chapter 1
Page 36 of 45

The Java API for XML Processing (JAXP), part of the Java SE platform,
supports the processing of XML documents using Document Object Model
(DOM), Simple API for XML (SAX), and Extensible Stylesheet Language
Transformations (XSLT). JAXP enables applications to parse and transform
XML documents independent of a particular XML processing implementation.

JAXP also provides namespace support, which lets you work with schemas that
might otherwise have naming conflicts. Designed to be flexible, JAXP lets you
use any XML-compliant parser or XSL processor from within your application
and supports the W3C schema.

• Java API for XML Web Services (JAX-WS)

The JAX-WS specification provides support for web services that use the JAXB
API for binding XML data to Java objects. The JAX-WS specification defines
client APIs for accessing web services as well as techniques for implementing
web service endpoints.

The Web Services for J2EE specification describes the deployment of JAX-WS-
based services and clients. The EJB and servlet specifications also describe
aspects of such deployment. It must be possible to deploy JAX-WS-based
applications using any of these deployment models.

The JAX-WS specification describes the support for message handlers that can
process message requests and responses. In general, these message handlers
execute in the same container and with the same privileges and execution
context as the JAX-WS client or endpoint component with which they are
associated.

These message handlers have access to the same JNDI java:comp/env

namespace as their associated component. Custom serializers and deserializers,
if supported, are treated in the same way as message handlers.

• Java Architecture for XML Binding (JAXB)

 Mikalai Notes - Chapter 1
Page 37 of 45

The Java Architecture for XML Binding (JAXB) provides a convenient way to
bind an XML schema to a representation in Java language programs. JAXB can
be used independently or in combination with JAX-WS, where it provides a
standard data binding for web service messages. All Java EE application client
containers, web containers, and EJB containers support the JAXB API.

• SOAP with Attachments API for Java

The SOAP with Attachments API for Java (SAAJ) is a low-level API on which
JAX-WS and JAXR depend. SAAJ enables the production and consumption of
messages that conform to the SOAP 1.1 specification and SOAP with
Attachments note. Most developers do not use the SAAJ API, instead using the
higherlevel JAX-WS API.

• Java API for XML Registries

The Java API for XML Registries (JAXR) lets you access business and general-
purpose registries over the web. JAXR supports the ebXML Registry and
Repository standards and the emerging UDDI specifications. By using JAXR,
developers can learn a single API and gain access to both of these important
registry technologies.

Additionally, businesses can submit material to be shared and search for

material that others have submitted. Standards groups have developed schemas
for particular kinds of XML documents; two businesses might, for example,
agree to use the schema for their industry’s standard purchase order form.
Because the schema is stored in a standard business registry, both parties can
use JAXR to access it.

• J2EE Connector Architecture (JCA)

 Mikalai Notes - Chapter 1
Page 38 of 45

The J2EE Connector architecture is used by tools vendors and system

integrators to create resource adapters that support access to enterprise
information systems that can be plugged in to any Java EE product.

A resource adapter is a software component that allows Java EE application

components to access and interact with the underlying resource manager of the
EIS.

Because a resource adapter is specific to its resource manager, typically there is

a different resource adapter for each type of database or enterprise information
system.

The J2EE Connector architecture also provides a performance-oriented, secure,

scalable, and message-based transactional integration of Java EE-based web
services with existing EISs that can be either synchronous or asynchronous.

Existing applications and EISs integrated through the J2EE Connector

architecture into the Java EE platform can be exposed as XML-based web
services by using JAX-WS and Java EE component models.

Thus JAX-WS and the J2EE Connector architecture are complementary

technologies for enterprise application integration (EAI) and end-to-end
business integration.

• Java Database Connectivity (JDBC) API

The Java Database Connectivity (JDBC) API lets you invoke SQL commands
from Java programming language methods. You use the JDBC API in an
enterprise bean when you have a session bean access the database.

You can also use the JDBC API from a servlet or a JSP page to access the
database directly without going through an enterprise bean.

The JDBC API has two parts: an application-level interface used by the
application components to access a database, and a service provider interface to
attach a JDBC driver to the Java EE platform.

• Java Persistence API (JPA)

 Mikalai Notes - Chapter 1
Page 39 of 45

The Java Persistence API is a Java standards-based solution for persistence.

Persistence uses an object-relational mapping approach to bridge the gap
between an object oriented model and a relational database. Java Persistence
consists of three areas:

 The Java Persistence API

 The query language

 Object/relational mapping metadata

• Java Naming and Directory Interface (JNDI)

The Java Naming and Directory Interface (JNDI) provides naming and directory
functionality, enabling applications to access multiple naming and directory
services, including existing naming and directory services such as LDAP, NDS,
DNS, and NIS. It provides applications with methods for performing standard
directory operations, such as associating attributes with objects and searching
for objects using their attributes.

Using JNDI, a Java EE application can store and retrieve any type of named
Java object, allowing Java EE applications to coexist with many legacy
applications and systems.

Java EE naming services provide application clients, enterprise beans, and web
components with access to a JNDI naming environment. A naming environment
allows a component to be customized without the need to access or change the
component's source code.

A container implements the component's environment and provides it to the

component as a JNDI naming context.
 Mikalai Notes - Chapter 1
Page 40 of 45

• Java Authentication and Authorization Service

The Java Authentication and Authorization Service (JAAS) provides a way for
a Java EE application to authenticate and authorize a specific user or group of
users to run it.

JAAS is a Java programming language version of the standard Pluggable

Authentication Module (PAM) framework, which extends the Java Platform
security architecture to support user-based authorization.

Container Services

Containers 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 module 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, including 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 that 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 that 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 that application components can
access these services.
 Mikalai Notes - Chapter 1
Page 41 of 45

 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.

Because the Java EE architecture provides configurable services, 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 nonconfigurable services such as enterprise bean

and servlet life cycles, database connection resource pooling, data persistence,
and access to the Java EE platform APIs.
 Mikalai Notes - Chapter 1
Page 42 of 45

Communication Technologies

Communication technologies provide mechanisms for communication between

clients and servers and between collaborating objects hosted by different
servers. The J2EE specification requires support for the following types of
communication technologies:

 Internet protocols

Internet protocols define the standards by which the different pieces of the
J2EE platform communicate with each other and with remote entities. The
J2EE platform supports the following Internet protocols:

• TCP/IP - Transport Control Protocol over Internet Protocol. These two

protocols provide for the reliable delivery of streams of data from one
host to another. Internet Protocol (IP), the basic protocol of the Internet,
enables the unreliable delivery of individual packets from one host to
another. IP makes no guarantees as to whether the packet will be
delivered, how long it will take, or if multiple packets will arrive in the
order they were sent. The Transport Control Protocol (TCP) adds the
notions of connection and reliability.

• HTTP 1.0 - Hypertext Transfer Protocol. The Internet protocol used to

fetch hypertext objects from remote hosts. HTTP messages consist of
requests from client to server and responses from server to client.

• SSL 3.0 - Secure Socket Layer. A security protocol that provides privacy
over the Internet. The protocol allows client-server applications to
communicate in a way that cannot be eavesdropped or tampered with.
Servers are always authenticated and clients are optionally authenticated.
 Mikalai Notes - Chapter 1
Page 43 of 45

 Remote Method Invocation Protocols

Remote Method Invocation (RMI) is a set of APIs that allow developers to

build distributed applications in the Java programming language. RMI uses Java
language interfaces to define remote objects and a combination of Java
serialization technology and the Java Remote Method Protocol (JRMP) to turn
local method invocations into remote method invocations.

The J2EE platform supports the JRMP protocol, the transport mechanism for
communication between objects in the Java language in different address
spaces.

 Object Management Group Protocols

Object Management Group (OMG) protocols allow objects hosted by the J2EE
platform to access remote objects developed using the OMG's Common Object
Request Broker Architecture (CORBA) technologies and vice versa. CORBA
objects are defined using the Interface Definition Language (IDL).

An application component provider defines the interface of a remote object in

IDL and then uses an IDL compiler to generate client and server stubs that
connect object implementations to an Object Request Broker (ORB), a library
that enables CORBA objects to locate and communicate with one another.

ORBs communicate with each other using the Internet Inter-ORB Protocol
(IIOP). The OMG technologies required by the J2EE platform are Java IDL and
RMI-IIOP.

1. Java IDL

Java IDL allows Java clients to invoke operations on CORBA objects that have
been defined using IDL and implemented in any language with a CORBA
mapping. Java IDL is part of the J2SE platform. It consists of a CORBA API
and ORB. An application component provider uses the idlj IDL compiler to
generate a Java client stub for a CORBA object defined in IDL. The Java client
is linked with the stub and uses the CORBA API to access the CORBA object.
 Mikalai Notes - Chapter 1
Page 44 of 45

2. RMI-IIOP

RMI-IIOP is an implementation of the RMI API over IIOP. RMI-IIOP allows

application component providers to write remote interfaces in the Java
programming language. The remote interface can be converted to IDL and
implemented in any other language that is supported by an OMG mapping and
an ORB for that language. Clients and servers can be written in any language
using IDL derived from the RMI interfaces. When remote interfaces are defined
as Java RMI interfaces, RMI over IIOP provides interoperability with CORBA
objects implemented in any language.

 Messaging Technologies

Messaging technologies provide a way to asynchronously send and receive

messages. The Java Message Service API provides an interface for handling
asynchronous requests, reports, or events that are consumed by enterprise
applications.

JMS messages are used to coordinate these applications. The JavaMail API
provides an interface for sending and receiving messages intended for users.
Although either API can be used for asynchronous notification, JMS is
preferred when speed and reliability are a primary requirement.

1. Java Message Service API

The Java Message Service (JMS) API allows J2EE applications to access
enterprise messaging systems such as IBM MQ Series and TIBCO Rendezvous.
JMS messages contain well-defined information that describe specific business
actions. Through the exchange of these messages, applications track the
progress of enterprise activities. The JMS API supports both point-to-point and
publish-subscribe styles of messaging.

2. JavaMail API
 Mikalai Notes - Chapter 1
Page 45 of 45

The JavaMail API provides a set of abstract classes and interfaces that comprise
an electronic mail system. The abstract classes and interfaces support many
different implementations of message stores, formats, and transports. Many
simple applications will only need to interact with the messaging system
through these base classes and interfaces.

 Data Formats

Data formats define the types of data that can be exchanged between
components. The J2EE platform requires support for the following data formats:

1. HTML - The markup language used to define hypertext documents

accessible over the Internet. HTML enables the embedding of images,
sounds, video streams, form fields, references to other HTML documents,
and basic text formatting. HTML documents have a globally unique
location and can link to one another.

2. Image files - The J2EE platform supports two formats for image files:
GIF (Graphics Interchange Format), a protocol for the online
transmission and interchange of raster graphic data, and JPEG (Joint
Photographic Experts Group), a standard for compressing gray-scale or
color still images.

3. JAR file - A platform-independent file format that permits many files to

be aggregated into one file.

4. Class file - The format of a compiled Java file as specified in the Java
Virtual Machine specification. Each class file contains one Java language
type - either a class or an interface - and consists of a stream of 8-bit
bytes.

5. XML - A text-based markup language that allows you to define the

markup needed to identify the data and text in structured documents. As
with HTML, you identify data using tags. But unlike HTML, XML tags
describe the data, rather than the format for displaying it. In the same way
that you define the field names for a data structure, you are free to use
any XML tags that make sense for a given application. When multiple
applications share XML data, they have to agree on the tag names they
intend to use.