Mikalai Chapter 1

8/7/2019 Mikalai Chapter 1

1/45

Mikalai Notes - Chapter 1

Page 1 of45

Chapter 1: Application Design Concepts and

Principles

Explain the main advantages of an object oriented approach tosystem 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.


2/45


Page 2 of45

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.


3/45


Page 3 of45

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)


4/45


Page 4 of45

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.


5/45


Page 5 of45

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


6/45


Page 6 of45

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


7/45


Page 7 of45

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 shouldnot be forced to implement interfaces they dont 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 shouldnt have been affected in the first

place.


8/45


Page 8 of45

Composite Reuse Principle (CRP)

Composition over inheritance in object-oriented programming isa 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 thebehaviors 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


9/45


Page 9 of45

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.


10/45


Page 10 of45

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.


11/45


Page 11 of45

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();

Im 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(){


12/45


Page 12 of45

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 tothe containing classes internal components. This can contribute

to a large and cumbersome public interface.

Package Dependency:

It isnt uncommon to find that many developers havent

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.


13/45


Page 13 of45

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 structuralrelationship to class Service, which implies that any changes to

the Service class may impact Client.

Lets examine this relationship from a different viewpoint. If thecontents 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 onP2.


14/45


Page 14 of45

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.


15/45


Page 15 of45

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, notonly 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 beapparent 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.

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


16/45


Page 16 of45

Functional cohesion emphasizes well-written methods

that are more easily maintained. Class cohesion

stresses the importance of creating classes that arefunctionally 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.


17/45


Page 17 of45

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


18/45


Page 18 of45

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


19/45


Page 19 of45


20/45


Page 20 of45

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


21/45


Page 21 of45

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.


22/45


Page 22 of45

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 databaseor 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 isassembled 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.


23/45


Page 23 of45

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 areoff-loaded to enterprise beans executing on the Java EE server,


24/45


Page 24 of45

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 anembedded 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 forcreating 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 theSwing 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.


25/45


Page 25 of45

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, theeasier it is to distribute, deploy, and manage the

application;

however, keeping more functionality on the client can

make for a better perceived user experience.


26/45


Page 26 of45

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


27/45


Page 27 of45

considered web components by the Java EE

specification.

Server-side utility classes can also be bundled with webcomponents 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.


28/45


Page 28 of45

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 receivesdata 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 fordatabase connectivity.


29/45


30/45


Page 30 of45

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 modulesmakes 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 tomodify 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. Anenterprise 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:


31/45


Page 31 of45

EJB modules, which contain class files for

enterprise beans and an EJB deployment

descriptor. EJB modules are packaged as JAR fileswith 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


32/45


Page 32 of45

Enterprise JavaBeans Technology


33/45


Page 33 of45

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 servletclass 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 containstwo 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


34/45


Page 34 of45

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 datastored 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


35/45


Page 35 of45

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 theapplication 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


36/45


Page 36 of45

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)


37/45


Page 37 of45

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 industrys 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)


38/45


Page 38 of45

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-endbusiness 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 thedatabase 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)


39/45


Page 39 of45

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


40/45


Page 40 of45

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


41/45


Page 41 of45

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.


42/45


Page 42 of45

Communication Technologies

Communication technologies provide mechanisms for communication between

clients and servers and between collaborating objects hosted by differentservers. 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.


43/45


Page 43 of45

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 Javalanguage 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 librarythat 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 havebeen 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.


44/45


Page 44 of45

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 accessenterprise 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


45/45


Page 45 of45

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

Documents

Mikalai Chapter 1