You are on page 1of 16

J2EE

Kenneth M. Anderson
CSCI 7818 - Web Technologies
October 3, 2001
Credit where Credit is Due
• Most (if not all) of the information in this
presentation comes from
– Enterprise JavaBeans
– by Richard Monson-Haefel
– O’Reilly & Associates, Inc.
– © 1999 and 2000
J2EE
• Stands for “Java 2, Enterprise Edition”
• It is a collection of standards
– JDBC, JNDI, JMX, JMS
• It is a component technology
– Enterprise JavaBeans
• It is an “application server”
– Following in the footsteps of Component
Transaction Monitors
History
• Distributed Objects
– CORBA, DCOM, etc.
– Three-tier scenario: presentation, business logic, and backend
databases
• Hard to “get right” without the proper infrastructure
• Server-Side Components
– Focuses on encapsulating “business rules” into objects in the
middle tier
• Component Transaction Monitors
– Descendant of CORBA’s Object Request Broker
• provides discovery, persistence, event notification, transactions, etc. for
three-tier or n-tier applications
Enterprise JavaBeans, Defined
• From Sun:
– The Enterprise JavaBeans architecture is a component
architecture for the development and deployment of
component-based distributed business applications.
Applications written using the Enterprise JavaBeans
architecture are scalable, transactional, and multi-user
secure. These applications may be written once, and
then deployed on any server platform that supports the
Enterprise JavaBeans specification
Enterprise JavaBeans
(shorter definition)
• From O’Reilly’s Enterprise JavaBeans book
– Enterprise JavaBeans is a standard server-side
component model for component transaction
monitors
• Aha! It’s a standard for building server-side
components and deploying them in
component transaction monitors
Distributed Objects Scenario
Client-Side Network Middle Tier
connect to
invokes
remote
Skeleton
object invoke Server-
Client Stub
Side
Compo
nent
return
return return
results
results results

Stub and Skeleton are auto-generated; client “thinks” its making a local
call, most networking details are hidden from client; the main detail
is obtaining a reference to the remote object →naming service
Architectural Overview
• Two Types of Enterprise JavaBeans
– Entity Beans
• Used to model business concepts such as customer,
cruise ship, inventory item, etc.
– Session Beans
• A server-side “representative” of the client; session
beans are responsible for managing processes or
tasks; for instance in an airline reservation scenario,
the session bean would be responsible for reserving
a seat on a particular flight and verifying payment
Insight into Session Beans
Client Using Client Using
only Entity Beans Session Beans

EJB Server
To Implement an Enterprise Bean
• Any enterprise bean must define two interfaces
and one or two classes
– Remote interface
• defines a bean’s external interface
• must extend javax.ejb.EJBObject (which in turn extends
java.rmi.Remote)
– Home interface
• The home interface defines a bean’s “life cycle” methods, eg.
create bean, remove bean, find bean, etc.
• must extend javax.ejb.EJBHome which also extends
java.rmi.Remote
To Implement, continued…
• Bean Class
– The java class that actually implements the bean’s external
interface, e.g. the bean class provides implementations for the
bean’s “business methods”
– An entity bean must implement the javax.ejb.EntityBean interface,
while a session bean must implement the (you guessed it)
javax.ejb.SessionBean. Both of these interfaces extend
javax.ejb.EnterpriseBean
• Primary Key
– The primary key is a very simple class that provides a pointer into
a database; Only entity beans need a primary key. This class must
implment java.io.Serializable (so the entity bean can automatically
be sent to persistent storage)
Additional Info
• Clients never interact directly with a bean class, they
use stubs (which connect to skeletons, which connect to
“containers” which call the bean class…whew!)
• Why? This allows the application server to replicate
bean instances (for performance reasons), manage
transactions, etc.
• A bean also interacts with its server via a container
interface: the container calls the bean’s life cycle
methods, manages the bean’s persistence, etc.
Architecture Diagram
Client EJB Server
Home EJB Container
Interface
Home Interface
Home
Stub EJB
Home

Remote Remote Interface


Interface EJB Object
EJB Bean Class
Stub
Benefits of an Application Server
• Resource Management
– Instance Pooling and Swapping
• Server can invoke multiple instances of a bean to
handle multiple incoming requests (pooling)
• An instance of a bean class can handle requests
from multiple skeletons (swapping)
– Activation
• if a bean is “stateful,” application servers automate
the process of saving and restoring bean state when
a bean is deactived and later activated
Benefits of an Application Server
• Primary Services
– Concurrency
• Beans are automatically thread safe; application servers handle
concurrent access to a bean; They also handle reentrance
– Transactions
• Bean operations can belong to a transaction and the application server
handles “rolling back” an application’s state if a partially completed
transaction fails
– Persistence
• Application servers can map beans into database entries (and back
again)
– Naming (bean discovery) and Security (encrypted
communication and access control)
References
• Enterprise JavaBeans
– by O’Reilly
– ISBN: 1-56592-869-5
• Sun’s J2EE website
– <http://java.sun.com/j2ee/>