Beruflich Dokumente
Kultur Dokumente
defined task
problems
problems
pricing rules
10 RAM modules
• The pricing rules are not unique for ordering computer parts only
engine
application
• Applets are portable java programs that can be downloaded and can
that host
• Applets and Servlets are well suited to handle client side operations
• Enterprise Java Beans are server side components that are meant to
layers
Presentation layer
Data layer
Multi-tier Architecture (contd.)
• The data layer is used by the business logic layer to persist state
permanently
Multi-tier Architecture (contd.)
• Central to the data layer is one or more database that house the
stored data
isolate each layer from the other so that it will be possible to plug
in a different view
the needs
• There is two tier architecture, three tier architecture and even n tier
data layer
• There are many advantages in pushing business logic into the data
layer like saves many round trips, increases the speed of database
Server Side Component Architecture Solutions
arisen
•The distinction between CORBA and J2EE is that CORBA has only
the
highlighted many problems with the Enterprise APIs and that lead
deployments in Java
• J2EE addresses all the problems raised by Sun’s Enterprise APIs like
• J2EE provides a test suite for vendors to test their products and if
the
The Java 2 Platform Enterprise Edition (contd.)
Java
Transaction Java Server
API and Pages
Java 2
Java
Enterprise
Transaction
Edition
Service Servlet
Java Mail
Java EXtended
MessagingS Markup
Java IDL Connectors ervice Language
Java Remote Method Invocation (JRMI)
• JRMI is seamless so that a user will not know that he is using RMI
network
and passwords
that client
portable way
execution
transactions
Java Transaction API and Java Transaction Service (contd.)
the scenes and the client code do not directly interact with JTS
depend on JTS
Java Messaging Service (JMS)
service
Java Servlets
• Servlets are networked components that can be used to extend the
• Servlets are request response oriented in that they take from client
servlets
server
Java Server Pages (JSP)
• Java Server Pages are very similar to servlets and JSP scripts are
• JSP scripts are not pure Java code but more centered around look
heterogeneous objects
• The connectors are different from the other J2EE APIs because
• The deployer
application
• Reuse by customization
• Enterprise beans can range in size and scope like smaller grained
enterprise beans which are very concrete with limited scope and
Beans to run
within them
containers
EJB Server
Enterprise
Enterprise
Java Bean3
Java Bean1
Enterprise Enterprise
Java Bean2 Java Bean4
EJB Server and container responsibilities
• The Servers and containers provide both implicit services and
explicit services
• Implicit security
• Implicit persistence
as needed
• Server clustering
architecture
The EJB Deployer
• The Business stores the list of their employees and their security
must adapt the access level of the beans to fit the particular
environment
containers provide
• There are two different kinds of enterprise java beans the session
business processes
calculations etc.
Session Beans (contd.)
• Session beans are called session beans because they live for about
• Session beans are usable by one client at a time and they are not
• There are two subtypes of session beans the stateful session beans
business
method invocation the same state will be available for the client in
Stateless Session Beans
• Entity bean do not contain business process logic rather they model
data
• Session beans use entity beans to represent the data session bean
uses
Entity Beans (contd.)
• It is possible to read an entire set of data out of a database at once
• An entity bean implements the data access logic layer in a multi tier
architecture
EJB Container Permanent Storage
Client code
such as Entity Bean
applet
Entity Beans (contd.)
• Entity bean survive critical failures such as application server
permanent database
• Entity beans have a life cycle much longer than Session beans even
inside
• The data that entity beans model could exist in a database before a
any language and EJB takes advantage of this and allows for the
persistent
Bean Managed Persistent Entity Beans
• Many companies have been involved each with customers that have
functionality
Session Beans versus Entity Beans
entity bean
• The key difference between the two are that session bean represent
related logic
workstations
Session Beans versus Entity Beans (contd.)
• When the customer places the order an order entity bean is used to
• The order is fulfilled by another session bean that contains the logic
to do so
• Entity bean defines the core business data such as purchase orders,
over time
access to data
• EJB containers house the enterprise beans and make them available
• State Management
• Transactions
• Security
• Persistence
services
• The EJB container is also responsible for controlling the life cycle of
then the container can destroy some beans that are not being
the EJB container because there is no state lost from the primary
client
• If a client times out the EJB container destroys the bean or reuse it
• Consider the case when a new client request a component and the
• The container can take a component that hasn’t been used for a
while
and write the state out to disk and the bean can be reassigned to
a different client
• When the original client makes a request the original client’s bean
• Transactions allow multiple users to share the same data and they
guarantee that any set of data they update will be completely and
wholly written
participants
Security
used to validate
• If the user has the correct rights he can perform the desired
operation
Persistence
underlying storage
• In the bean the machine location should not be hard coded because
it
• Each EJB container ships with a suite of glue-code tools which are
component
remote accessibility
Specialized Container Features
other containers
• eg. If clients are less active at night than during the day then a
• Distributed transactions
client of that bean the bean must adhere to a well defined interface
component
• The EJB specification defines a few standard interfaces that the bean
• The basic interface that all bean classes must implement is the
javax.ejb.EnterpriseBean interface
The Enterprise Bean Class (contd.)
{ }
•Both session beans and entity beans have more specific interfaces
• The enterprise bean class can not be called across the network
enabled
• The network enabled object receives calls from client and delegates
client and the bean and the layer of indirection manifests itself
as
The EJB Object (contd.)
EJB Container
Client Home
Code Interface
Home
Ca
ll a
Object
m
et
ho
d
EJB
Remote Object
Interface
Ac Enterprise
q
del uire a Java Bean
ega B
the t e a
Be e the n an
an me d
tho
d to
The EJB Object (contd.)
• The EJB object acts as glue between the client and the bean and it
supplies glue code tools that generate the class file for the EJB
object automatically
The Remote Interface
• The clients invoke methods on EJB objects rather than the beans
• Remote interfaces must comply with the rules that the EJB
a
The Remote Interface (contd.)
throws java.rmi.RemoteException;
throws java.rmi.RemoteException;
throws java.rmi.RemoteException;
The Remote Interface (contd.)
public abstract boolean isIdentical(javax.ejb.EJBObject)
throws java.rmi.RemoteException; }
• These methods are the required methods that all EJB objects must
implement
• The client code that wants to work with the beans calls the methods
in javax.ejb.EJBObject
• When a bean’s client invokes any of the business methods the EJB
java.rmi.RemoteException
invoking a bean
conventions
Java RMI and EJB Objects (contd.)
this means the client code is portable and not tied to a specific
and the client will not be aware of exactly where the EJB object
reside
• Like EJB objects, home objects are proprietary and specific to each
EJB container
• Home objects are physically part of the container and are auto
EJB objects
• EJB defines some required methods that all home interfaces must
javax.ejb.EJBHome interface
means the home interfaces are fully networked Java RMI remote
Deployment Descriptors
• Deployment descriptors enable EJB containers to provide implicit
service automatically
transaction
particular bean
Deployment Descriptors (contd.)
• It is the responsibility of a bean provider to create a deployment
descriptor
• The bean read these properties at runtime and use the properties to
algorithm to use
• Once the Ejb jar file is made the enterprise bean is complete and is a
• To install the EJB objects the jar file is decompressed , extracted and
the EJB objects and home objects are generated and deployed
Session Bean
stock
Session Bean Lifetime
times out
crashes
Session Bean Lifetime (contd.)
methods
a bean and the callback methods are not intended for clients
Conversational versus Nonconversational Session Beans
• A conversation is an interaction between a client and a bean
method
conversations
Conversational versus Nonconversational Session Beans (contd.)
• Any stateless session bean can service any client request because
client
All Session Bean Methods are Serialized
bean instance
javax.ejb.EnterpriseBean
• The interface defines a few required methods that the EJB container
• Clients of the bean will never call these methods because these
javax.ejb.EnterpriseBean
throws java.rmi.RemoteException;
throws java.rmi.RemoteException;
throws java.rmi.RemoteException;
throws java.rmi.RemoteException; }
setSessionContext(SessionContext ctx)
session context
• The bean can use session context to query the container about the
Import javax.ejb.*;
this.ctx = ctx;
………..
}
ejbCreate(…)
• The ejbCreate() method initialize the session bean
arguments
• Clients can initialize the beans in different ways because there are
Import javax.ejb.*;
this.memberVariable = initialValue;
………..
}
ejbCreate(…) (contd.)
• The ejbCreate() methods are callback methods that the container will
invoke
deal
• If too many beans are instantiated the EJB container can passivate
• The container can then release the resources the beans had claimed
Import javax.ejb.*;
………..
}
ejbActivate( )
• If the client needs to use a bean that has been passivated the
ejbActivate() method
import javax.ejb.*;
public class MyBean implements SessionBean {
public void ejbActivate() {
<open socket connections, etc….>
}
………..
}
ejbRemove( )
• If a container wants to remove the session bean it calls the
business methods
• For clients to call the business methods the business methods must
import javax.ejb.*;
return (i + j);
}
Understanding How to call Session Beans
• Calling the session beans takes place in four steps and they are
services
resources etc.
• There are two common steps that must be taken to find any
descriptor, the J2EE product will bind the nickname to the resource
2. Clients of the resource can use the nickname with JNDI to look up
the client
• Clients do not hard code the machine names that home objects
• Clients will use the nickname to identify the home object it wants
• JNDI goes over the network to some directory service to look for the
3 Home
Client
Object
5
4
7 Enterprise
6 EJB Java
1 2 Object Beans
object
• To create an EJB object call one of the create() methods on the home
method may not be called because the container can pool and
• As the client has an EJB object it can start calling one or more of the
• When the client calls a method on the EJB object the EJB object
existing instance
• When the bean instance is done the EJB object takes the return value
• The remove() method enables the container to destroy the EJB object
them apart
ejbCreate() cal
•The EJB containers can pool stateless session bean instances before
clients
Characteristics of Stateless Session Beans (contd.)
• The benefit of bean instance pooling is that the pool of beans can be
• If more clients connect to the deployment during day than night then
the container might allow to have a large pool during day and a
small pool at night which frees system resources for other tasks
EJB objects
• A new bean does not necessarily have to be created at the same time
available pool
beans expose
• The EJB object will delegate all client requests to actual beans
package com.session.helloworld;
import javax.ejb.*;
import java.rmi.RemoteException;
import java.rmi.Remote;
/*
The one method - hello - returns a greeting to the client.
*/
public String hello() throws RemoteException;
}
Hello World remote interface explanation
• The required container callback methods are also added to the code
environment
package com.session.helloworld;
import javax.ejb.*;
import java.rmi.RemoteException;
/*
This is the home interface for HelloBean. This interface is
implemented by the EJB Server's glue-code tools – the
implemented object is called the Home Object, and serves as a
factory for EJB Objects. One create() method is in this Home
Interface, which corresponds to the ejbCreate() method in
HelloBean.
*/
Hello World home interface source code (contd.)
objects
• The home interface exposes one method to create an EJB object and
• Bean home name : The nickname that clients use to look up for the
• Home interface class name : The fully qualified name of the home
interface
• Remote interface class name : The fully qualified name of the home
Writing the Deployment Descriptor (contd.)
beans only
invocations
in the bean must be available for that same client on the next
method request
• When an application goes idle its memory can be swapped out from
physical memory and onto hard disk and when the application
•The same scenario can be used with stateful session bean resources
activation
transaction completes
convert the bean’s conversational state into a bit blob and the
• The EJB container calls the ejbPassivate() method to give the bean a
• The bean is a counter bean and the bean will be counting up one by
one
• The current count will be stored within the bean and it will increment
called val
Count Bean remote interface source code
package com.session.count;
import javax.ejb.*;
import java.rmi.RemoteException;
/* These are CountBean's business logic methods. This interface is
what clients operate on when they interact with EJB objects. The
container vendor will implement this interface; the implemented
object is the EJB object, which delegates invocations to the
actual bean. */
public interface Count extends EJBObject {
/* Increments the int stored as conversational state */
public int count() throws RemoteException;
}
Count Bean source code
package com.session.count;
import javax.ejb.*;
/* Demonstration Stateful Session Bean. This Bean is initialized to
some integer value, and has a business method which
increments
the value. This example shows the basics of how to write a
stateful session bean, and how passivation/activation works.
*/
public class CountBean implements SessionBean {
private transient SessionContext ctx;
/* The current counter is our conversational state. */
public int val;
/* Business methods Counts up */
Count Bean source code (contd.)
public int count() {
System.out.println("count()");
return ++val;
}
/* EJB-required methods */
public void ejbCreate(int val) throws CreateException {
this.val = val;
System.out.println("ejbCreate()");
}
public void ejbRemove() {
System.out.println("ejbRemove()");
}
Count Bean source code (contd.)
parameters in ejbCreate()
• The initialization method uses val as the starting state of the counter
• The val member variable obeys the rules for conversational state
package com.session.count;
import javax.ejb.*;
import java.rmi.RemoteException;
CountBean file.
*/
Count Home interface source code (contd.)
/* This method creates the EJB Object. @param val Value to initialize
*/
}
Count Home interface explanation
• The home interface shows how to create and destroy the Count EJB
object
• The Max beans loaded at any time descriptor restricts the maximum
• The container can load three beans at a time and the container will be
memory
descriptor
• The bean is not declared stateful in the bean code itself because this
back
Count client source code
package com.session.count;
import javax.ejb.*;
import javax.naming.*;
import java.util.Properties;
/*This class is a simple example of client code which invokes
methods on a simple Stateless Enterprise Bean. This create 3
EJB
Objects in this example, but we only allow the container to have 2
count[i] = home.create(countVal);
/* Add 1 and print */
countVal = count[i].count();
System.out.println(countVal);
/* Sleep for 1/2 second */
Thread.sleep(500); }
/* A call on count() on each EJB Object to make sure the beans
were passivated and activated properly */
System.out.println("Calling count() on beans...");
for (int i=0; i < 3; i++) {
/* Add 1 and print */
countVal = count[i].count();
System.out.println(countVal);
Count client source code (contd.)
• The home object is used to create three different Count EJB objects
different clients
• The deployment descriptor limits the bean pool size to two beans so
during the previous step some of the three beans must have
• For stateless bean the EJB container is able to easily pool and reuse
• When the same paradigm is used with a stateful beans the bean state
client request arrives because the bean cannot hold any state on
• Another way to get client specific data to a stateless bean is for the
• If the business process lasts for a single method call then stateless