mwt unit ii

8/9/2019 mwt unit ii

1/35

Entity Beans

These are long-lived; they exist across client sessions, areshared by multiple clients, andremain alive even after a restart of the server orother failure.

Typically, an Entity EJB object represents a set of data inpersistent storage.

The EntityBean Interface

public interface javax.ejb.EntityBean

{

public abstract void ejbActivate();

public abstract void ejbLoad();

public abstract void ejbPassivate();

public abstract void ejbRemove();

public abstract void ejbStore();

public abstract void setEntityContext(EntityContext ctx);

public abstract void unsetEntityContext();

}

ejbActivate() and ejbPassivate()

These methods analogous to the methods of the same name in the SessionBean Interface. ejbPassivate() is called before an Entity object is swapped out and ejbActivate() is called

after the Entity Object is swapped in.


2/35

ejbLoad() and ejbStore()

These operations allow the Entity bean to synchronize its state with an underlyingdatabase.

Under bean managed persistence the developer has to write the coding in these methods. Under container managed persistence no coding is needed for these methods.

setEntityContext() and unsetEntityContext()

setEntityContext() passes an object that inherits from EJBContext() to the EJB instance.

public interface javax.ejb.EntityContext extends javax.ejb.EJBContext

{

public abstract EJBObject getEJBObject();

public abstract Object getPrimaryKey();

}

o The getEJBObject() method in this interface is analogous to the method of thesame name in the SessionContext interface.

o The getPrimaryKey() method returnsprimary key for this object.o In the context of entity EJBs, a primary key is an object of some user-defined type

that can be used to look up a reference to a particular Entity EJB.

Because Entity EJBs can exist across many client invocations, the Entity Bean interfaceincludes an unsetEntityContext() method that allows the bean to discard its previous

context when it is destroyed.


3/35

ejbRemove()

The container invokes the ejbRemove() method when a client has called the remove()method of the beans home interface.

ejbFindByPrimaryKey()

This is implemented only if using bean-managed persistence; in container-managedpersistence, the container will generate automatically.

The container invokes this method when a client invokes the findByPrimaryKey() method on an EJBs home interface with a particular primary key.

This key is passed to the container, which uses it to look up the object and return areference to its remote interface to the client.

Bean-Managed and Container-Managed Persistence

Entity beans are intrinsically tied to an underlying database representation. The internal state of an active Entity EJB should always be synchronized with its

underlying data after a transaction concludes.

The EJB specification permits two approaches to maintaining this synchronization:o Bean-Managed persistenceo Container-Managed persistence

Inbean-managedpersistence, the author of the bean must write necessary database callsto send the object out to persistent storage and read it back in again.

o The container calls ejbLoad() to notify the object that it should load its state infrom a database; so, here the developer has to write the code to read the state from

the database.

o Similarly, the ejbStore() notifies the object that it should write its state out to thedatabase; the developer has to write the code to write the state in the database.

In container-managed persistence, the developer has to do anything to synchronize withthe database.

oAt runtime, container will invoke ejbLoad() and ejbStore(), but the developer


4/35

A High Level View of an EJB Conversation

A High Level View of an EJB Conversation

In the EJB architecture, the client undertakes the following tasks:o Finding the beano Getting access to a beano Calling the beans methods

need not provide any implementations to these methods.

Reentrant and Non-reentrant Entity Beans

By default, Entity EJBs are non reentrant. That is, if a call is being processed and another call to the same object comes in with the

same transaction context, the program will throw a RemoteException and the call will not

be allowed.

It is possible to specify in a deployment descriptor that an Entity EJB is reentrant thatis, it will accept more than one call in the same transaction context.

The developer might choose this approach so as to allow a remote object invoked by aclient to perform callbacks to the client.

If possible, always avoid reentrant entity beans.


5/35

o Getting rid of the bean

Finding the beano EJB specification mentions two ways in which a client can find a bean

Using the Java Naming and Directory Interface Using the CORBAs Common Object Service (COS)

o JNDI API provides a uniform interface to naming and directory services.o A naming service is a service that associates a Symbolic Name with an objecto Domain Name Service is a commonly used naming service that is used to transfer

symbolic machine names into numeric IP addresses.

o Previous model of DNS, needed to maintain a file containing a list of symbolichost names along with the numeric IP addresses that they should resolve to.

o Problems in this approach: If the/etc/hosts/file developed errors, couldnt resolve symbolic names. Needed to maintain the change of addresses when new machines were

added.

If a machine did not appear in the /etc/hosts file, need to know its numericIP address to connect to it.

o Using DNS approach allows you to avoid many of these annoyances. It works asfollows:

A client makes a query to a DNS server If the DNS server knows how to resolve the address, it returns the address. If the DNS server does not know how to resolve the address, it provides

the query to another DNS server

Once the server is able to resolve the name, it returns the address to theclient. Typically, it also caches the result so that, if the request is made

again, it can be handled immediately.

o JNDI provides a uniform interface to naming services.o JNDI client uses the Servers SPI (Server Provider Interface) to access its

services.

o A Java client can use JNDI to lookup an EJB component.o The JNDI call returns a reference to an object implementing the EJB components


6/35

home interface, which can then be used to gain access to the EJB object itself.

o The other way to find an EJB component is to use CORBAs Common ObjectServices (COS) naming service.

o COS refers to a group of Services, including naming, that is provided as part ofthe CORBA services specification.

o In addition to suing COS naming directly, can make use it via JNDI.

Getting access to a beano The result of the naming lookup is a reference to an object implementing the

EJB components home interface

o A client uses the home interface to look up existing EJB instances, or to createnew ones.

o This lookup result in a reference to an object that implements the EJB objectsremote interface.

o The client uses the remote interface to interact with the EJB objects on theserver.

Calling the beans methodso After the client has a reference to an object implementing the objects remote

interface, it can then invoke the methods that the EJB object makes public in the

remote interface.

Getting rid of the beano When the client has finished with an EJB object, it can call the remove() method

on the home interface or on the objects remote interface.

o Usually remove() is called on a stateful session bean when it is no longer needed,so that the container can discard it and use the space for other beans.

o remove() method on the stateless bean can be invoked, but generally has noeffect; the server simply returns the instance to a pool.

o remove() on entity beans, would remove the underlying object from persistent


7/35

storage.

(Ex: when the customer bean is removed, the data will be deleted from the

underlying database.)

o Clients can interact with EJB either through CORBA or through RMI.

Building and Deploying EJBs

Building and Deploying EJBs

Writing the EJB:

EJB must provide three required classes:o EJB implementation Classo Home Interfaceo Remote Interface

Each EJB must provided with a deployment descriptor The deployment descriptor is serialized instance of a Java class that contains information

about how to deploy the bean.

Two flavors of deployment descriptors:o Session Descriptors apply to Session EJBso Entity Descriptors apply to Entity EJBs

A Deployment Descriptor contains information such as the following:o The name of the EJB Classo The name of the EJB Home Interfaceo The name of the EJB Remote Interfaceo ACLs of entities authorized to use each class or method.


8/35

o For Entity Beans, a list of container managed fields.o For Session Beans, a value denoting whether the bean is stateful or stateless.

Properties File may be generated, which contains environment properties that will beactivated during runtime.

Manifest File is needed to create the ejb-jar file, which is the medium used to distributeEJBs.

Name :

Enterprise-Bean:True

Deploying the EJBs:

At the deployment time, the EJB container must read the ejb-jar file, createimplementations for the home and remote interfaces.

Reads the deployment-descriptor and ensures that the bean has what it wants and ad thebeans property settings to the environment so that theyre available to the bean at

runtime.

Connecting to the EJB

The client can use either RMI or CORBA to connect to the EJB The client looks up the EJBs home interface using a naming service (JNDI or COS) Invokes a find() or create() method on the home interface to get a reference to an EJB

object. And then uses the EJB object as if it were an ordinary object.

Roles in EJB


9/35

Roles in EJB

EJB specification gives a clear description of each of these roles and their associatedresponsibilities.

a) Enterprise Bean Provider

It is the person or group that writes and packages EJBs. It might be a third-party vendor of EJB components, or it might be an information

systems programmer who writes EJBs to implement their companys business logic.

Because the container must provide transaction and network communication support, theenterprise bean provider does not need to be an expert at low-level system programming,

networking or transaction processing. The end product is an ejb-jar file, which contains the Enterprise bean, its supporting

classes, and information that describes how to deploy the bean.

b) Deployer

The deployer takes an ejb-jar file and installs it into an EJB container. The deployers task begins with the receipt of an ejb-jar file, and ends with the

installation of the ejb-jar file in the container.

This task is typically handled by the System Administrator in MIS world.

c) Application Assembler

An application assembler builds applications using EJBs classes. An MIS programmer may purchase a prepackaged set of EJBs that implement an

accounting system.

Then the programmer might use tools to customize the beans. The application assembler might also need to provide a user-interface client program. This role is roughly analogous to that of a Systems Integrator in the MIS world.


10/35

d) EJB Server Provider

An EJB Server Provider provides a server that can contain EJB containers. The EJB 1.0 specification does not describe the interface between the server and the

container, so the EJB server provider and the EJB container provider will likely be one

and the same for any given product.

The diagram shows the relationships among the EJB server, the EJB container, and theEJB bean.

An EJB server provides services to an EJB container and an EJB container providesservices to an Enterprise Java Bean.

The role of the EJB server provider is similar to that of a database system vendor.

e) EJB Container Provider

An EJB container is the world in which an EJB bean lives. The container services requests from the EJB, forwards requests from the client to the

EJB, and interacts with the EJB server.

The container provider must provide transaction support, security and persistence tobeans.

It is also responsible for running the beans and for ensuring that the beans are protectedfrom the outside world.


11/35

f) System Administrator

System Administrators are responsible for the day-to-day operation of the EJB server. Their responsibilities include keeping security information up-to-date and monitoring the

performance of the server.

Session Beans

Session Beans

These are generally tied to the lifetime of a given client session. They are relatively short-lived. The stateful session objects are created in response to a single clients request,

communicate exclusively with a single client and die when the client no longer needs

them.

A session bean is required to implement the javax.ejb.SessionBean interface.

public interface javax.ejb.SessionBean extends javax.ejb.EnterpriseBean

{

public abstract void ejbActivate();

public abstract void ejbPassivate();

public abstract void ejbRemove();


12/35

public abstract void setSessionContext(SessionContext ctx);

}

Al of the methods declared in this interface are callback methods; that is they areinvoked by the container to notify the Session EJB that some event has occurred.

ejbPassivate()

Container calls this method to swap the EJB class out to semi-persistent storage. The storage is semi-persistent because Session EJBs do not carry the same sort of

guarantee of long life as Entity EJBs do.

If the EJB container crashes or restarts, the session beans that existed before thecrash or restart are destroyed.

Session bean also have an associated timeout value; after the timeout expires, theyare destroyed.

If none of these events happens the session bean can be sapped back in at some latertime.

ejbActivate()

The ejbActivate() method is essentially the inverse of the ejbPassivate() call. The container calls this method after a session beans state has been restored from

semi-persistent storage, but before it becomes available to the outside world.

A bean can use the ejbActivate() call to restore any resources that is closed beforebeing passivated.

ejbRemove()

This callback methodin invoked by the container as a result of a client calling theremove() method of a beans home or remote interface.


13/35

The clients invocation of the remove() method notifies the container that thisparticular session bean instance should be destroyed.

setSessionContext(SessionContext ctx)

This method is called at the very beginning of a session beans life. The container passes the session bean an object that implements the SessionContext

interface.

The bean stores this object in an object variable, and can then use theSessionContext to interact with container-provided services such as security and

transaction management.

The EJBContext Interface

The SessionContext interface inherits from the EJBContext interface. The EJBContext interface is the parent interface of both the SessionContext and

EntityContext interfaces.

public interface javax.ejb.EJBContext

{

public abstract Identity getCallerIdentity();

public abstract EJBHome getEJBHome();

public abstract Properties getEnvironment();

public abstract boolean getRollbackOnly();

public abstract UserTransaction getUserTransaction();

public abstract boolean isCallerInRole(Identity role);

public abstract void setRollbackOnly();


14/35

}

getCallerIdentity()

This method is used to get a java.security.Identity object that represents the identityof the client.

It can be used in concert with isCallerInRole() to allow the EJB object to performauthorization checks before performing an operation.

getEJBHome()

This method is used to get a reference to its own home interface. This interface can be used to create or find other instances of the bean class, or to do

several other things.

getEnvironment()

This call returns the EJBs environment properties. These properties can be adjusted at deployment time.

getRollbackOnly()

EJB supports distributed transactions. If any of the players in a distributed transaction cannot continue for some reason, it

can mark the transaction as rollback only.

A rollback only transaction can never complete; it must be rolled back. A bean can use this to check the status of a transaction before attempting to

participate in it.


15/35

getUserTransaction()

In TX_BEAN_MANAGED transaction type, the bean is responsible for beginning,committing and possibly rolling back its own transactions.

If a bean has a transaction attribute of TX_BEAN_MANAGED, it can usegetUserTransaction() to gain access to the transaction.

The UserTransaction Interface

public interface javax.jtx.UserTransaction

{ public final static int STATUS_ACTIVE;

public final static int STATUS_COMMITTED;

public final static int STATUS_COMMITTING;

public final static int STATUS_MARKED_ROLLBACK;

public final static int STATUS_NO_TRANSACTION;

public final static int STATUS_PREPARING;

public final static int STATUS_PREPARED;

public final static int STATUS_ROLLEDBACK;

public final static int STATUS_ROLLING_BACK;

public final static int STATUS_UNKNOWN;

public abstract void begin();

public abstract void commit();

public abstract int getStatus();


16/35

public abstract void rollback();

public abstract void setRollbackOnly();

public abstract void setTransactionTimeout(int seconds);

}

This provides the classic begin, commit, and rollback operations getStatus() operation, which allows the caller to see the status of the transaction. Also allows the caller to set a transaction timeout, enabling the caller to set some

upper bound on the execution time of the transaction.

isCallerInRole()

This boolean method can be used to test whether the caller has assumed a given role. An EJB developer might specify several different roles that can be played by the

users of the class.

setRollbackOnly()

Calling this method sets the current transaction to rollback only.

The SessionContext Interface

public interface javax.ejb.SessionContext extends javax.ejb.EJBContext

{

public abstract EJBObject getEJBObject();


17/35

}

This contains only one method namely getEJBObject().

This method returns a reference to an EJBObject. This remote reference to an object implements the beans remote interface,

and can be used if the bean wants to pass a reference to itself to some other

entity.

EJB Container is responsible for creating objects that implement the remoteinterface; these objects act as proxies, forwarding the business method calls

to the object.

Session beans home interface provides one or more create methods. create methods are invoked by clients to create new instances of a particular EJB

object.

When a client invokes a create() method on the beans home interface, the containercreates an object of the appropriate type, calls its setSessionContext() method, and

then calls a method in EJB class called ejbCreate().

The Rules for an ejbCreate() method in Session Beans are as follows:

The method must have a void return type. The container will pass the remoteinterface back to the client.

The number and type of arguments to the ejbCreate() method must exactly matchthe number and type of arguments in the corresponding create() method declared in

the home interface.

The following steps are involved in the creation of a new Session Bean:

1.

The client calls a create() method in the beans home interface.


18/35

2. The container sets aside storage for the object and instantiates it.3. The container calls the objects setSessionContext() method.4. The container calls the ejbCreate() method whose signature matches the create()

method invoked by the client.

Stateful and Stateless Session Beans

A stateless session bean is one that doesnt keep track of any information from one method call to another essentially, a bean with no instance variables. (Ex:

CalculateInterest Bean)

Any two instances of a stateless bean are equivalent. A container can easily handle a stateless Session bean, because instances of a

stateless bean can be created and destroyed at will, without worrying about their

state at the time of their destruction.

A stateful session bean, is a bean thatchanges state during a conversation that is, abean that has instance variables. (Ex: Shopping Cart Bean)

The life cycle of a stateful bean is more complex for the container than the statelessbean.

Because, the container have to maintain the state of the stateful session bean duringswap out and swap in process.

According to the EJB specification, EJB Objects are not allowed to have staticvariables.

The SessionSynchronization Interface

public interface javax.ejb.SessionSynchronization

{

public abstract void afterBegin();


19/35

public abstract void afterCompletion(boolean committed);

public abstract void beforeCompletion();

}

A session bean can implement the SessionSynchronization interface if it wishes to benotified by the container about the state of any transaction in which it may be

involved.

Even if a Session bean does not manage its own transactions via theUserTransaction interface, it may still implement the SessionSynchronization

interface.

All of the methods in the SessionSynchronization interface are callbacks.

afterBegin()

This method notifies the bean that a transaction has begun.

beforeCompletion()

This method indicates that a transaction is nearly complete. If the bean wishes to roll back the transaction for some reason, it can call the

setRollbackOnly() method of the SessionContext interface to do so.

afterCompletion()

The container calls this method after a transaction has been completed. Its boolean argument will be set to true if the transaction was committed

successfully, and false if the transaction was rolled back.


20/35

This interface must be implemented in the stateful session bean because, the state ofinstance variables is not transactional.

That is, if the instance variables in a session bean are modified during the course ofa transaction and the transaction is then rolled back, the instance variables will not

be automatically reset to their original state prior to the transaction.

To reset the instance variables, the SessionSynchronization interface is needed anduse the afterCompletion() callback to read the state variables back out of the

database.

Note that, a stateless session bean cannot implement this interface, because, it has nostate, theres no point in trying to synchronize its state with the database.

Enterprise Beans

The EJB Home Interface

All home interfaces must extend the EJBHome Interface.


21/35

public interface javax.ejb.EJBHome extends java.rmi.Remote

{

public abstract EJBMetaData getEJBMetaData();

public abstract void remove (Handle handle);

public abstract void remove (Object primaryKey);

}

The home interface serves as the initial point of contact for a client. When the clientuses a naming service to lookup an EJB bean, the naming service returns a reference

to an object that implements the beans home interface.

The home interface requires implementation of three methods namely,getEJBMetaData(), remove(Handle handle) and remove(Object primarykey).

getEJBMetaData()

This call returns a reference to an object that implements the EJBMetaDatainterface.

public interface javax.ejb.EJBMetaData

{ public abstract EJBHome getEJBHome();

public abstract Class getHomeInterfaceClass();

public abstract Class getPrimaryKeyClass();


22/35

public abstract Class getRemoteInterfaceClass();

public abstract boolean isSession();

}

Builder tools can use the information in the EJBMetaData class to generate wrapperclasses to invoke methods on the bean.

remove(Handle handle)

This method removes an EJB object using a Handle, which is a serializablereference to a particular bean.

remove(Object primaryKey)

This method removes an EJB object by its primary key. (Only an Entity bean canhave a primary key)

The EJBHome interface does not provide any methods by which a client can create new

beans or look up existing ones. Instead, the EJB bean developer must write the method

signatures for these tasks in their own interfaces.

A client uses a naming service to look up an EJB, getting a reference to an objectthat implements its home interface to get a reference to the beans remote interface.

The EJBObject Interface


23/35

All remote interfaces extend the EJBObject interface:

public interface javax.ejb.EJBObject extends java.rmi.Remote

{

public abstract EJBHome getEJBHome();

public abstract Handle getHandle();

public abstract Object getPrimaryKey();

public abstract boolean isIdentical (EJBObject obj);

public abstract void remove();

}

getEJBHome()

This method returns a reference to an object implementing the EJB objects homeinterface.

getHandle()

This method returns a handle, which is a serializable reference to the object. The Handle interface specifies one method, getEJBObject(), which can be used to

recreate a remote reference from the handle.

getPrimaryKey()


24/35

This method returns the primary key used by the EJB object. Although it exists onthe interfaces for both session and entity beans, it really makes sense to use this

method only on an entity bean; session beans do not expose a primary key to the

outside world, and indeed need not have a primary key at all.

isIdentical()

This method provides a way to test whether two EJB object references refer to anidentical object. It is mainly useful for Entity Beans.

Two Entity beans that are from the same home interface and have the same primary key are

considered identical.

The two references in this method do not necessarily point to the same object in memory, but

all of these instances are considered to have the same identity.

remove()

This method allows the caller to remove the remote EJB object.

Note: To create a remote interface, simply create an interface that inherits from EJBObject and

add the method signatures of the methods. And there is no need to implement this remote

interface. Instead the container generates a proxy object that interacts with remote clients and

passes their method calls to the bean.


25/35

The EnterpriseBean Interface

The top-level type in the EJB Class hierarchy is the EnterpriseBean interface.

public interface javax.ejb.EnterpriseBean extends java.io.Serializable

{

}

This merely serves as a common point of ancestry for the Session and Entity beans,and requires that its subinterfaces be serializable. The transaction attribute logically

belong with the Enterprise Bean interface, even though theyre not associated

directly with it. Either a Session or an Entity Bean can be assigned any of the six

available transaction attributes.

EJB Containers

EJB Containers It is an environment in which EJB execute. Its primary role is to serve as a bufferbetween an EJB and the outside world The container is having high degree of flexibility in servicing client requests. The container provides following services:

o Support for transactionso Support for management of multiple instanceso Support for persistence


26/35

o Support for security The container generally provides support for managing and monitoring EJBs as

well as for version management.

a) Support for transactions

EJB container provides the beans with ACID properties. EJB supports transaction by having the transaction manager for begin and

commit operations.

It also provides another approach, called declarative transaction management. Here the author can specify the type of transaction support for that bean. When the bean is deployed, the container reads the deployment descriptorassociated

with that particular EJB Bean, and provides necessary transaction support

automatically.

EJB Provides six modes of transaction management

1) TX_NOT_SUPPORTED

2) TX_BEAN_MANAGED

3) TX_REQUIRED

4) TX_SUPPORTS

5) TX_REQUIRES_NEW

6) TX_MANDATORY

TX_NOT_SUPPORTED means that the bean does not support any transactions, andcant be used from within a transaction. If the client attempts to use the bean from

within a transaction, the clients transaction will remain suspended until the bean

completes its operation; the clients transaction will then resume.


27/35

In TX_BEAN_MANAGED, the bean manages its own transaction. This option is theonly type of transaction support in which the bean can directly manipulate the

transaction.

For TX_REQUIRED mode, if the client has a transaction open when it invokes thebeans method, the bean runs within the clients transaction context. Otherwise, the

container starts a new transaction.

TX_SUPPORTS means that if the client has a transaction in progress when it invokesthe beans methods, the clients transaction is used. Otherwise no new transaction is

created.

In TX_REQUIRES_NEW, the bean always starts a new transaction (even if atransaction is already in progress). If a transaction is underway, the container

temporarily suspends it until the beans transaction finishes.

For TX_MANDATORY, the bean requires that the client have a transaction openbefore the client attempts to use the bean. If no transaction is available, an error

occurs.

b) Support for Management of Multiple Instances

Normally stateless session beans are accessed by only one client. Other types of beans may be used concurrently by multiple clients The EJB container must ensure that each clients requests are serviced in a timely

manner.

To accomplish this goal, the server performs several tasks behind the screen.

i) Instance Passivation

ii) Instance Pooling

iii) Database connection pooling

iv) Preached Instances

v) Optimized method invocation


28/35

i) Instance Passivation

It is the temporary swapping of an EJB bean out to storage. If a container needs resources, it may choose to temporarily swapouta bean. Both session & entity beans can bepassivated. Passivation on session beans are performed only to free up space. But on the entity

beans, also used to synchronize its state with the underlying data store.

ii) Instance Pooling

This means that the container shares instances of EJB beans among multiple clients To increase the efficiency the container instantiate fewer copies of a given bean to

service requests. This not possible in all the cases.

Specially, the container must provide one session bean per client otherwiseconversational state cant be tracked by the containers.

iii) Database Connection Pooling

It is a strategy commonly employed in middleware applications. When a component wishes to access a database, it does not create a new database

connection; instead, it simply grabs a connection from a pool of available

connections.

This is beneficial for two reasonso It avoids the overhead of establishing a new database connectiono Maintaining an open database connection consumes resources on the database.

Connection pooling allows to limit the no. of simultaneous connections and

reduces the overhead on performance.

iv) Precached instances

This may be used when an EJB needs to load some state information from adatabase when it is created.

EJB State information can be cached in some readily available place and this speedsup the loading process.


29/35

v) Optimized method invocations

These are employed to combat overhead costs associated with remote invocation Whether the client of an EJB is a remote client or another EJB in the same

container, the APIs used to gain access to it are always the same.

A typical EJB interaction is as follows:o Use a naming service to locate the EJBs home interface o Make a call on the EJBs home interface to gain access to its remote interface. o Make calls to the business methods against the remote interface.

Contain short circuit the remote protocol, when both the beans live in the samecontainer.

c) Support for persistence

Support for persistent EJBs (Entity Beans) is not mandatory in the 1.x version ofthe EJB specification, but it will become mandatory, but it will become mandatory

in the 2.0 version.

Persistence means that the state of an object is saved to some sort of persistentstorage (typically a file or a database) allowing the object to be read in and used at

some later time, instead of being recreated each time.

The shifting of responsibility for transaction management, concurrency, securityand persistence to the container means that the bean developer can concentrate on

the business rules of his/her application.

d) Support for security

The main mechanism used in EJB security is the access control list(ACL). An ACL is a list of persons or groups that are allowed to access particular pieces of

functionality.

Only those users who are included in the ACL will be able to access the ACLprotected beans.


30/35

EJB Servers

It is a Container Container it contains the EJB container It is responsible for providing the container with lower-level services such asnetwork

connectivity.

The EJB Specification 1.0 did not outline the exact interface between the EJB containerand the EJB server. So, interface is currently left up to the individual vendor.

At an abstract level, though, the relationship between the container and server is such thatthe server will provide the container with low-level implementation of the services

required by the container.

The layered architecture is shown below:

Overview of EJBs Software Architecture

Overview of EJBs Software Architecture

The diagram presents a high-level view of the EJB architecture, showing the various

relationships between the various components.


31/35

This illustrates theKey Features of theEJB Architecture

EJB bean exists within the container Client never communicates directly with the EJB bean;

rather it talks to the bean through itshome interface and itsremote interface, both of

which are provided by the container.

EJB server does not take part in the logical conversationbetween client and EJB bean. Actually, the server is doing a lot of work behind the

scenes. Remembers the must handle requests for the container, and feed the

container incoming client requests. And the bean and the client not directly access

the server all access is performed against the container.

EJB Logical Architecture

EJB Logical Architecture

A EJB system is logically a three-tier

system

The three tiers are as follows:

a)The Client

b)The EJB Server

c)The Database (or other persistent

store)


32/35

This is a logical architecture because

these tiers dont necessarily have to reside on three different machines.

For example,

a)The EJB server and the databasemight reside on the same machine, when the EJB server includes

built-in functionalities for persistent storage.

b)The client and the EJB server

might reside on the same machine, when an EJB bean makes a call to

another bean in the same container. The caller bean is acting as a

client here.

c)These two cases can be combined

to have all the tiers in a single machine.

EJBs role in each of these tiers are:

a)A program on the client side

makes call to remote EJBs. The client needs to know how to find the

EJB server and how to interact with the objects that reside on the

EJB server.

b)The EJB components live in the

middle tier. The EJB objects reside inside an EJB container, which

in turn resides in an EJB server.

c)EJB can access the database

themselves, typically via Java Database connecting (JDBC), or they

can allow the container to handle their data storage needs for them.


33/35

EJBs Role

EJBs Role

-[if !supportLists]-->1. EJB Specifies an execution environment

Thecontainer is responsible for

providing services to EJB.

An EJB is a Java class that implements

either the Session Bean or theEntity Bean Interface.

The container provides services such as

support for transactions, support for persistence, and management of

multiple instances of a given bean.

The container does not allow the bean to

be accessed directly from the client; rather, the container provides aproxy

object for each bean.

This approach gives the container a high

degree of freedom in managing the beans and insulates the bean themselvesfrom the outside world.

-[if !supportLists]-->2. EJB exists in the middle-tier

EJB, like other middle-tier components

are used to encapsulatebusiness rules.

A typical EJB consists ofmethods that

encapsulatebusiness logic.

Aremote client can invoke these

methods, which typically result in the updating of a database.

-[if !supportLists]-->3. EJB supports transaction processing

An EJB container must support

transactions

When the bean is deployed, the container

reads this information and provides necessary support.

Possible types of transaction support:


34/35

i. Requiring that the client

provide an open transaction context.

ii. Requiring that the container

start a new transaction when the bean is invoked.

iii. Requiring that the bean be

allowed to manage its own transaction.

-[if !supportLists]-->4. EJB can maintain state

CGI scripts are handy because they

work against a well-defined interface.

A CGI application has no built-in

mechanism to store state information.

Each invocation of a CGI application is

therefore a fresh start.

If the developer would like to build an

application with several screens that handles complex input, CGI is not

suitable.

EJB can maintain state across several

method invocations.

The EJB container keeps track of any

state information that a bean needs.

Stateless bean can also be created.

-[if !supportLists]-->5. EJB can maintain state

CGI scripts are handy because they

work against a well-defined interface.

A CGI application has no built-in

mechanism to store state information.

Each invocation of a CGI application is

therefore a fresh start.

If the developer would like to build an

application with several screens that handles complex input, CGI is not

suitable.


35/35

EJB can maintain state across several

method invocations.

The EJB container keeps track of any

state information that a bean needs.

Stateless bean can also be created.

-[if !supportLists]-->6. EJB is simple

The EJB container handles all the

responsibilities and runs on the server environment. So, developer work load

is much reduced.

Even the developer need not worry about

the multithreaded code, because the container handles concurrent requests.

Because the bean is a middle-tier object,

an EJB developer does not need to create any user interface logic.

The developer must write only the code

necessary to implement theapplications business rules andmanage its data.

EJB brings together several trends in

computing:

i. Transaction processing

ii. Persistent storage of objects

iii. Platform independence

iv. Multithreaded architecture

EJB provides all of these features in a

straight forward, portable, easy-to-use framework.

Because an EJB bean can run in any

EJB container, the potential exists for a new market in business-logic

middleware.

Write Once, Run Anywhere.

mwt unit ii

Documents

Transcript of mwt unit ii