Transcript EJB Architecture

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 lowlevel transaction and state management details, multithreading, 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.
Session Bean Persistence
• Stateful Session Bean Passivation and Activation
– Activation is the process where the persisted
state of a bean is deserialized due to client
access on the persisted bean. The state is
restored and ejbActivate() is called to notify the
bean that it should re-establish connections,
handles, etc.
– Passivation is performed according to a Least
Recently Used (LRU) strategy. The bean
whose last client access was farthest back in
time is the first to be passivated.
Container-Managed Persistence
• The container implicitly performs all
database operations on behalf of the CMP
entity bean
• Primary Key class must be serializable
• Object-Relational database mapping is done
declaratively in the deployment descriptor
• Programmer generally writes little if any
direct JDBC connection code (but is free to
if he wishes)
Container-Managed Persistence
• finder functions are described in the deployment
descriptor (ejb-jar.xml):
– <query>
–
<query-method>
–
<method-name>findAccount</method-name>
–
<method-params>
–
<method-param>double</method-param>
–
</method-params>
–
</query-method>
–
<ejb-ql>
–
<![CDATA[SELECT OBJECT(a) FROM AccountBean AS a
WHERE a.balance = ?1]]
– >
–
</ejb-ql>
–
</query>
Entity Bean Persistence
• Bean-Managed Persistence
– Bean developer, not the container, provides all
data access logic
– Developer implements callbacks such as
ejbFind…(), ejbCreate(), ejbActivate(),
ejbLoad(), ejbStore(), ejbPassivate(),
ejbRemove()
– Developer uses JDBC or SQL/J to interact with
the database
Distributed Transaction Support
• JDBC provides default non-distributed
transaction support with autocommit
• This is insufficient when dealing with
distributed components which may
severally be involved in a single transaction
• ACID Properties (Atomic, Consistent,
Isolated, Durable)
Distributed Transaction Support
• Only flat transactions are supported currently in
EJB, not nested transactions
• Multiple database can be updated automatically in
a single transaction
• Transactions can be handled either declaratively or
programmatically
– Programmatically handled requires programmer
to issue Begin, End, Commit, Rollback
– Declaratively handled requires the EJBObject
(container) to issue transaction boundaries on
behalf of the implementation
Distributed Transaction Support
• EJB Transaction Attribute Values (set in Deployment Descriptor):
– TX_BEAN_MANAGED: bean is programmatically handling all
transaction boundaries
– TXN_NOT_SUPPORTED: bean operates outside of any particular
transactional context
– TXN_REQUIRED: bean must always run within the context of a
transaction
– TXN_REQUIRES_NEW: bean must always have its own new
transaction created, current transaction, if any, is suspended
– TXN_SUPPORTS: bean only runs in a transaction if one is already
present
– TXN_MANDATORY: bean must run in a transaction, and that
transaction must already be present and active
(javax.ejb.TransactionRequired exception)
Distributed Transaction Support
• EJB Isolation Levels (set in Deployment Descriptor)
– TRANSACTION_READ_UNCOMMITTED (no
protection from dirty reads, repeatable reads, etc.)
– TRANSACTION_READ_COMMITED (eliminates
dirty reads, reading uncommited data)
– TRANSACTION_REPEATABLE_READ (eliminates
changing data during updates)
– TRANSACTION_SERIALIZABLE (eliminates dirty
reads, unrepeatable reads, and phantom (new) reads)
Resource Management/Load Balancing
Mechanisms
• Instance pooling in EJB Servers reduces the number of
component instances needed overall, by allowing clients
to share components individually or collectively
• Pooling also reduces the frequency of component creation
and removal
• Each instance of a component in a pool is equivalent, but
some may have higher priority due to access algorithms
(LRU, Round-Robin)
• New instances can be created and added to the pool, and
other instances can be checked in and out for usage by
clients
• Pool management is handled intelligently by the container
• Database ConnectionPools are supported and userdefined
Resource Management/Load Balancing
Mechanisms
• EJB Servers/Containers provide Instance Swapping
– Stateless SessionBeans can easily be swapped for
client access because they maintain no client-specific
state, they are truly equivalent, and one will work as
well as another
– Entity beans can also be swapped through the
interaction of the container and the setEntityContext()
and unsetEntityContext() methods
• EJB Servers/Containers provide management through
activation and passivation
Failover Management
• Stateless Session Beans: On failure, bean is
automatically reinstantiated in a different server
process
• Stateful Session Beans: On failure, manual
reconfiguration on another machine is required
• Entity Beans: On failure, Client application reacts
to RemoteException by reinvoking
findByPrimaryKey, which will automatically
map to other supporting groups
Metadata Management
• Deployment Descriptors allow EJB
containers to supply run-time middleware
services (persistence, transaction, security,
etc.) to a generic EJB, thus relieving the
EJB from having to hard-code this support
into the bean itself
• Entries in a Deployment Descriptor
cumulatively make up the bean’s metadata
Metadata Management
• A bean’s metadata may also include bean-specific
properties that are become Java properties, that are
available to a bean at runtime
• With EJB 1.0, you had to write a single deployment
descriptor for each bean, and that DD had to be a
serializable Java class, based on a plain text file
description, and a manifest file was needed to describe all
the deployment descriptors in an ejb-jar file
• With EJB 1.1, you need only write a single deployment
descriptor for each ejb-jar file, and this descriptor is
written in XML. Since there is now only one deployment
descriptor, manifest files are no longer needed
Deployment Description Overview
•
•
•
•
•
Specify Home Interface
Specify Remote Interface
Specify Bean implementation class
Specify Bean type (session or entity)
Specify the JNDI name for the home
interface for Clients to use
• Transaction support definition
Deployment Description Overview
•
•
•
•
Transaction isolation level definition
Access Control Lists (ACLs) and attributes
Session Timeout (session beans only)
Database member-Class attribute mapping
(container-managed entity beans only)
• Reentrancy information (entity beans only)
• Primary Key class (entity beans only)
• Environment specifics
Abstracting Capabilities of the
Container
•
•
•
•
Multithreading
Resource Pooling
Scaling
Distributed naming and location
– Container is responsible for make the home interfaces
of its deployed beans available via JNDI
• Automatic persistence
– Bean-Managed Persistence
– Container-Managed Persistence
• Transaction handling
• Distributed Transaction Management
Responsibilities of the Container for
Session Beans
• Making the home interfaces of deployed beans
available via JNDI
• Implementing the home interface of each installed
EJB (EJBHome)
– home interface allows a client to create a new
session object (factory method)
– home interface allows for the removal of a
session object
• Implementing the remote interface of each
installed EJB (EJBObject)
– remote interface allows clients to make
business method calls on a session objects
Responsibilities of the Container for
Session Beans
• Implementing Handle (support) classes for the
Home and Remote interfaces
• Implementing the EJBMetaData class
• Must ensure that only one thread can be executing
an instance at any time (session objects are
serialized, single-client servants)
Responsibilities of the Container for
Entity Beans
• Making the home interfaces of deployed beans
available via JNDI
• Implementing the home interface of each installed
EJB (EJBHome)
– home interface allows a client to create a new
session object (factory method)
– home interface allows for the removal of a
session object
• Implementing the remote interface of each
installed EJB (EJBObject)
– remote interface allows clients to make
business method calls on a session objects
Responsibilities of the Container for
Entity Beans
• Implementing Handle (support) classes for
the Home and Remote interfaces
• Implementing the EJBMetaData class
• Must ensure that reentrant rules are
followed (intra-transactional legal loopback,
illegal concurrent call)
• Implementation of robust (long-lived)
object references. A client should be able to
use an object reference across a server crash
and restart
BEA Weblogic Enterprise
(WLE)
•
•
•
•
WLE combines an ORB and OLTP functionality within ATMI (Application-toTransaction Manager Interface), CORBA and EJB
CORBA and EJB objects share the same transaction, security, configuration,
and monitoring infrastructure
Native IIOP communication between RMI, EJB, CORBA Java/C++, and
Tuxedo ATMI (Xopen XATMI compliant)
WLE Domain Offerings:
–
–
–
–
–
–
–
–
CORBA
EJB
ATMI
Security
TP Monitor
Web Server & Servlet Engine
RMI
HTML/JSP