Java_J2EE_Job_Interview_Companion

160	Enterprise – RMI

RMI runtime steps (as shown in the diagram above) involved are:

Step 1: Start RMI registry and then the RMI server. Bind the remote objects to the RMI registry. Step 2: The client process will look up the remote object from the RMI registry.

Step 3: The lookup will return the stub to the client process from the server process.

Step 4: The client process will invoke method calls on the stub. The stub calls the skeleton on the server process through the RMI reference manager.

Step 5: The skeleton will execute the actual method call on the remote object and return the result or an exception to the client process via the RMI reference manager and the stub.

Q 53: What is a remote object? Why should we extend UnicastRemoteObject? SF FAQ

A 53: A remote object is one whose methods can be invoked from another JVM (i.e. another process). A remote object class must implement the Remote interface. A RMI Server is an application that creates a number of remote objects.

An RMI Server is responsible for

Creating an instance of the remote object (e.g. CarImpl instance = new CarImpl()).

Exporting the remote object.

Binding the instance of the remote object to the RMI registry.

By exporting a remote object you make it available to accept incoming calls from the client. You can export the remote object by either extending the java.rmi.server.UnicastRemoteObject or if your class is already extending another class then you can use the static method

UnicastRemoteObject.exportObject (this);

If the UnicastRemoteObject is not extended (i.e. if you use UnicastRemoteObject.exportObject(…) then the implementation class is responsible for the correct implementations of the hashCode(), equals() and toString() methods. A remote object is registered in the RMI registry using:

Naming.rebind(String serviceName, Remote remoteObj);

Remote Objects

java.rmi.Remote	Remote interface	java.rmi.server.RemoteServer
	eg: public interface Car extends Remote{}
	Implementation of Remote interface	java.rmi.server.UnicastRemoteObject
	eg: public class CarImpl extends UnicastRemoteObject implements Car{}
	Compile Car &
	CarImpl

use rmic to generate stubs & skeletons rmic -d /classes CarImpl

					d	g
				te		e
						n
			a				er
		r						at
	e								e
n										d
e
g

instantiated

	stub class	skeleton class
	instantiated	instantiated
Client Object	stub Object	skeleton Object	remote Object
instances	instances	instances	instances

		Enterprise – RMI		161
Q 54: What is the difference between RMI and CORBA? SF
A 54:
	RMI		CORBA
	Java only solution. The interfaces,		CORBA was made specifically for interoperability among various
	implementations and the clients are all written		languages. For example the server could be written in C++ and the
	in Java.		business logic can be in Java and the client can be written in COBOL.
	RMI allows dynamic loading of classes at		In a CORBA environment with multi-language support it is not possible to
	runtime.		have dynamic loading.

Q 55: What are the services provided by the RMI Object? SF

A 55: In addition to its remote object architecture, RMI provides some basic object services, which can be used in a distributed application. These services are

Object naming/registry service: RMI servers can provide services to clients by registering one or more remote objects with its local RMI registry.

Object activation service: It provides a way for server (i.e. remote) objects to be started on an as-needed basis. Without the remote activation service, a server object has to be registered with the RMI registry service.

Distributed garbage collection: It is an automatic process where an object, which has no further remote references, becomes a candidate for garbage collection.

Q 56: What are the differences between RMI and a socket? SF

A 56:

	Socket			RMI
	A socket is a transport mechanism. Sockets are like			RMI uses sockets. RMI is object oriented. Methods can be
	applying procedural networking to object oriented			invoked on the remote objects running on a separate JVM.
	environment.
	Sockets-based network programming can be laborious.			RMI provides a convenient abstraction over raw sockets. Can
				send and receive any valid Java object utilizing underlying
				object serialization without having to worry about using data
				streams.
Q 57: How will you pass parameters in RMI?
		SF
A 57:

Primitive types are passed by value (e.g. int, char, boolean etc).

References to remote objects (i.e. objects which implement the Remote interface) are passed as remote references that allow the client process to invoke methods on the remote objects.

Non-remote objects are passed by value using object serialization. These objects should allow them to be serialized by implementing the java.io.Serializable interface.

Note: The client process initiates the invocation of the remote method by calling the method on the stub. The stub (client side proxy of the remote object) has a reference to the remote object and forwards the call to the skeleton (server side proxy of the remote object) through the reference manager by marshaling the method arguments. During Marshaling each object is checked to determine whether it implements java.rmi.Remote interface. If it does then the remote reference is used as the Marshaled data otherwise the object is serialized into byte streams and sent to the remote process where it is deserialized into a copy of the local object. The skeleton converts this request from the stub into the appropriate method call on the actual remote object by unmarshaling the method arguments into local stubs on the server (if they are remote reference) or into local copy (if they are sent as serialized objects).

Q 58: What is HTTP tunneling or how do you make RMI calls across firewalls? SFSE

A 58: RMI transport layer generally opens direct sockets to the server. Many Intranets have firewalls that do not allow this. To get through the firewall an RMI call can be embedded within the firewall-trusted HTTP protocol. To get across firewalls, RMI makes use of HTTP tunneling by encapsulating RMI calls within an HTTP POST request.

	162	Enterprise – RMI
		HTTP tunnelling
	Proxy Server	Web Server
		on port 80
	HTTP encapsulated RMI call	call forwarded by CGI script
	RMI Client	RMI Server
	Firewall	Firewall

When a firewall proxy server can forward HTTP requests only to a well-known HTTP port: The firewall proxy server will forward the request to a HTTP server listening on port 80, and a CGI script will be executed to forward the call to the target RMI server port on the same machine.

			HTTP tunneling
	Client			Web	Servlet Container
	applets	I	Firewall
	servlets	n		Server	Servlet
	JMS client	t
		e
		r
		n
		e			Business Service
		t			RMI
				company	EJB
				network	Corba

The disadvantages of HTTP tunneling are performance degradation, prevents RMI applications from using callbacks, CGI script will redirect any incoming request to any port, which is a security loophole, RMI calls cannot be multiplexed through a single connection since HTTP tunneling follows a request/response protocol etc.

Q 59: Why use RMI when we can achieve the same benefits from EJB? SF

A 59: EJBs are distributed components, which use the RMI framework for object distribution. An EJB application server provides more services like transaction management, object pooling, database connection-pooling etc, which RMI does not provide. These extra services that are provided by the EJB server simplify the programming effort at the cost of performance overhead compared to plain RMI. So if performance is important then pure RMI may be a better solution (or under extreme situations Sockets can offer better performance than RMI).

Note: The decision to go for RMI or EJB or Sockets should be based on requirements such as maintainability, ease of coding, extensibility, performance, scalability, availability of application servers, business requirements etc.

Tech Tip #5:

Q. How do you pass a parameter to your JVM?

As JVM arguments:

$> java MyProgram -DallowCache=true

alternatively in your code:
System.setProperty(“allowCache”, Boolean.TRUE);	// to set the value
System.getProperty(“allowCache”);	// to get the value

Enterprise – EJB 2.x

163

Enterprise – EJB 2.x

There are various persistence mechanisms available like EJB 2.x, Object-to-Relational (O/R) mapping tools like Hibernate, JDBC and EJB 3.0 (new kid on the block) etc. You will have to evaluate the products based on the application you are building because each product has its strengths and weaknesses. You will find yourself trading ease of use for scalability, standards with support for special features like stored procedures, etc. Some factors will be more important to you than for others. There is no one size fits all solution. Let’s compare some of the persistence products:

EJB 2.x		EJB 3.0		Hibernate		JDBC
PROS:		PROS:		PROS:		PROS:
Security is provided for free		A lot less artifacts than EJB		Simple to write CRUD		You have complete control
for accessing the EJB.		2.x. Makes use of annotations		(create, retrieve, update,		over	the	persistence
Provides declarative		or attributes based		delete) operations.		because this is the building
		programming.		No container or application		blocks of nearly all other
transactions.		Narrows the gap between EJB				persistence		technologies in
EJBs are pooled and				server is required and can be		Java.
		2.x and O/R mapping.		plugged into an existing		Can call Stored Procedures.
cached. EJB life cycles are		Do support OO concepts like		container.
managed by the container.				Tools are available to simplify		Can	manipulate relatively
		inheritance.
Has remote access				mapping relational data to		large data sets.
capabilities and can be				objects and quick to develop.
clustered for scalability.

Cons:		Cons:			Cons:				Cons:
Need to understand the		As of writing, It is still evolving.			Little or no capabilities for				You will have to write a lot
intricacies like rolling back					remote access and				of code to perform a little.
a transaction, granularity					distributability.				Easy to make mistakes in
etc, infrastructures like					Mapping schemas can be				properly		managing
session facades, business									connections and can cause
delegates, value objects etc					tedious	and	O/R	mapping	out of cursors issues.
and strategies like lazy					has its tricks like using lazy				Harder to maintain because
loading, dirty marker etc.					initialization,		eager	loading
EJBs use lots of resources					etc. What works for one may				changes in schemas can
					not work for another.				cause lot of changes to your
and have lots of artifacts.					Limited clustering				code.
Does not support OO									Records need to be locked
					capabilities.
concepts like inheritance.					Large data sets can still				manually (e.g. select for
									update).
					cause memory issues.
					Support for security at a
					database level only and no
					support	for	role	based
					security without any add on
					APIs like Aspect			Oriented
					Programming etc.
As a rule of thumb, suitable		As a rule of thumb, suitable for			Suitable for records in use				Where	possible	stay away
for distributed and	clustered	distributed	and	clustered	between 100 and 5000. Watch				from using JDBC unless you
applications, which is heavily		applications,	which	is heavily	out for memory issues, when				have compelling		reason to
transaction based.	Records	transaction based.		Records in	using large data sets.				use it for batch jobs where
in use say between 1 and 50.		use say between 1 and 100.							large amount of data need to
									be transferred, records in use
									greater	than 5000, required
									to use	Stored	Procedures
									etc.

The stateless session beans and message driven beans have wider acceptance in EJB 2.x compared to stateful session beans and entity beans. Refer Emerging Technologies/Frameworks section for Hibernate and EJB 3.0.

Q 60: What is the role of EJB 2.x in J2EE? SF

A 60: EJB 2.x (Enterprise JavaBeans) is widely adopted server side component architecture for J2EE.

EJB is a remote, distributed multi-tier system and supports protocols like JRMP, IIOP, and HTTP etc.

It enables rapid development of reusable, versatile, and portable business components (i.e. across middleware), which are transactional and scalable.

164	Enterprise – EJB 2.x

EJB is a specification for J2EE servers. EJB components contain only business logic and system level programming and services like transactions, security, instance pooling, multi-threading, persistence etc are managed by the EJB Container and hence simplify the programming effort.

Message driven EJBs have support for asynchronous communication.

Note: Having said that EJB 2.x is a widely adopted server side component, EJB 3.0 is taking ease of development very seriously and has adjusted its model to offer the POJO (Plain Old Java Object) persistence and the new O/R mapping model based on Hibernate. In EJB 3.0, all kinds of enterprise beans are just POJOs. EJB 3.0 extensively uses Java annotations, which replaces excessive XML based configuration files and eliminates the need for the rigid component model used in EJB 1.x, 2.x. Annotations can be used to define the bean’s business interface, O/R mapping information, resource references etc. Refer Q18 in Emerging Technologies/Frameworks section. So, for future developments look out for EJB 3.0 and/or Hibernate framework. Refer Q14 – Q16 in Emerging Technologies/Frameworks section for discussion on Hibernate framework.

EJB - Big Picture

Other J2EE

C++ application

Messaging

Java Applet,

HTTP Client

Systems

Client

Java stand-alone application

(eg: Browser, Wireless etc)

HTTP

Web Services

(SOAP, UDDI, WSDL, ebXML)

	Firewall
J2EE Server			JSP
Servlets	messaging		(use JavaBeans)
(use JavaBeans)	IIOP	RMI/IIOP	Servlets
	Business Delegate
	(use JavaBeans)		(use JavaBeans)
EJB Container (Enterprise Java Beans are deployed)				SystemLevel Services like transaction, Security etc are provided by the container
EJB Session Bean	EJB Message Driven Bean	EJB Session Bean
EJB Entity Bean	EJB Session Bean	EJB Session Bean
BusinessprovidedLogicby the developerthroughEJB
SQL	SQL (fast Lane Reader)		Web Services
	Connectors (JCA)
		(SOAP, UDDI, WSDL, ebXML)
	proprietary protocol
	Legacy System,	Message Oriented	Other J2EE
			Systems
Database	ERP System etc	Middleware Topic

Q 61: What is the difference between EJB and JavaBeans? SF FAQ

A 61: Both EJBs and JavaBeans have very similar names but this is where the similarities end.

JavaBeans	Enterprise JavaBeans (EJB)
The components built based on JavaBeans live in a single	The Enterprise JavaBeans are non-visual distributable
local JVM (i.e. address space) and can be either visual	components, which can live across multiple JVMs (i.e. address
(e.g. GUI components like Button, List etc) or non-visual at	spaces).
runtime.
No explicit support exists for services like transactions etc.	EJBs can be transactional and the EJB servers provide
	transactional support.
JavaBeans are fine-grained components, which can be	EJBs are coarse-grained components that can be deployed as
used to assemble coarse-grained components or an	is or assembled with other components into larger
application.	applications. EJBs must be deployed in a container that
	provides services like instance pooling, multi-threading,
	security, life-cycle management, transactions etc
Must conform to JavaBeans specification.	Must conform to EJB specification.

Enterprise – EJB 2.x

165

Q 62: Explain EJB architecture? SF

A 62:

				E J B A rc h ite c tu re
			E J B S e rv e r
ClientEJB aloneStandJSP,Servlet,(eg etc)Appletapplication,			E J B C o n ta in e r				D a ta b a s e S e rv e r
						E n te rp ris e Ja v a B e a n s
		sy n c h ro n o u s	H o m e /L o c a lH o m e		H o m e O b je c t /	S e s s io n B e a n s
			In te rfa c e	L o c a l H o m e O b je c t
						sta te fu l / s ta te le ss
							E n tity B e a n s
		sy n c h ro n o u s	R e m o te /L o c a l		E J B O b je c t /		C M P / B M P
			In te rfa c e		E J B L o c a lO b je c t
						E n te rp ris e Ja v a B e a n s
J M S						M e s s a g e -D riv e n
M e s s a g e
			J M S M e s s a g e				B e a n s
P ro d u c e r		A sy n c h ro n o u s
(e .g .			L is te n e r In te rfa c e
p u b lis h	to
a T o p ic o r
se n d to a
Q u e u e )			E n te rp ris e S e rv ic e s a n d A P I
			JN D I	JM S	T ra n s a ctio n s	S e c u rity	P e rs is te n c e
			E J B C o n ta in e r

C lie n t

g

p

u

B

k

o

U

o

T

L

S

.

t

1

e

g

ke

.

2

vo

. In

()

3

te

ea

()

cr

nd

)

fi

e(

ov

m

b

re

e stu

9

on

th

e

.

i

nter

pr

nv

oke

ise

m e

b

ean

etH

thods

li

orse

P ow

ke

er()

J N D I

H o m e In te rfa c e

R e m o te In te rfa c e

							&
						t
					p
				e
			rc
		te
	in
.
4

H o m e O b je c t

					t &
5new. instance				ce	p
			te	r
	6	.	in

					ly
			p
		p
a								s
							ice
				s	e	r	v
			ly
		p
a	p

D e p lo ym e n t d e sc rip to r

-B e a n d e fin itio n

-T ra n s a ctio n

-S e c u rity e tc

8 . b e a n					m e
	life -c y c le						th o d s
	e jb	C re a te ()o r
	e jb F in d ()
									ds
								tho
						ss me
				ine				etc
			us				r()
		n b
	ea					we
. b					o
10				eP
		tH	ors
	ge

E J B O B je c t

7 .
R e fe r	E JB C o n te xt

e n te rp ris e

b e a n in s ta n c e

S a m p le C o d e :

C o n te x t in itia lC tx = n e w In itia lC o n te x t(); //In itia liz e th e J N D I c o n te x t. i.e . e n try p o in t.

C a rH o m e h o m e O b je c t = (C a rH o m e ) in itia lC tx .lo o k u p (e jb /M y E jb ); // S te p s 1 & 2 in th e a b o v e d ia g ra m C a r c a rO b je c t = h o m e O b je c t.c re a te (); // S te p s 3 - 8

c a rO b je c t .g e tH o rs e P o w e r(); // S te p s 9 - 1 0

N o te : A n E J B c lie n t s h o u ld n e v e r a c c e s s a n e n te rp ris e b e a n in s ta n c e d ire c tly . A n y a c c e s s is d o n e th ro u g h th e c o n ta in e r g e n e ra te d c la s s e s , w h ic h in tu rn in v o k e e n te rp ris e b e a n in s ta n c e ’s m e th o d s . T h e c o n ta in e r g e n e ra te d

c la s s e s in te rc e p t th e re q u e s t a n d a p p ly s e rv ic e s lik e tra n s a c tio n , s e c u rity e tc p rio r to in v o k in g th e a c tu a l m e th o d o n th e e n te rp ris e b e a n in s ta n c e .

EJB Container: EJBs are software components, which run in an environment called an EJB container. An EJB cannot function outside an EJB Container. The EJB container hosts and manages an Enterprise JavaBean in a similar manner that a Web container hosts a servlet or a Web browser hosts a Java Applet. The EJB container manages the following services so that the developer can concentrate on writing the business logic:

Transactions (refer Q71 – Q75 in Enterprise section)

Persistence

EJB instance pooling

Security (refer Q81 in Enterprise section)

Concurrent access (or multi-threading)

Remote access

Design pattern: EJBs use the proxy design pattern to make remote invocation (i.e. remote proxy) and to add container managed services like security and transaction demarcation. Refer Q11 in “How would you about…” section for a more detailed discussion on proxy design pattern and dynamic proxies.

EJBContext: Every bean obtains an EJBContext object, which is a reference directly to the container. The EJB can request information about its environment like the status of a transaction, a remote reference to itself (an EJB cannot use ‘this’ to reference itself) etc.

166	Enterprise – EJB 2.x

Deployment Descriptor: The container handles all the above mentioned services declaratively for an EJB based on the XML deployment descriptor (ejb-jar.xml). When an EJB is deployed into a container the deployment descriptor is read to find out how these services are handled. Refer to the J2EE deployment structure diagram in Q6 in Enterprise section.

EJB: The EJB architecture defines 3 distinct types of Enterprise JavaBeans.

Session beans.

Entity beans.

Message-driven beans.

The session and entity beans are invoked synchronously by the client and message driven beans are invoked asynchronously by a message container such as a Queue or a Topic. Let’s look at some of the EJB container services in a bit more detail:

Instance pooling

EJB instance pooling

Client Application		EJB Server
home	1. create()	EJB	2.
stub		Home
			n
			e
			wI
				n
				s
				t
				a
				n
				c
				e
				(	bean instance pool
				)
	4. return EJB Object reference			EJB	3. assign an instance
		to client		Object	to EJB Object

Note:

1 The client looks up the stub from the jndi and invokes the create() method on the EJBHome object. CarHome homeObject = (CarHome) initialCtx.lookup(ejb/MyEjb);

Car carObject = homeObject.create()

2-3 The EJBHome creates an EJBObject by invoking newInstance() and assigns a bean instance from the pool to the EJBObject. Now the assigned bean instance becomes in ready state from the pooled state.

4 Now the EJBObject can service client requests and reference is returned to the client. carObject .getHorsePower();

Finally once the client is finshed with EJBObject reference the bean instance is returned back to the pool to serve other clients

The above diagram shows how the EJB instances are pooled and assigned to EJB Object and then returned to the pool. Let’s look at in detail for different types of EJBs.

stateless session & entity bean pooling

	EJB Server
Client stub 1	EJB	A
	Object
		bean instance pool
Client stub 2	EJB	C	D
	Object	B
	EJB Server
Client stub 1	EJB	B
	Object
		bean instance pool
Client stub 2	EJB	C	D
	Object	A

Notes:

The diagram on the left shows that since the stateless session beans and entity beans do not maintain any client state the bean instance A was firstly allocated to client stub 1 and later on allocated to client stub 2. So if there are 1000 concurrent clients then 30 instances of bean can serve them by taking turns.

This behavior is not possible with regards to stateful session beans which maintain the client state. So there will be a dedicated instance of the bean for each client stub. So if there are 1000 clients then there will be 1000 instances of beans. So how do we conserve memory. This is done by activation and passivation. Passivation is the process where the bean instance is serialized into a persistent store when not used to conserve memory and Activation is the process where the serialized bean instance is de-serialized back into memory to serve client request. This process affects performance.

Enterprise – EJB 2.x

167

From the diagrams it is clear that bean instances can be reused for all the bean types except for the stateful session bean where the client state is maintained. So we need a dedicated stateful session bean for each client.

Message Driven Bean (MDB) pooling

JMS Client 1

JMS Client 2

JMS Client 3

	EJB Server
msg X	EJB		MDB-1 bean instance pool
for Q1		A	for queue Q1
	Object
			B	C
msg Z for Q2	EJB	B
	Object		MDB-2 bean instance pool
			for queue Q2	C
msg y for Q2	EJB	A
	Object

Note: MDBs are like stateless session beans,

The instance pools are created for each MDB and within each pool multiple instances are created. In terms of number of instances created in each pool are very similar to stateless session beans or entity beans (i.e. 3 instances of MDB-1 for queue Q1 instance pool can serve 10 JMS clients for queue Q1).

Concurrent access

The session beans do not support concurrent access. The stateful session beans are exclusively for a client so there is no concurrent access. The stateless session beans do not maintain any state. It does not make any sense to have concurrent access. The entity beans represent data that is in the database table, which is shared between the clients. So to make concurrent access possible the EJB container need to protect the data while allowing many clients simultaneous access. When you try to share distributed objects you may have the following problem:

If 2 clients are using the same EJBObject, how do you keep one client from writing over the changes of the other? Say for example

Client-1 reads a value x= 5

Client-2 modifies the value to x=7

Now the client-1’s value is invalid.

The entity bean addresses this by prohibiting concurrent access to bean instances. Which means several clients can be connected to one EJBObject but only one client can access the EJB instance at a time.

Persistence

Entity beans basically represent the data in a relational database. An Entity Bean is responsible for keeping its state in sync with the database.

Entity beans representing data in the database

instance for id = 1001

AccountBean

id = 1001 (primary-key) bsb = 1234

account_number = 98765432

instance for id = 1002

AccountBean

id = 1002 (primary-key) bsb = 1234

account_number = 12345678

Account Table

id bsb account_num

	1001	1234	98765432
	1002	1234	12345678

database

168	Enterprise – EJB 2.x

Container-managed persistence (CMP) - The container is responsible for saving the bean’s state with the help of object-relational mapping tools.

Bean-managed persistence (BMP) – The entity bean is responsible for saving its own state.

If entity beans performance is of concern then there are other persistence technologies and frameworks like JDBC, JDO, Hibernate, OJB and Oracle TopLink (commercial product).

Q 63: What are the different kinds of enterprise beans? SF FAQ

A 63:

Session Bean: is a non-persistent object that implements some business logic running on the server. Session beans do not survive system shut down. There are two types of session beans

Stateless session beans (i.e. each session bean can be reused by multiple EJB clients).

Stateful session beans (i.e. each session bean is associated with one EJB client).

Entity Bean: is a persistent object that represents object views of the data, usually a row in a database. They have the primary key as a unique identifier. Multiple EJB clients can share each entity bean. Entity beans can survive system shutdowns. Entity beans can have two types of persistence

Container-Managed Persistence (CMP) - The container is responsible for saving the bean’s state.

Bean-Managed Persistence (BMP) – The entity bean is responsible for saving its own state.

Message-driven Bean: is integrated with the Java Message Service (JMS) to provide the ability to act as a message consumer and perform asynchronous processing between the server and the message producer.

Q 64: What is the difference between session and entity beans? SF

A 64:

		Session Beans	Entity Beans
		Use session beans for application logic.	Use entity beans to develop persistent object model.
		Expect little reuse of session beans.	Insist on reuse of entity beans.
		Session beans control the workflow and transactions of a	Domain objects with a unique identity (i.e.-primary key) shared
		group of entity beans.	by multiple clients.
		Life is limited to the life of a particular client. Handle	Persist across multiple invocations. Handles database access
		database access for a particular client.	for multiple clients.
		Do not survive system shut downs or server crashes.	Do survive system shut downs or server crashes.
	Q 65: What is the difference between stateful and stateless session beans?
						FAQ
				SF
	A 65:
		Stateless Session Beans	Stateful Session Bean
		Do not have an internal state. Can be reused by different	Do have an internal state. Reused by the same client.
		clients.
		Need not be activated or passivated since the beans are	Need to handle activation and passivation to conserve system
		pooled and reused.	memory since one session bean object per client.

Q 66: What is the difference between Container Managed Persistence (CMP) and Bean Managed Persistence (BMP) entity beans? SF FAQ

A 66:

	Container Managed Persistence (CMP)	Bean Managed Persistence (BMP)
	The container is responsible for persisting state of the bean.	The bean is responsible for persisting its own state.
	Container needs to generate database (SQL) calls.	The bean needs to code its own database (SQL) calls.
	The bean persistence is independent of its database (e.g.	The bean persistence is hard coded and hence may not be
	DB2, Oracle, Sybase etc). So it is portable from one data	portable between different databases (e.g. DB2, Oracle etc).
	source to another.

Q 67: Can an EJB client invoke a method on a bean directly? SF

A 67: An EJB client should never access an EJB directly. Any access is done through the container. The container will intercept the client call and apply services like transaction, security etc prior to invoking the actual EJB.

Enterprise – EJB 2.x

169

Q 68: How does an EJB interact with its container and what are the call-back methods in entity beans? SF A 68: EJB interacts with its container through the following mechanisms

Call-back Methods: Every EJB implements an interface (extends EnterpriseBean) which defines several methods which alert the bean to various events in its lifecycle. A container is responsible for invoking these methods. These methods notify the bean when it is about to be activated, to be persisted to the database, to end a transaction, to remove the bean from the memory, etc. For example the entity bean has the following call-back methods:

public interface javax.ejb.EntityBean {

public void setEntityContext(javax.ejb.EntityContext c); public void unsetEntityContext();

public void ejbLoad(); public void ejbStore(); public void ejbActivate(); public void ejbPassivate(); public void ejbRemove();

}

EJBContext: provides methods for interacting with the container so that the bean can request information about its environment like the identity of the caller, security, status of a transaction, obtains remote reference to itself etc. e.g. isUserInRole(), getUserPrincipal(), isRollbackOnly(), etc

JNDI (Java Naming and Directory Interface): allows EJB to access resources like JDBC connections, JMS topics and queues, other EJBs etc.

Q 69: What is the difference between EJB 1.1 and EJB 2.0? What is the difference between EJB 2.x and EJB 3.0? SF

FAQ

A 69: EJB 2.0 has the following additional advantages over the EJB 1.1

Local interfaces: These are beans that can be used locally, that means by the same Java Virtual Machine, so they do not required to be wrapped like remote beans, and arguments between those interfaces are passed directly by reference instead of by value. This improves performance.

ejbHome methods: Entity beans can declare ejbHomeXXX(…) methods that perform operations related to the EJB component but that are not specific to a bean instance. The ejbHomeXXX(…) method declared in the bean class must have a matching home method XXXX( …) in the home interface.

Message Driven Beans (MDB): is a completely new enterprise bean type, which is designed specifically to handle incoming JMS messages.

New CMP Model. It is based on a new contract called the abstract persistence schema, which will allow the container to handle the persistence automatically at runtime.

EJB Query Language (EJB QL): It is a SQL-based language that will allow the new persistence schema to implement and execute finder methods. EJB QL also used in new query methods ejbSelectXXX(…), which is similar to ejbFindXXXX(…) methods except that it is only for the bean class to use and not exposed to the client (i.e. it is not declared in the home interface)

Let’s look at some of the new features on EJB 2.1

Container-managed timer service: The timer service provides coarse-grained, transactional, time-based event notifications to enable enterprise beans to model and manage higher-level business processes.

Web Service support: EJB 2.1 adds the ability of stateless session beans to implement a Web Service endpoint via a Web Service endpoint interface.

EJB-QL: Enhanced EJB-QL includes support for aggregate functions and ordering of results.

Current EJB 2.x model is complex for a variety of reasons:

You need to create several component interfaces and implement several unnecessary call-back methods.

EJB deployment descriptors are complex and error prone.