EJB

Component Characteristics An enterprise Bean typically 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 at deployment time by editing its environment entries.

Components Various metadata, such as a transaction and security attributes, are separate from the enterprise Bean class. This allows the metadata to be managed by tools during application assembly or deployment (or both). Client access is mediated by the Container in which the enterprise Bean is deployed.

Components An enterprise Bean can be included in an assembled application without requiring source code changes or recompilation of the enterprise Bean. A client view of an enterprise Bean is defined by the Bean Provider. The client view can be manually defined by the Bean developer, or generated automatically by application development tools. The client view is unaffected by the container and server in which the Bean is deployed. This ensures that both the Beans and their clients can be deployed in multiple execution environments without changes or recompilation.

EJB use Tier 1: Client Tier 2: EJB server –EJB container (provides transaction management, security, remote connectivity, concurrency, life cycle management) Enterprise beans Tier 3: Databases, legacy code

Session beans Model business processes such as checking, canceling, shipping orders. Run by code on a remote client: locates bean through JNDI (Java Naming and Directory Interface) EJB container creates copy of session bean on client

Session Beans Four pieces of code you need to write –remote interface: methods client can use –home interface: used to create remote copy –session bean: does most of the work –client code that calls the bean

Remote Interface public interface Hello extends EJBObject { String sayHello() throws RemoteException; Client will call only one method Follow RMI rules: must throw RemoteException, return types primitive or...

Home Interface public interface HelloHome extends EJBHome { Hello create(String str) throws RemoteException, …; }

Session Bean Implementation public class HelloEJB implements SessionBean { String str; public ejbCreate(String str) {this.str = str; } public String sayHello() throws RemoteException {return str;}…}

Session bean Also: ejbRemove(), ejbActivate(), ejbPassivate() ejbCreate corresponds to create method in home interface

Client: main method Context ic = new InitialContext(); Object obj = ic.lookup(“helloapp/Hello”); HelloHome hhome = (HelloHome) PortableRemoteObject.narrow (obj, HelloHome.class);

Client: main method Hello hobj = hhome.create(“Hello World”); String hstr = hobj.sayHello(); System.out.println(hstr);

Entity Beans Persistent: can be container managed using deployment descriptor container also provides transaction management –Remote interface –Home interface –Entity bean class

Example Tier 1: WebBrowser: Applet Tier 2: –WebServer: Servlet –EJB Server EJB Container –Product Entity Bean –Order Entity Bean –Customer Entity Bean Tier 3: Data Base Server

Entity Bean Class business methods create methods remove methods finder methods load and store methods activation, passivation methods

EJB Session beans –represents a client in the server. Client calls methods (e.g., enterOrder). Is transient: terminates when client terminates. Entity beans –represents a business object (persistent). –Persistence can be beans or container managed

Enterprise Java Beans (EJB) and Aspectual components EJB: a hot Java component technology from SUN/IBM Aspectual components: a conceptual tool for the design of enterprise Java beans (and other components)

Enterprise JavaBeans (EJB) Addresses aspectual decomposition. An enterprise Bean provider usually does not program transactions, concurrency, security, distribution and other services into the enterprise Beans. An enterprise Bean provider relies on an EJB container provider for these services.

EJB Beans Containers: to manage and adapt the beans. Intercept messages sent to beans and can execute additional code. Similar to reimplementation of expected interface in aspectual component.

Aspectual components for EJB design/implementation Use ACs to model transactions, concurrency, security, distribution and other system level issues. Translate ACs to deployment descriptors (manually, or by tool). Use ACs to model beans in reusable form. Generate (manually or by tool) Java classes from ACs and connectors.

Example: Use AC for EJB persistence As an example we consider how persistence is handled by EJB containers. The deployment descriptor of a bean contains an instance variable ContainerManagedFields defining the instance variables that need to be read or written. This will be used to generate the database access code automatically and protects the bean from database specific code.

Aspectual component: Persistence component Persistence { PerMem p; participant Source { expect Target[] targets; expect void writeOp();} // for all targets:writeOp participant Target expect void writeOp(); replace void writeOp() { // write to persistent memory p expected();}}

Deployment connector PersistenceConn1 { ClassGraph g = ; // from Company to * Company is Persistence.Source; Nodes(g) is Persistence.Target; with {writeOp = write*}; // must be the same writeOp for both // Source and Target }

Generate deployment descriptor Connector contains information about ContainerManagedFields Connector localizes information; it is not spread through several classes

Discussion of session bean and entity bean distinction interesting modeling is done in session beans; initially only session beans entity beans: dumb objects? Enterprise beans components are intended to be relatively coarse-grained business objects (e.g. purchase order, employee record). Fine-grained objects (e.g. line item on a purchase order, employee’s address) should not be modeled as enterprise bean components.

Ejb and aop deployment descriptors :=: APPC session beans :=: “session” APPC –session beans are extensions of clients entity beans :=: “base” participants –key participants regular classes :=: define through APPC

Terminology Building block = BB Participants (classes at basic level) = BB of type 1 APPC = BB of type 2 = consisting of set of generic BB of type 1. Connectors = map generic BB

AOP components = building blocks type 1 whatever does not fit into one building block of type 1 is expressed as one building block type 2 that consists of a set of generic building blocks of type 1. generic building blocks of a building block of type 2 are mapped to building blocks of type 1.

Generic BB A building block with holes

AOP Properties of mapping –one generic building block is mapped to one or more building blocks –building blocks may have parts. One part of generic building block is mapped to one or more parts of corresponding generic building block.

Exceptions in EJB An application exception is an exception defined in the throws clause of a method of the enterprise Bean’s home and remote interface, other than the java.rmi.RemoteException. An enterprise bean business method may encounter various system exceptions or errors that prevent the method from successful completion.

Examples Application exception: account has insufficient balance System exception: failure to obtain a database connection, JNDI exceptions, unexpected RemoteException from invocation of other enterprise beans, unexpected RuntimeException, JVM errors, etc.

Use of application level exceptions Application exceptions are intended to be handled by the client, and not by the system administrator. They should be used only for reporting business logic exceptions, not for reporting system level problems.

Application exception Because an application exception does not automatically result in marking the transaction for rollback, the Bean Provider must do one of the following to ensure data integrity before throwing an application exception from an enterprise bean instance: –no loss of data integrity –mark for rollback before throwing application exception, prevents commit

System exception guidelines If the bean method encounters a RuntimeException or error, it should simply propagate the error from the bean method to the Container (i.e. the bean method does not have to catchthe exception). Any other unexpected error conditions should be reported using the javax.ejb.EJBException.

What the container does catches a non-application exception, logs it (which can result in alerting the System Administrator), and throws the java.rmi.RemoteException (or subclass thereof) to the client.

What container does The Bean Provider can rely on the Container to perform to following tasks when catching a non-application exception: –The transaction in which the bean method participated will be rolled back. –No other method will be invoked on an instance that threw a non-application exception.

What container does This means that the Bean Provider does not have to perform any cleanup actions before throwing a non-application exception. It is the Container that is responsible for the cleanup.

AOP and Law of Demeter ? Only talk to friends