Java Enterprise Edition (Java EE)

emptyslowInternet and Web Development

Nov 12, 2013 (7 years and 10 months ago)



Java Enterprise Edition (Java EE)

FMIS 3202 Enterprise System Architectures

Nik R. Hassan

Spring 2007


Java Beans

A Java Bean is a special kind of class.

There are three major types of Java Beans

Entity Beans

They can be used to map an entry in a database table to a class. They become the
“Data Layer” of the 3
tier client/server system replacing result sets from a database
query. The application server provides the functionality to load, update or delete the
values of a class instance to the database.

Session Beans

Session beans are used to implement the functionality of your application. There are
two kind of session beans: Stateful and Stateless.

A stateful session bean is for example a shopping cart class. The state is the cart
holding the shopping items and the quantity. The cart class is hold in your application
session and disposed at the end when the user checked out.

A stateless bean is a short living class. A typical example is a MailSender class
sending a message. You call a method and dispose it. With a application server you
do not instantiate the class each time you need it. The application server passes an
instance from a pool. This is more efficient.

Message Driven Beans

Message beans provide functionality to implement messaging in your business logic.
When you want to send a message to one or more recipients to start another
business logic, you can use message beans. A Shop application could send a order
message to the Warehouse management. Once the warehouse management
software is started, it receives the orders from the shop application.


Why Enterprise Java Beans (EJB)?

Enterprise Java Beans (EJB) is a heavyweight industry
strength framework.

If the application is not as heavy, you should choose simple applications,
Hibernate, or just straight databases/SQL.

Advantages of EJB:

Many vendor application servers conform to the J2EE specification allowing one
to select a best
breed solution.

To handle fluctuations in resource demand server
side resources can easily be
scaled by adding or removing servers.

Application servers provide access to complex services, namely transaction and
security management, resource pooling, JNDI (Java Naming and Directory
Interface), component lifecycle management, etc.

Disadvanatges of EJB:

EJB has a large and complicated specification.

EJBs take longer to develop. Also, when things go wrong they can be more
difficult to debug. Occasionally the bug may not be in your code but in the
application server itself.

New specifications may force modifications

When NOT to use EJB?

Do not choose EJB when there is no need for scalability, transaction
management, or security.

Do not choose EJB if you anticipate low numbers of read
only users.

Do not choose EJB if your team lacks EJB experience or cannot quickly obtain
that experience. The EJB learning curve is steep and overcoming it can easily
derail an otherwise viable project.


Java Components and Application Servers

EJBs are a kind of component
packaged software object with standardized
interface that is reusable in multiple applications

E.g. a customer component can be used in EBay as well as in Amazon with only
minor modifications

A set of specifications that details how components interact with each other and
with other software tools

The application server:

Is a process which manages one or more EJB containers

Provides access to system services for EJB containers

Provides J2EE services for naming, transactions and security

The EJB container:

Manages EJB classes and instances and access to beans

Enforces transactional requirements

Manages bean life cycle

May manage persistence for entity beans


Encapsulation Simplifies Complexity

The whole idea is to simplify the complex enterprise system by hiding
(encapsulating) that complexity

The client shouldn’t have to worry about which components it needs to connect
to when changes are necessary (loosely coupled)

The components on the server side shouldn’t have to worry about other
components regardless where they reside (location transparency)

Each component need only to focus on their business logic (cohesiveness)

When the client calls the server, the call is intercepted by a request interceptor that
is created by the EJB container. This interceptor takes care of the low
level API
functions and passes the call to the correct distributed object (enterprise bean)

The EJB container creates multiple instances of the bean as is needed and
spawning threads in which these instance are executed.

This wrapping process appears to the client as the EJB object which knows about
networking, transactions, security, and more.

The EJB container creates stubs and skeletons it requires to service the call.

EJB Object
Remote Interface
Remote Interface
Remote Interface
Request Interceptor
Distributed Object

Remote Method Invocation (RMI)

When you call a method (e.g. myAccount.transfer(tran) in your homework), the
reference variable is usually

which means it is running on the same machine
(same java heap/JVM). In an enterprise system, you cannot assume so (e.g.
clients could be browsers or beans on another machine).

Enterprise systems must allow for remote clients that can pass message across
machines. That means the reference variable is not only out of scope (remember
the familiar “cannot find symbol” error?), but on another machine.

Java’s RMI solves this problem by giving the client a proxy (called a
) helper
object that acts as the go
between and takes care of the low
level communication
(sockets and streams) with the remote object.

On the server side there is also a helper object that accepts the socket connection
from the stub called the
. This skeleton unpacks the message and invokes

on the real object, appearing like a local client. Both helper objects
accepts calls and transfer the message to the real distributed object.

That is why EJBs need to implement the Serializable interface so that the stub can
flatten them (make them like primitives) and then ship them off to the skeleton.

All classes that can be called remotely must extend the java.rmi.Remote marker
interface (which is why stubs and skeletons are necessary as interface proxies for
the real classes since concrete classes cannot “extend” interfaces, so they
“implement” their helper interfaces).

What happens if the server is down? Or if the connection drops? How is the client
to know what is happening (especially in the typical asynchronous fashion which
does not immediately provide feedback?)


Handling Exceptions

During risky remote calls Java’s built
in exception handling takes over. Exception handling is useful
(and required by the compiler) in instances that things can go wrong (e.g. calling a remote object
that you didn’t write).

You need to know that the method you are calling is risky so that you can write code that can handle
the failure if it does happen.

Two structures support this situation (e.g. look up the public Socket() constructor of the documentation. Every time you create a new socket to connect, you need to
declare that it is risky):

If you

a method that involves risky behavior you must declare it using the

(e.g. the Socket constructor), or

If you

a method that throws an exception, you must acknowledge that it is risky by wrapping
the call in a
block or ducks what is thrown by ignoring the exception and passing it to
the methods higher up the calling stack

What is being thrown is an exception object that can be handled by the catch block.

private void setUpNetwork() { //doesn’t have a throws keyword
so must have try

try { //start of try

socket = new Socket(“”, 8080); //creates a new socket on the localhost on port 8080

writer = new PrintWriter(socket.getOutputStream());//
if successful, a new PrintWriter object is created

System.out.println(“networking established!”);

} catch(IOException ex) { //if not successful

maybe server is down

System.out.println(“Failed to connect”); //prints out a message

ex.printStackTrace(); //prints out a stack trace


} //end of try
catch block, execution continues after this


EJBHome and EJBObject

To wrap it all up, how does a client know which methods to call? Or more
importantly which objects to reference? What happens next?

It makes sense that the object must be identified first before the methods of that
object can be called.

Two interfaces must be coded to extend the following interfaces (NB Your
interfaces extends standard Java interfaces
see documentation for javax.ejb).
Your interfaces will then be implemented by the EJB container to construct
EJBObjects and EJBHome objects

The Home interface (EJBHome)

This interface defines the methods that allow a remote client to create, find, and remove
distributed bean objects

In this program you define a create() method.

The Remote Interface (EJBObject)

This interface provides the client view of the EJB object (it contains the same exact methods
as the distributed bean object)

The Remote interface extends java.rmi.Remote and every method declares a
RemoteException (from the java.rmi package)

Arguments and return types must be shippable (Serializable, primitive, array of
Serializable or primitives or Remote objects)

The EJBObject class becomes the bodyguard to all the distributed bean objects.
All services that are required are started up by the EJBObject before a local call
is made to the bean. The EJBObject does the following

Checks to see if the client is authorized (Java security services)

Checks to see if the call is part of the right transaction (Java transaction services)

Checks to see if the bean needs to load info from the database before running the method


What Happens after Deployment

Using the EJBHome interface you created, the EJB container
creates a new EJBHome object and registers it with Java
Naming Directory Interface (JNDI). This way, any client can
look it up in a directory

The client does a JNDI lookup using its registered name.

JNDI sends back a stub of the EJBHome object. Now the
client has local access to its create() method. The client
invokes create() and the actual distributed bean is created on
the server. The stub may be destroyed.

Using the EJBObject interface you created, the EJB container
creates a new EJBObject object (which becomes the
bodyguard to the newly created distributed bean) and its stub
is returned to the client (this stub has exactly the same
methods as the distributed bean)

Now the client can make local calls using the stub


EJB Clients

Almost any type of program can be an EJB client

Another EJB

The client bean can be deployed in the same or a different EJB

A Java Servlet or JavaServer Page

The Servlet or JSP provides a server
side interface to the EJB logic

A Java application

A stand
alone Java application can make use of centralized business
logic through EJBs

Security considerations make this most attractive for Java applications
which run inside a corporate firewall

Java clients

EJBs are compatible with, for example, CORBA


Types of EJB


Types of EJB

Session Bean

A non
persistent object that implements some business logic and runs on a server (similar to
business layer components)

Reused by different clients, but not shared concurrently

Stateless session beans retain no conversational state between method calls, e.g. a credit card
verification method performs the task on invocation and does not retain any information about
the credit card.

Stateful session beans retain conversational state between method calls, e.g. an ATM could
perform operations like checking an account balance, transferring funds, or making a withdrawal
could be performed, one by one, by the same customer. So the bean needs to keep track of the
state for each of these operations.

driven beans

A message
driven bean instance is an asynchronous message consumer

driven beans have no client visibility


Types of EJB..

driven beans act as a Java Messaging Service (JMS) message listener, like how an
event listener listens to events, message
driven beans listens to messages. The messages may
be sent by any J2EE component
an application client, another enterprise bean, a Web
or by a JMS application or system that does not use J2EE technology.

Entity beans

An entity bean instance represents an object
oriented view of data in a persistent storage

E.g. a program can create an entity bean and then the program can be stopped and restarted
but the entity bean will continue to exist. After being restarted, the program can again find the
entity bean it was working with and continue using it.

Plain old Java objects (POJO) are used only by one program. An entity bean, on the other hand,
can be used by any program on the network.

Client programs just need to find the entity bean via JNDI in order to use it. Entity beans must
have a unique primary key that is used to find the specific entity bean they want to manipulate.
For example, an "employee" entity bean may use the employee's social security number as its
primary key. Methods of an entity bean run on a "server" machine. When a client program calls
an entity bean's method, the client program's thread stops executing and control passes over to
the server. When the method returns from the server, the local thread resumes execution.

managed persistence (CMP) and bean
managed persistence (BMP) are available


Structure of an EJB

To become an EJB, a Java class needs to implement specific

Session beans must implement javax.ejb.SessionBean

Entity beans must implement javax.ejb.EntityBean

driven beans must implement

All these interfaces extend the marker interface
javax.ejb.EnterpriseBean. This is how the system knows the
class is an enterprise bean. Also, because this interface
extends, all enterprise beans can be
converted to a bit
blob (a class that can be saved as a flat



The EJB specification mandates that:

EJBs be packaged in EJB JAR files

The deployment descriptor be included in an EJB JAR in the file

Deployment descriptor contains

Structural information

The structure of an enterprise bean

The external dependencies of the enterprise bean

Application assembly information

How the enterprise beans in the ejb
jar file are assembled into a larger application
deployment unit (usually an Enterprise Archive or EAR file)

The fundamental element within the ejb
jar contains the declarations of
one or more EJBs

An EJB is declared as <entity>, <session> or <message