Java Enterprise Edition (Java EE)

emptyslowInternet and Web Development

Nov 12, 2013 (3 years and 8 months ago)

51 views

EJB

Java Enterprise Edition (Java EE)

FMIS 3202 Enterprise System Architectures

Nik R. Hassan

Spring 2007

2

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.

3

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


4

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


5

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.



Client
Stub
Skeleton
EJB Object
Bean
Remote Interface
Network
Remote Interface
Remote Interface
Request Interceptor
Distributed Object
6

Remote Method Invocation (RMI)


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

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
stub
) 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
skeleton
. This skeleton unpacks the message and invokes
the
real
method

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

7

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
java.net.Socket documentation. Every time you create a new socket to connect, you need to
declare that it is risky):


If you
write

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

keyword
(e.g. the Socket constructor), or


If you
call

a method that throws an exception, you must acknowledge that it is risky by wrapping
the call in a
try
-
catch
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
-
catch


try { //start of try
-
catch


socket = new Socket(“127.0.0.1”, 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

8

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

9

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


10

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
container


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


Non
-
Java clients


EJBs are compatible with, for example, CORBA

11

Types of EJB

12

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.


Message
-
driven beans


A message
-
driven bean instance is an asynchronous message consumer


Message
-
driven beans have no client visibility

13

Types of EJB..


Message
-
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
component
--
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.


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

14

Structure of an EJB


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


Session beans must implement javax.ejb.SessionBean


Entity beans must implement javax.ejb.EntityBean


Message
-
driven beans must implement
javax.ejb.MessageDrivenBean


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 java.io.Serializable, all enterprise beans can be
converted to a bit
-
blob (a class that can be saved as a flat
file).


15

Deployment


The EJB specification mandates that:


EJBs be packaged in EJB JAR files


The deployment descriptor be included in an EJB JAR in the file
META
-
INF/ejb
-
jar.xml


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