Enterprise Java Beans Ii

  • Uploaded by: akirank1
  • 0
  • 0
  • May 2020
  • PDF

This document was uploaded by user and they confirmed that they have the permission to share it. If you are author or own the copyright of this book, please report to us by using this DMCA report form. Report DMCA


Overview

Download & View Enterprise Java Beans Ii as PDF for free.

More details

  • Words: 1,993
  • Pages: 25
Enterprise Java Beans II CS-422 Steflik

EJB Development •

The EJB Specification define six roles that are involved in the development and deployment of EJB applications – – – – – –

Enterprise Bean Provider Application Assembler Deployer System Administrator EJB Server Provider EJB Container Provider

Enterprise Bean Provider • •

A programmer type, who codes the EJB functions done by the Enterprise Bean Provider – write a home interface for the bean – write a component interface for the bean that declares various methods required by the application – write an implementation class that implements the various business methods declared in the remote interface – write a deployment descriptor describing the resources required by the bean and various other parameters – Package the interfaces and implementation class along with the deployment descriptor into an EJB JAR file

Application Assembler •

• • •

A person with the domain knowledge and expertise to be able to gather together the beans written by several Bean Providers (including vendors) and by modifying the deployment descriptors assemble them into an applications that will represent a complete business solution. This assembly activity is usually done via GUI based tools provided by the application server OEM. The assembler should be able to understand the various interfaces declared by the Bean Providers Into pulling together the various Beans the assembler will allso collect together other components, such as JSP, HTML and graphics files.

The Deployer • •

• •

The deployer takes an assembled application and deployes it to a specific environment the deployer need to have the detail knowledge required for the specific EJB server to be used and be familiar with the development procedures for that server the deployer must map the resources required for the application onto the current infrastructure (map data sources on the data bases…) the deployer is also responsible for mapping security requirements onto the infrastructure (creating userids, password, user groups…)

System Administrator •

The System Administrator is responsible for the overall operational well being of the installation – – – –

Insure the availability of the application at all times Configure and administer the entire installation Support the networking infrastructure at the installation Create groups and users for the system to be used by the deployer while deploying the application – Monitor the application performance using tools provided by the server provider – Fine-tune the use of various resources required by the application

EJB Server Provider •

• •

A system level expert with expertise in providing low-level support services for distributed object applications and distributed transaction management. Typically an OS vendor or middleware vendor can be assumed thast the same party plays the role of the EJB Container Provider

EJB Container Provider • •

A system level expert that implements a secure, transaction enabled, and scaleable container that can be integrated with an EJB Server. The container provider is responsible for: – run-time environment for the deployed EJBs – deployment Tool for deploying EJBs on the container

Developing an Enterprise Bean •

At it simplest an EJB consists of four elements: – – – –



a home interface a component interface a bean implementation class a deployment descripter

we’ll develop a simple bean that calculates our monthly net salarybased on annual salary,pension contributions and income tax. – It will be a stateless session bean

Developing the Home Interface •





The Home Interface is responsible for managing the life-cycle operations upon a bean; creating, removing and locating the bean. The Home interface is the first point of contact that a client has with a bean A client will obtain a reference to the the bean’s Home Interface via JNDI. You will see that each bean is registered in a JNDI server that can be used at run-time to get a reference to the bean’s Home Interface Once a client has a reference to the bean’s home interface it can perform operations on the bean through this interface: these operations are: – – – – –

create a new instance or find an existing instance (local and remote) access the EJBMetaData interface (remote only) get a serializable reference to a bean instance (remote only) remove the bean instance execute home business methods (remote entity beans only)

Basic EJBHomeInterface package javax.ejb; import java.rmi.Remote; import java.rmi.RemoteExecption; public interface EJBHome extends Remote { // get a reference to the EJBMetaData object; can later be used to retrieve data about the bean public abstract EJBMetaData getEJBMetaData( ) throws RemoteExecption; // get a Handle to the home object; basically a persistent reference to the object public abstract HomeHandle getHomeHandle( ) throws RemoteExecption; // remove the bean instance ; in the case of en entity bean this is like deleting a row from the data store public abstract void remove (Object obj) throws RemoteExecption, RemoveExecption; public abstract void remove (Handle handle) throws RemoteExecption, RemoveExecption; }

Basic EJBLocalHome Interface package javax.ejb; public interface EJBLocalHome { public abstract void remove (Object obj ) throws RemoveException, EJBException; }

the SalaryHome Interface package simpleBean; public interface SalaryHome extends javax.ejb.EJBHome{ Salary create() throws java.rmi.RemoteException, javax.ejb.CreateException; }

the Component Interface package javax.ejb; import java.rmi.Remote; import java.rmi.RemoteException; public interface EJBObject extends Remote { // get a referenct to the home object public abstract EJBHome getEJBHome( ) throws RemoteException; // get a Handle to the home object public abstract Handle getHandle( ) throws RemoteException; // for entity beans: get the beans Primary Key public abstract Object getPrimaryKey( ) throws RemoteException; public abstract boolean isIdentical (EJBObject ejbobject) throws RemoteException; public abstract void remove( ) throws RemoteException, RemoveException; }

the Salary Interface package simpleBean; public interface Salary extends javax.ejb.EJBObject { double calculateSalary ( int annualSalary, int pensionContrib, double bonus) throws hava.rmi.RemoteException;

}

SalaryEJB Implementation package simpleBean; import javax.ejb.*; public class SalaryEJB implements SessionBean { public void ejbCreate( ) { } public void ejbRemove( ) { } public void ejbActivate( ) { } public void ejbPassivate( ) { } public void Ct( SessionContext ctx ) { } private static double taxRate = 28; public double calculateSalary (int annualSalary, int pensionContrib, double bonus) { double monthly = 0; monthly = annualSalary/12; monthly - monthlu - (monthly * (pensionContrib/100)); monthly = monthly - (monthly * (taxrate/100)); return monthly; } }

Limitations to the EJB Model • • • • • • • • • • •

Bean must not use read/write static fields bean can’t use threads or the Threading API bean can’t use AWT for input or output bean cannot act as a network server, by listening,accepting or multicasting on a socket bean cannot use java.io package bean can’t load a native driver bean can’t use “this” as an argument or return value bean can’t modify the class loader, stop the JVM, or change the input, output or error streams bean can’t access or modify security settings bean must not attempt to define a class in a package bean must not use the subclass and object substitution features of the serialization protocol

EJB Context •

In the SalaryBean implementation we had to invoke setSessionContext – there are similar methods required for other bean types • ex. setEntityContext for Entity Beans – each of these methods accepts a subclass of an EJBContext to provide the bean instance with information about the container - the bean’s context – The EJBContext interface: package javax.ejb; import java.security.Identity; import java.security.Principle; import java.util.Properties; import javax.transaction,UserTransaction; public interface EJBContext { public abstract Identy getCallerIdentity( ); public abstract Principal getCallerPrincipal( ); public abstract EJBHome getEJBHome( ); public abstract Properties getEnvironment( ); public abstract boolean getRollbackOnly( ) throws IllegalStateException public abstract UserTransaction getUserTransaction( ) throws IllegalStateException; public abstract boolean isCallInRole( String s); public abstract boolean isCallerInRole (Identity identity); public abstract void setRollbackOnly( ) throws IllegalStateException }

EJBContext Interface •

Additionally SessionContext and EntityContext (but not MessageDrivenContext) define: public abstract EJBLocalObject getEJBLocalObject( ) throws IllegalStateException; public abstract EJBObject getEJBObject( ) throws IllegalStateException;

Deployment Descriptors In the original EJB Specification the deployment descriptor was written as a Java object, in the EJB 1.1 Specification that was changed to be an XML Document. DTD Element

Optional

<ejb-jar>

Purpose the root element of the deployment descriptor, all other elements are children of this

<description>

Yes

textual description of the parent element, many other elements can have their own description elements



Yes

a name that the deployment tool can use to display the name

<small-icon>

Yes

relative path to a small (16x16) jpeg or GIF to be used by deployment tools



Yes

relative path to a large (32x32) jpeg or GIF to be used by deployment tools

<enterprise-beans>

The parent element that contains the declarations for all beans within this application



Yes

the parent element that contains application assembly instructions for the EJB application (includes; transaction attributes, method permissions, security roles and excluded methods)

<ejb-client-jar>

Yes

a JAR file that contains the classes necessary for a client to access the bean

An EJB Deployment Descriptor <ejb-jar> <description> Single stateless bean to calculate Monthly Salary Simple Bean <enterprise-beans> <session> <description>Simple Salary BeanSalary Bean
<ejb-name>Salary simpleBean.SalaryHome simpleBean.Salary <ejb-class>simpleBean.SalaryEJB <session-type>Stateless Container

A Salary Client import javax.ejb.*; import simpleBean.* import javax.naming.InitialContext; class SalaryClient { public static void main (String[ ] args) { try { InitialContext ctx = new InitialContext( ); Object objRef = ctx.lookup(“Salary”); SalaryHome home = (SalaryHome) javax.rmi.PortableRemoteObject.narrow(objRef, SalaryHome.class); Salary bean = home.create( ); System.out.println ( “Monthly net salary = “ + bean.calculateSalary(28000, 2, 500)); } catch (javax.namingException ne) { System.out.println(“ naming exception caught”) } catch (javax.ejb.CreateException) { System.out.println(“ EJC Ceration Exception caught); } catch (java.rmi.RemoteExecption) { System.out.println(“rmi RemoteExceprion caught”); } } }

Entity Beans ( ver 1.1) • •



Entity beans represent data in a datastore as a Java object, this usually means that the bean represents a row in a relational table. Since the bean and the database record are synonymous, any change in the bean must be synchronized with the database record; this is called persistence there are two types of Entity beans, they are differentiated by how they handle persistence – Container-Managed Persistence (CMP) • the synchronization (persistence) is handled automatically by the container

– Bean-Managed Persistence (BMP) • we manage the synchronization (persistence) in code in the bean and tell the container to keep its hands off

CMP or BMP •

One of the services offered by the EJB container is to have the container manage the persistence, at deployment time the container will generate all of the code needed to synchronize the bean with the database. – This lets the programmer focus on business logic and not have to be concerned over persistance – by using CMP the bean becomes more independent of the database, this can make them easier to re-deploy using another database



With BMP we must provide all of the SQL to manage the persistence as part of the bean, its more work but some EJB containers are not fully compliant with the EJB specification as relates to CMP; so, the only option may be to use BMP. – This may be only option when trying to use legacy databases (IBM/IMS) that are not SQL oriented – to get finer graind control than what CMP provides

Primary Keys • •



The identity of an entity bean is its primary key primary key is represented by a primary key class that is defined by the developer, this class contains everthing necessary to find the entity in the datastore for BMP the primary key class must – the primary key can be any legal value type in RMI/IIOP, must be serializable – must provide suitable implementations of the hashCode( ) and equals( ) methods – must have a unique value within the set of all beans of a particular type



for CMP these additional rules apply – key class must have a no-arguments public constructor – must be able to map the beans state to the primary key and vice-versa

Related Documents

Enterprise Java Beans
November 2019 13
Enterprise Java Beans
May 2020 11
Enterprise Java Beans
May 2020 11
Java Beans
November 2019 22
Java Beans
May 2020 20

More Documents from "Adarsh"

Javascript
May 2020 19
Ch8 Structures
April 2020 24
Ch4 Functions
April 2020 24
Cold Fusion Ii
May 2020 21