Download J2EE

Survey
yes no Was this document useful for you?
   Thank you for your participation!

* Your assessment is very important for improving the workof artificial intelligence, which forms the content of this project

Document related concepts
no text concepts found
Transcript
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
invokes
Client
return
results
Stub
Network
connect to
remote
object
Middle Tier
invoke
Skeleton
Server-Side
Component
return
results
return
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
only Entity Beans
EJB Server
Client Using
Session Beans
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
Interface
EJB Container
Home
Stub
Home Interface
EJB
Home
Remote
Interface
Remote Interface
EJB Object
EJB
Stub
Bean Class
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/>