enterprise javabeans - architecture and goals

Lecture 7
Enterprise JavaBeans:
Architecture and Goals

What are Enterprise JavaBeans
•
EJB is a semi-automated server-side component management architecture that facilitates
the deployment of enterprise-class distributed object applications in Java.
–
server-side
•
highly-available enterprise (24x7)
–
components
•
encapsulated (self-contained)
•
portability
•
object model (inheritance, polymorphism, interface/implementation
disjunction)
•
reusability
–
automated management
•
Persistence (distributed 2-Phase Commit Transactions)
•
Security
•

Load balanced/fault tolerant
–
deployment
–
enterprise distributed object applications
–
Java language

Foundations
•
EBJ Technology is built on other key J2EE and OMG
foundations:
–
RMI objects
•
JNDI naming and location
–
Does for Novell’s NDS and LDAP access what JDBC did
for Sybase and Oracle DBMS acccess
•
Remote method exposure
–
JDBC
–
JTS/JTA
–
CORBA IIOP

What’s J2EE all about?
•

J2EE is a specification
–
Vendor independent
–
Platform independent (portable)
–
API consistency
–
Test suite
–
Reference implementation

J2EE Technologies
(EJB as a canton in a larger confederacy)
•
RMI and RMI-IIOP
•
Java Naming and Directory Interface (JNDI)
•
JDBC
•
Java Transaction API (JTA) and Java Transaction Service
(JTS)
•
Java Messaging Service (JMS)
•
Java Servlet API (JSDK)
•
Java Server Pages (JSP)
•

Java IDL (CORBA)
•
JavaMail API
•
Extensible Markup Language (XML)
•
Enterprise Java Beans (EJB)

Stated Goals of EJB
•
“The EJB architecture will be the standard component
architecture for building distributed object-oriented
business applications in the Java Programming Language.”
Sun EJB Specification 1.1
•
“Application developers will not have to understand low-
level transaction and state management details, multi-
threading, connection pooling and other complex low-level
APIs.” ibid.
•
“EJBs will follow the Write Once, Run Anywhere
philosophy of the Java Programming Language. An EJB
can be developed once, and then deployed on multiple
platforms without recompilation or source code
modification.” ibid.

Stated Goals of EJB
•
“The EJB architecture will address the
development, deployment, and runtime aspects of

an enterprise application’s life cycle.” ibid.
•
“The EJB architecture will provide
interoperability between enterprise Beans and
non-Java programming language applications.”
ibid.
•
“The EJB architecture will be compatible with the
CORBA protocols.” ibid.

What benefits does the EJB
Architecture Provide?
•
Component Transaction Monitor
–
Distributed Transaction/2 Phase monitoring
•
Generic Naming and Implicit component location
–
clients do not have to know the specific
location of a component to use it
•
Security
–
Automated User Authentication via Access
Control Lists

What benefits does the EJB
Architecture Provide?
•

Persistence
–
Implicit persisting, activation and deactivation
–
Implicit component life cycle management
•
Implicit distributed transaction management
–
Distributed 2-Phase commit
(Begin,End,Commit,Rollback)
•
Load Balancing/Transparent Failover
–
Resource Pooling
–
Multi-client support
•
Metadata Management
–
Declarative Specification

Server Architecture

Client-Server Interaction

Component Characteristics
•
An enterprise bean contains business logic that
operates on the enterprise’s data.
•

An enterprise bean’s instances are created and
managed at runtime by a Container.
•
An enterprise bean can be customized by the
customer at deployment time by editing the
bean’s metadata
•
Client access is indirect it always is via the
Container
•
The EJB can be deployed in any compliant
Container

EJB Topology
•
An EJB may implement:
–
an object that represents a stateless (highly available)
service
•
a calculation algorithm (insurance, finance, trading,
etc.)
•
a lookup service
•
a security manager that validates a user and returns a
token
•
pooled resource
•

Stateless Session Bean

EJB Topology
•
An EJB may implement:
–
an object that represents a conversational session with a
particular client (contradistinguished from HTTP
protocol)
•
Extension of client business functionality on the
server side
–
avoids Fat clients and 2-tier scenarios
•
Typically will handle database operations on behalf
of the client
•
automated instance passivation and activation
•
pooled resource
•
Stateful Session Bean

EJB Topology
•
An EJB may implement:
–
a high-level abstraction that represents a
business entity that encapsulates business state

and is accessible by multiple clients
•
a “Customer” object
•
a “Contract” object in futures trading
•
a “Policy” object in insurance
•
Entity Bean

EJB Topology
•
An EJB may implement:
–
a middleware observer that listens for certain
events in the system, and acts as a consumer of
events it is interested in
•
a “logger” object
•
a “trade validator” object in futures trading
•
a “claim processor” object in insurance
•
Message-Driven Bean

Session Objects
•
execute some business logic on behalf of a single
client

•
can be transaction enabled
•
does not directly represent data in a database, but
can access one
•
are generally short-lived
•
are removed when the Container crashes (client
must reconnect)
•
participate in a Container’s scalable runtime
environment, executing concurrently with multiple
instances

Entity Objects
•
provide a class (object-encapsulated) view
of data in a database
•
allow keyed, shared access from multiple
simultaneous clients
•
are generally long-lived
•
along with their primary keys and remote
references survive the crash of the
Container

Implementing an EJB Object

•
Home Interface
–
The Client’s way of creating a local reference
to a server
–
Defines a single create(…) method
•
Remote Interface (think CORBA IDL)
–
This interface defines the client semantics for
the bean
–
Here is where you declare the methods your
bean will implement

Implementing an EJB Object
•
Bean Implementation (think CORBA Impl)
–
Here is where you implement the methods in
the Remote Interface.
–
Similar to a CORBA implementation
implementing an IDL interface, the Bean
implementation implements the Remote
Interface’s declared methods.

Implementing an EJB Object
•

The Bean implementation also defines callback
methods that the Container will use to
communicate with the bean. These include:
–
ejbPassivate()
–
ejbActivate()
–
ejbCreate()
–
ejbRemove()
–
ejbLoad(): entity
–
ejbStore(): entity
–
ejbFindByPrimaryKey(Primary key): entity

General Security
•
2 Levels of security that clients must pass in EJB:
–
client authentication
•
verifies the client is indeed whom he claims to be
•
username/password authentication
•
after authentication, given a security identity for the
rest of the session

–
client authorization
•
grants permission to a security identity to perform
certain operations
•
occurs during an EJB method call
•
supports both declarative (container-based) and
programmatic authorization

General Security
•
Security Roles
–
Security Roles are collections of client
identities, such as “general user”, “privileged
user”, “system administrator”, etc.
–
Every Security Role can be assigned method
permissions, which grant certain roles the rights
to access some defined group of methods on a
home or remote interface
–
Roles are defined in the deployment descriptor

General Security
•
Declarative Authorization (in deployment
descriptor)

–
modifySystemProperties [administrator]
–
searchData [everyone]
•
Programmatic Authorization (based on
java.security.Principal and SessionContext)
–
isCallerInRole(securityRole) - checks to see
that the current user (per the EntityContext) is a
member of a role
–
getCallerPrincipal() - returns the secure name
of the client user

Session Bean Persistence
•
Stateful Session Bean Passivation and Activation
–
Since Stateful SessionBeans cannot be shared
but are client-specific, their resources are
limited and can, under load, be persisted to
permanent storage and later recalled into
memory
–
Passivation is the process whereby a stateful
session bean’s non-transient conversational
state is serialized to permanent storage. After
the container has passivated the state,
ejbPassivate() is called to allow the Bean to

release any database or socket connections, etc.