Developer's Forum - Ejb : FAQ

Enterprise Java Beans (EJB's)

In this session, we will look at the concept of Enterprise Java Beans, or EJB's. We'll

look at the different types of EJB, and find out about the features that EJB's offer.

Java Beans

Sun invented the concept of a

Java Bean some years ago, in an attempt to extend

Java's reach into the area of Rapid Application Development.

We saw in "Java vs Other Languages" session (Page 26) that Visual Basic allows

developers to rapidly build applications by dragging and dropping prebuilt

components on to the screen, and then by customising the components by changing

some properties.

Sun's idea was that a

Java Bean would become the equivalent of the Visual Basic

Components. A Java Bean is a standard Java Class, but one that is simple and easy for

programmers to reuse themselves. For example, the "Button" in Swing (see Page 16)

is a Java Bean. The programmer can change the colour of the button, the behaviour of

the button and so on, but most of the work has already been done for them.

Java Beans are often graphical, but not necessarily. As long as the Java Class

conforms to a collection of "Design Patterns", simple guidelines as to how the class is

written, then it qualifies as a Java Bean. The key aim is that regardless of what the

Bean is, it has a collection of properties that can be accessed and customised by the

programmer.

Figure 31 - A JavaBean (in this case, the Button from the Swing classes). The

programmer has customised the bean slightly, but most of the work was already

done for them

The Purpose of Java Beans

By assembling these Java Bean "Components" we can theoretically build applications

without reinventing the wheel. Java Beans were originally envisaged to be graphical,

but a Java Bean can actually be any Java Class, as long as it conforms to the "Design

Patterns".

An Introduction to Java and J2EE

From a theoretical point of view, Java Beans are easy to design and build – but in

reality, there are some catches that make good Beans very difficult to build well.

Therefore, commercial Java Beans can be quite expensive to buy.

Enterprise Java Beans

The next stage of evolution of Java Beans was the development of

Enterprise Java

Beans

, or EJB's. EJB's are essentially the same as standard Java Beans – they are

small components that perform some kind of job.

However, EJB's live on servers rather than inside standard desktop applications. Since

they are server based, they are never graphical, unlike standard Java Beans, which

often are.

As an example, you might have a "Customer" EJB in an e-commerce application.

This EJB would hold data about your customers, such as their credit rating and which

products they are most likely to be interested in. As with any other Java Module, an

EJB will be able to do things as well – for example we might be able to query the

Customer EJB and find out the credit rating for each customer we are interested in.

The most striking feature of EJB's is that they provide your programmers with a

whole raft of functionality that is essential when building large scale systems. All of

this is done for them, so they can concentrate on the job in hand.

EJB's Are:

•

Persistent

•

Transaction Aware

•

Distributed

•

Multithreaded

We'll look at each of these concepts in turn. All of these features are provided "for

free" – the programmer of the EJB doesn't need to manually implement any of it. The

trick is that your programmer's EJB's are "wrapped" in a piece of software called the

EJB Container

, provided by the Application Server.

EJB's are Persistent

The data held inside an EJB can be made to be persistent – in other words, it can be

stored on a relational database automatically. Any changes to the data in the bean will

be reflected in the database, without the need for the programmer to write laborious

(and error-prone) JDBC code (see "Databases in Java", page 24).

The SQL required to perform the database transactions will be generated

automatically by the deployment tool supplied by your application server (this SQL

An Introduction to Java and J2EE

can be tailored to your own needs if required, but it is done in the tool rather than

polluting the Java code).

If required, persistence

can be handled manually by the programmer. This would be

necessary if particularly complex database persistence is required, but it does mean

polluting the Java code with database/JDBC calls.

The terminology for the automatic persistence is "Container Managed Persistence", or

CMP

– the manual variety is BMP.

Our general advice is aim for CMP if at all possible – it is much more elegant and is

one of the strongest features of EJB's. We'll return to this topic in a short while.

EJB's are Transaction Aware

EJB's that hold data can be made to be transaction aware fairly easily. Either the

programmer manually demarks regions of code that must be considered atomic, or

entire methods (Java procedures) can be set to be a single transaction, using the

deployment tool.

In this example, we have set a Java method called "buy" to be a single transaction. If

anything goes wrong part way through the process, any changes made as part of that

method will be automatically rolled back.

Place Order Example

As an example, consider an EJB that is responsible for placing an order for a

customer. The EJB's task is as in the following flow chart:

Place Order Use Case

Add order to

orders list

Add invoice to the

invoice queue

Send "order placed"

message to customer

Credit Check

Customer

ok?

Return Error

Message

Use Case End

yes

Figure 32 - The Place Order Process

An Introduction to Java and J2EE

Clearly, if the process crashed (for whatever reason) after the order had been added to

the list, but before the invoice was added to the queue, we would have a fairly serious

business problem. By running the procedure as an EJB, we can make the entire

process a transaction.

If more fine grained control is required (let's say we wanted to start the transaction

after the credit check, and end the transaction once the invoice is raised), then this can

be done by the programmer using a fairly simple "start transaction" and "end

transaction" process.

The automatic transaction handling is called "Container Managed Transactions"

(

CMT); the method using programmer intervention is called "Bean Managed

Transactions" (

BMT)

EJB's are Distributed

As we have seen, Enterprise Java Beans are located on a server and managed by the

Application Server.

However, the programmer using the EJB (the

client programmer) doesn't need to

know anything about where the EJB is physically located. They follow a fairly simple

procedure of "looking up" the EJB to get a handle on the bean; and then they call its

methods exactly as they would do with a regular Java class.

All of the nasty network mechanics happens behind the scenes in complete

transparency (by the way, the technique used is called RMI or Remote Method

Invocation – any programmer who has used RMI by hand will testify, it is a fairly

unpleasant technique!)

EJB's are Multithreaded

The Application Server manages threading automatically. As a quick example,

assume a programmer has written an EJB called "Book" representing a product in an

online book store. What happens if two customers try to get information about the

book at the same time?

The application server will automatically manage threads so that the two tasks can

happen in parallel – and once again, no programmer intervention is required to make

this happen.

In addition, the application server will also intelligently pool resources. For example,

a thousand clients might all be trying to access the same EJB at the same time; the

application server will be able to share a limited number of EJB's amongst those

thousand clients, thus preserving resources and preventing excessive server load –

again, all this happens without the programmer needed to code anything special to

make this happen.

An Introduction to Java and J2EE

Types of EJB

Although until now we have considered an EJB to be a single concept, in fact there

are actually three different types of Enterprise Java Bean available. The three types

are:

•

A Session EJB

•

An Entity EJB

•

Message Driven EJB's (MDB)

Session beans

are in very common use – these are usually beans that are primarily

written to

do something. For example, we might have a session bean responsible for

credit checking customers, or for placing orders (as on Page 55).

Session Beans are

not persistent – any data they hold will be lost when the system is

restarted.

Entity Beans

are EJB's that provide the persistence features we discussed earlier.

They are usually used to represent the real world "objects" that exist in the system.

Examples of Entity EJB's would be

Customer, StockRecord and PurchaseOrder.

You could think of an Entity Bean as being "data storage" beans, but they are Java

classes, and so can

do things just as with a session bean.

Message Driven Beans are Java Classes that are capable of responding to "Messages"

sent to them. The benefit of an MDB is that they can work

asynchronously – in other

words the client asks the bean to do something, and the client can go off and carry on

with some other task, while the MDB is responding to the message at the same time.

This is a powerful facility, but we won't explore it in any depth on this course.

Entity Beans

The concept and implementation of Entity Beans is very controversial (at the time of

writing; things change quickly in J2EE!). Many J2EE applications have studiously

avoided implementing entity beans, and have been happy to settle with Servlets, JSP

and Session Beans.

This will work perfectly well; an entity bean can be replaced by a standard class (you

will see these referred to as "Plain Old Java Classes" – POJO's). These plain Java

classes use JDBC calls to manually manipulate the underlying database.

Remember, however, that this manual use of JDBC is a pollution of your Java code, it

is less maintainable and perhaps less understandable. But on the other hand, many

people find Entity Beans difficult to understand and use anyway.

Much of the confusion about Entity Beans has been attributed to the original

specification of them – it was allegedly poorly written and difficult to understand.

An Introduction to Java and J2EE

The choice is entirely down to your project and its senior designers. However, be

aware that a new version of the Entity Bean spec has now been released – it is called

EJB 2.0

, and it fixes many of the original problems with Entity Beans.

As long as certain design principles are maintained (more on this shortly), Entity

Beans are now viable for serious developments, and they certainly are a powerful tool.

J2EE Design Patterns

Designing and building J2EE systems is difficult. Or perhaps more accurately

speaking, it is easy to design and build poor J2EE systems; applications that perform

and scale badly.

Help is at hand. A collection of good design principles, called "

Design Patterns"

have been formulated by the J2EE community. Sun are making a big effort to collect

and publish these design patterns – they are all available on-line at the Java website.

We'll look at a quick example of a simple design pattern – our aim is not to teach

design patterns, as that is beyond the scope of this course – but we do want to give the

flavour of design patterns, and establish that understanding them is critical to building

good systems.

Our advice is to ensure that your designers and programmers are familiar with at least

some of the patterns, and that your project embraces the teachings of the patterns.

If you are planning to buy a J2EE Design Patterns book, ensure that the book covers

EJB 2.0, as the new version of Entity Beans has made some of the design patterns

redundant. An excellent design patterns book is available for free download – see

reference [4].

Example Design Pattern

Consider a simple system that allows the user to view a list of all customers in the

database – and for each customer, their open purchase orders are also displayed.

Here is our first attempt at designing the application…

An Introduction to Java and J2EE

Web

Page

(JSP)

Customer

EJB

Purchase

Order EJB

getCustomerDetails

getPODetails

Application

Client Server

Figure 33 - Our first design attempt

This will work. Our client application (in this case it is a web page, but it could have

been a standard Java application) makes calls to the Enterprise Java Beans on the

server. Remember, this is possible and easy because EJB's are distributed and the

client programmer can easily locate and call the beans.

Our design has the client calling the Customer EJB first to get the customer data, and

then it follows with a call to the Purchase Order EJB. The information is then

displayed on the web page.

Design Problem

Assume that this application works. The J2EE Design Patterns tell us that it isn't a

very good design however – it will perform badly, especially as the application scales

up.

The reason is that the calls across to the EJB's are slow. They are travelling across a

network, or possibly even the internet. Essentially, having two separate calls is

wasteful. Applying a Design Pattern will help here…

Design Solution

The solution is called a

Session Façade – all design patterns have recognizable

names. The Session Façade guides us to remove the multiple calls across the network

and replace with one single call.

An Introduction to Java and J2EE

We will require an extra EJB to make this work, however – usually we will use a

Session Bean

16. We make a single call to the session bean, and then the session bean

can talk to the EJB's on the server.

Web

Page

(JSP)

Customer

EJB

Purchase

Order EJB

getCustomerDetails

getPODetails

Application

Client Server

ListCustomers

Session EJB

listCustomers

Figure 34 - The new design, using a Session Façade

This has cut down the network "chattiness" and will certainly have a significant effect

on performance, especially when we scale the system up, or if the List Customers

process becomes more complex with more calls.

This is just one design pattern (it happens to be the most common and one of the most

important), but as we have mentioned, there are plenty more and investing time and

effort into learning them will pay off in spades for your project.

EJB Summary

•

Enterprise Java Beans are similar to standard Java Classes

•

They automatically provide Distribution, Transactions, Multithreading and

Persistence

•

There are three different types of EJB – Session, Entity and Message-Driven

•

Entity Beans are the persistent type of Bean and have been quite slow to gain

acceptance

•

Use recognised "Design Patterns" when building your applications

This makes sense – recall we said that Session Beans usually do something rather than holding onto

data

Chapter 7