EJB Notes

• Enterprise JavaBeans -- remote specification


• Enterprise Java Bean -- remote component

EJB Container	runtime environment for managing enterprise beans
	instantiates and controls the enterprise beans providing system-level services

System-level services:

• transaction management for the bean


• security for the bean


• persistence of the bean


• remote access to the bean


• database connection pooling


• instance pooling for the bean

Enterprise Beans

Session Beans stateful stateless	invoked synchronously by an enterprise bean client
Entity Beans	invoked synchronously by an enterprise bean client
Message-driven Beans (MDBs)	invoked by a message container e.g. publish/subscribe topic

★ Session Beans

• 
  performs business logic for the client
  


• 
  represents a single client and not shared across clients
  


• 
  not persisted across multiple sessions
  

■ Stateful Session Bean
⇒ maintains a conversational state with one client for the duration of a single session
⇒ maintain instance variables across multiple invocations from one client during a single session
⇒ life ends when EJB container removes the enterprise bean

■ Stateless Session Bean
⇒ all data is transient between invocations for each client
⇒ each invocation is a request to a brand new object instance

★ Entity Beans

• share the same qualities found in relational databases


• intended to represent the business logic for an entity existing in persistent storage


• responsible for inserting, updating, selecting, removing data within the data source

⇒ persistent
⇒ allow shared access (container handles concurrency)
⇒ have primary keys
⇒ may participate in relationships
⇒ can participate in transactions

Persistence

• process of writing information to an external data source

▲ Bean Managed Persistence (BMP)
⇒ all access to data source is determined by programmer

▲ Container Managed Persistence (CMP)
⇒ programmer is freed from writing data-access code
⇒ entity bean can be deployed in different containers and/or against different data sources



★ Message Driven Beans

• allows enterprise applications to handle messages asynchronously

EJB can help solve

• Scalability (deployable across many different hardware platforms transparently)


• Transaction Support


• Client-location Transparency (architecture is designed to hide the location of the EJB from the client program)


• Data Source Portability (data source access can be handled by container)


• Reusability (business logic can be written once and reused easily as needed)


• Asynchronous Messaging (for applications requiring asynchronous communication)

Steps in EJB Deployment

• 
  Write classes and interfaces for enterprise bean
  
  
  
  • an interface that extends javax.ejb.EJBObject (component interface)
  
  
  • an interface that extends javax.ejb.EJBHome (home interface)
  
  
  • a class that implements either javax.ejb.SessionBean or javax.ejb.EntityBean (enterprise bean class)
  
  
  
  


• 
  Write deployment descriptor (ejb-jar.xml)
  

  
             <? xml version="1.0" encoding="UTF-8" ?>
             <ejb-jar>
                  <description>xxx</description>
                  <display-name>XXX</display-name>
                  <enterprise-beans>
                     <session>
                         <ejb-name/>
                         <home/>
                         <remote/>
                         <ejb-class/>
                         <session-type/>
                         <transaction-type/>
                     </session>
                  </enterprise-beans>
             </ejb-jar>
        

  
  


• 
  Package enterprise bean and associated files into a jar file
  


• 
  Deploy the bean
  

Hashtable, HashMap, HashSet

--- begin Hashtable ---

public class Hashtable
extends Dictionary
implements Map, Cloneable, Serializable

This class implements a hashtable, which maps keys to values. Any non-null object can be used as a key or as a value.

To successfully store and retrieve objects from a hashtable, the objects used as keys must implement the hashCode method and the equals method.

--- end Hashtable ---

--- begin HashMap ---

public class HashMap
extends AbstractMap
implements Map, Cloneable, Serializable

Hash table based implementation of the Map interface. This implementation provides all of the optional map operations, and permits null values and the null key. (The HashMap class is roughly equivalent to Hashtable, except that it is unsynchronized and permits nulls.) This class makes no guarantees as to the order of the map; in particular, it does not guarantee that the order will remain constant over time.

Note that this implementation is not synchronized. If multiple threads access this map concurrently, and at least one of the threads modifies the map structurally, it must be synchronized externally. (A structural modification is any operation that adds or deletes one or more mappings; merely changing the value associated with a key that an instance already contains is not a structural modification.) This is typically accomplished by synchronizing on some object that naturally encapsulates the map. If no such object exists, the map should be "wrapped" using the Collections.synchronizedMap method. This is best done at creation time, to prevent accidental unsynchronized access to the map:

Map m = Collections.synchronizedMap(new HashMap(...));

--- end HashMap ---

--- begin HashSet ---

public class HashSet
extends AbstractSet
implements Set, Cloneable, Serializable

This class implements the Set interface, backed by a hash table (actually a HashMap instance). It makes no guarantees as to the iteration order of the set; in particular, it does not guarantee that the order will remain constant over time. This class permits the null element.

Note that this implementation is not synchronized. If multiple threads access a set concurrently, and at least one of the threads modifies the set, it must be synchronized externally. This is typically accomplished by synchronizing on some object that naturally encapsulates the set. If no such object exists, the set should be "wrapped" using the Collections.synchronizedSet method. This is best done at creation time, to prevent accidental unsynchronized access to the HashSet instance:

Set s = Collections.synchronizedSet(new HashSet(...));

--- end HashSet ---

Vector and ArrayList Comparison

I was once asked about the difference between these two Java classes and I was not able to answer immediately. Here's what the Java API docs has to offer:

--- begin ArrayList ---

public class ArrayList
extends AbstractList
implements List, RandomAccess, Cloneable, Serializable

* (This class is roughly equivalent to Vector, except that it is unsynchronized.)

Note that this implementation is not synchronized. If multiple threads access an ArrayList instance concurrently, and at least one of the threads modifies the list structurally, it must be synchronized externally. (A structural modification is any operation that adds or deletes one or more elements, or explicitly resizes the backing array; merely setting the value of an element is not a structural modification.) This is typically accomplished by synchronizing on some object that naturally encapsulates the list. If no such object exists, the list should be "wrapped" using the Collections.synchronizedList method. This is best done at creation time, to prevent accidental unsynchronized access to the list:

List list = Collections.synchronizedList(new ArrayList(...));

--- end ArrayList ---

--- begin Vector ---

public class Vector
extends AbstractList
implements List, RandomAccess, Cloneable, Serializable

As of the Java 2 platform v1.2, this class has been retrofitted to implement List, so that it becomes a part of Java's collection framework. Unlike the new collection implementations, Vector is synchronized.

--- end Vector ---

The Iterators returned by both classes' iterator and listIterator methods are fail-fast: if the classes are structurally modified at any time after the Iterator is created, in any way except through the Iterator's own remove or add methods, the Iterator will throw a ConcurrentModificationException. Thus, in the face of concurrent modification, the Iterator fails quickly and cleanly, rather than risking arbitrary, non-deterministic behavior at an undetermined time in the future.