EJB
Persistence Modes as valid for EJB 2.xA Quick and Easy Guide
Please observe: Once EJB 3.0 will be out these pages will be obsolete - if I should forget to take them of the web in time then again - please observe that the following pages on EJB persistence only apply to EJB 2.x and lower.
These pages are intended to demonstrate that our persistence patterns can also be found in a newer wake of object oriented business systems: Enterprise Java Beans (EJB) Entity Beans. If you're not familiar with the concept of EJBs please visit one of the sites that give you an overview of EJBs, because we will not replicate all this material here.
It must be noted that EJBs (these pages relate to EJB 2.x) are seen somewhat critical today. Before you use them you might want to read a discussion on EJBs versus POJOs (plain old Java objects). For a deeper discussion see also Floyd Marinescu's book on EJB Design Patterns (you can download the book there), which also covers EJB persistence (besides other things).
This page deals in short form with:
EJB
Persistence Modes as valid for EJB 2.x
an
Example of Bean-Managed Persistence
a
discussion on why this looks so
simplistic compared to sophisticated E/R mappers
and a
construction site on Container-Managed
Persistence
EJBs distinguish between two modes of persistence
Container-Managed Persistence (CMP): Persistence
is provided in an orthogonal fashion by the container provider. This may be
achieved by using stream persistence or automatic object relational mappers.
These latter are usually based on the o/r patterns but
handled very different by different container vendors. CMP gets better all
the time. In the meantime (EJB 2.1) they have something that comes pretty
close to the upper interface of an object-oriented database. Often popular
o/r mapping products also serve as the persistence engine below CMP.
Bean-Managed Persistence (BMP): In this case the bean provider is responsible for the persistence mechanisms and must provide an implementation for the hook methods prescribed by the EJB specification. If you write that bean you also write the database access code or use a mapping framework to provide it. It's a bit tough to follow, whether the BMP interface has changed since EJB version 1.1. Therefore proceed with care from here on. I did not find an indicator, the samples are still on the web. Tough to say. Nevertheless the samples give you an idea.
For an account of EJB persistence see also the SUN technical pages on Entity Beans.
For the following we will have a deeper look at bean managed persistence in EJB1.1. Sun has a nice example for this. This example uses a few o/r patterns.
An entity bean needs to implement the Entity Bean interface, which is in fact an application of a CRUD pattern. If you look at a commented bank account example, you will see how the CRUD operations are implemented using elementary relational database operations.
So there's not too much surprising stuff in EJBs concerning persistence and the o/r patterns will still contain valuable information about the deeper mechanics.
q.e.e. (quod errat expectandum :-)
For another similar example follow this link, which follows the same straightforward line. If you have links to a more sophisticated implementation, drop me a mail
If you had a closer look at the examples and if you did already browse through our o/r patterns you might have noticed that a few things are missing here. The EJB specification does not say anything about
Implementation
Inheritance:
Therefore you do not need patterns
for mapping inheritance here. Nevertheless you will find ways to mimick
implementation inheritance in EJB 2.0 and higher. Best Google
your way to it. Fact is that EJB still does not offer inheritance in Nov.
2003.
Aggregation:
another area of interest for mapping
patterns. Higher EJB versions offer a mechanism of dependent objects - which
can be used as aggregation.
Relations
between EJBs: In EJB 1.1 there's no Smart
Pointer mechanism in the EJB spec that allows you to navigate from one EJB
to another by something that feels like just dereferencing a pointer - you have
to do this by using object IDs and by asking the container to give you the
respective object. In EJB 2.0 and higher, relations are support (OODB style and
CMP) but please don't ask me, how they do it in BMP.
Therefore you might not need most of the concepts that a sophisticated o/r mapper has to provide and you end up implementing objects that can be mapped to a single table. Or you hide a few tricks below the bean's interface like aggregating a few simple data types or treating an order with it's order lines as a single bean interface. BTW: For most business applications this is a perfect match - People who build lots and lots of inheritance in their Business Object Layer at the user perceived business object level will end up having a lot of trouble anyway.
Some would also treat a cluster of Java objects as one EJB - see the article on the Aggregate Entity Pattern (by Craig Larman) - in this case there might be the necessity for a full o/r mapping.
There are some proprietary EJB containers, like IBM's Websphere Application Server (formerly Component Broker) suite that have more complex features like inheritance and relationships at the bean level but these features are non-standard. If you see the description you will find nice known uses for our mapping patterns.
 |
Container-Managed Persistence |
The cute thing about container managed persistence is, that it relieves you of writing all the database code you have seen in the bean-managed persistence example. A similar example for container managed persistence reads like this. If you see the CRUD methods here, you will find no database code.
How is this miracle performed ... The miracle happens because
first of
all you have to declare all the instance variables that you want to be
persistent public. This allows your container to "fill them by
magic" and also to "write them by magic"
you have
to declare at bean deployment time which of these public instance variables is
to be mapped to which column in your database. Most vendors for EJB containers
that support container-managed persistence offer a mapping tool for this.
If you want a compact discussion on what is good about CMP versus e.g. JDO have a look at the this article on CMP or JDO?
TheServerSide.com,
a site operated by Floyd Marinescu offers a
free dowload of his book on
EJB Design Patterns - which also covers EJB persistence.
for
anything on EJB and the like have a look at TheServerSide.com.
This is also a prime palce for discussions on whether to use EJBs at all or use
other approaches like lighter frameworks, less deployment descriptors and the
like.
jBoss
- a very prominent open source EJB container.
Enhydra
Open Source EJB Container Project. Has nice architecture sketches and far more
examples than just the EJB container but also a complete reference application
architecture