Lecture 7 Enterprise Java Beans Architecture and Goals

Lecture 7 Enterprise Java. Beans: Architecture and Goals

What are Enterprise Java. Beans • 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 (24 x 7) – 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 J 2 EE 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 J 2 EE all about? • J 2 EE is a specification – Vendor independent – Platform independent (portable) – API consistency – Test suite – Reference implementation

J 2 EE 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) Java. Mail 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: – ejb. Passivate() – ejb. Activate() – ejb. Create() – ejb. Remove() – ejb. Load(): entity – ejb. Store(): entity – ejb. Find. By. Primary. Key(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) – modify. System. Properties [administrator] – search. Data [everyone] • Programmatic Authorization (based on java. security. Principal and Session. Context) – is. Caller. In. Role(security. Role) - checks to see that the current user (per the Entity. Context) is a member of a role – get. Caller. Principal() - returns the secure name of the client user

Session Bean Persistence • Stateful Session Bean Passivation and Activation – Since Stateful Session. Beans 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, ejb. Passivate() 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 ejb. Activate() 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>find. Account</method-name> – <method-params> – <method-param>double</method-param> – </method-params> – </query-method> – <ejb-ql> – <![CDATA[SELECT OBJECT(a) FROM Account. Bean 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 ejb. Find…(), ejb. Create(), ejb. Activate(), ejb. Load(), ejb. Store(), ejb. Passivate(), ejb. Remove() – 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. Transaction. Required 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 Connection. Pools are supported and user-defined

Resource Management/Load Balancing Mechanisms • EJB Servers/Containers provide Instance Swapping – Stateless Session. Beans 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 set. Entity. Context() and unset. Entity. Context() 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 Remote. Exception by reinvoking find. By. Primary. Key, 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 EJBMeta. Data 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 EJBMeta. Data 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-to -Transaction Manager Interface), 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