Entity Bean Usage

Thread view:

Peter McKenzie - 24 Sep 2003 20:50 GMT

I'm in the early stages of a J2EE project that will use entity beans
(EJB 2.0)as the primary persistance mechanism. One of the main design
considerations we are currently debating is whether to put the bulk of
the business logic into the entity beans. To my way of thinking this
is the natural 'O.O' way of doing things but I understand it is quite
common to put the business logic into session beans.

Often the session bean approach seems to fall into the pattern of that
Martin Fowler would call a 'Transaction Script' which is basically a
procedural style of implementing the business logic. I'm more
interested in taking a domain model approach, which means creating an
object model of my problem domain. Is it feasible to do this using
entity beans?

To add a bit of context, we will be using the EJB command pattern to
provide a course grained service layer, I envisage some basic
sequencing type logic to find its way into the commands. All EJB
access will be via the local interface. Overall I would describe the
application as being of moderate size and complexity, meaning it is
non-trivial but not overly big or complex.

Interested in any thoughts on these matters, and particularly
interested in hearing from anybody who has experience with using
entity beans to create an object model (with significant business
logic) of their problem domain.

thanks in advance,
Peter

Reply to this Message

John C. Bollinger - 24 Sep 2003 21:50 GMT

> I'm in the early stages of a J2EE project that will use entity beans
> (EJB 2.0)as the primary persistance mechanism. One of the main design
> considerations we are currently debating is whether to put the bulk of
> the business logic into the entity beans. To my way of thinking this
> is the natural 'O.O' way of doing things but I understand it is quite
> common to put the business logic into session beans.

You answered your own question when you called the entity beans a
"persistance mechanism." Business logic and persistence should not be
comingled -- it makes for difficult maintenance and higher rate of bugs.
As a practical matter, it also removes the possibility of using
container-managed persistence.

Business logic is the bread and butter of session beans, although they
can do persistence, too. Entity beans are designed specifically as a
persistence mechanism.

> Often the session bean approach seems to fall into the pattern of that
> Martin Fowler would call a 'Transaction Script' which is basically a
> procedural style of implementing the business logic. I'm more
> interested in taking a domain model approach, which means creating an
> object model of my problem domain. Is it feasible to do this using
> entity beans?

I'm somewhat leery, at least if you are talking about using _only_
entity beans to define your model. It might work, but I think you'd be
setting yourself up for development and maintenance problems.

Now, you could certainly construct a model in the form of a framework
into which you plug entity beans where you need persistent data. Such a
model need not be in a bean at all, but it would be pretty natural to
put it in a session bean so as to be easily able to perturb the model
wholly within the scope of a single J2EE transaction. Behind the scenes
you can have as complex an arrangement of helper classes as you wish to
make it all fit together.

My recommendation, if you want to pursue the object model approach, is
to design the object model independant of any consideration of the
persistence mechanism. After you have a reasonably good idea what the
object model will look like, then fit it to the most appropriate EJB and
/ or other J2EE technologies. That way your design drives the
technology choices rather than the other way around.

John Bollinger
jobollin@indiana.edu

Reply to this Message

Peter McKenzie - 25 Sep 2003 05:18 GMT

> > I'm in the early stages of a J2EE project that will use entity beans
> > (EJB 2.0)as the primary persistance mechanism. One of the main design
[quoted text clipped - 6 lines]
> "persistance mechanism." Business logic and persistence should not be
> comingled -- it makes for difficult maintenance and higher rate of bugs.

I was mainly thinking of CMP, where the bulk of the persistance logic
is handled by the container. In this case I'm not sure where the
extra bugs will come from.

> As a practical matter, it also removes the possibility of using
> container-managed persistence.

Why is that?

> Business logic is the bread and butter of session beans, although they
> can do persistence, too. Entity beans are designed specifically as a
> persistence mechanism.

Or were they designed to be components that support persistence?

> > Often the session bean approach seems to fall into the pattern of that
> > Martin Fowler would call a 'Transaction Script' which is basically a
[quoted text clipped - 5 lines]
> I'm somewhat leery, at least if you are talking about using _only_
> entity beans to define your model. It might work, but I think you'd be

My mistake, I didn't mean to imply that the model would consist *only*
of entity beans. Of course there will be non-entity bean objects.

The approach I am suggesting is simply to use entity beans (CMP) to
implement objects that require persistence. And if the domain model
suggests that an object that is implemented as an entity bean should
be responsible for certain behaviour, then that behaviour would go
directly into the entity bean itself. Seems natural enough to me :-)
What problems would this cause?

> setting yourself up for development and maintenance problems.
>
[quoted text clipped - 12 lines]
> / or other J2EE technologies. That way your design drives the
> technology choices rather than the other way around.

I agree with this last paragraph in principle, but there are external
considerations...

cheers,
Peter

> John Bollinger
> jobollin@indiana.edu

Reply to this Message

Bob Kranson - 25 Sep 2003 18:50 GMT

A few thoughts:

> > As a practical matter, it also removes the possibility of using
> > container-managed persistence.
> Why is that?

Concurrent data access will suffer because many users are manipulating the
same copy of the data rather than a copy of the data associated in the
session bean. Activation and passivation per entity bean instance becomes
more intense. (More bugs to ensure correct object instance is manipulated.)
Whereby the session manipulates a copy from the entity bean, the entity bean
may become more active on the logic than it can interpret the necessary
persistance. (The entity bean is worried about the data store more than it
is the logical manipulation of the data.)

> > Business logic is the bread and butter of session beans, although they
> > can do persistence, too. Entity beans are designed specifically as a
> > persistence mechanism.
>
> Or were they designed to be components that support persistence?

I think entity beans are defined more-so for persistance. Thus stateless
and stateful session beans.

> The approach I am suggesting is simply to use entity beans (CMP) to
> implement objects that require persistence. And if the domain model
> suggests that an object that is implemented as an entity bean should
> be responsible for certain behaviour, then that behaviour would go
> directly into the entity bean itself. Seems natural enough to me :-)
> What problems would this cause?

I thought a behavior as an association of objects. Unless you are
referencing that behavior as a property constraint. In this case, a
business method in the entity bean makes sense. This seems to be referred
to as the 'immediacy' of the requirement. Checked in presentation, servlet,
session, or entity bean? Does your user really want to wait for the entity
bean to reject an edit check?

I think you need to be careful in assuming all CMP management. Vendor
transaction management can influence your data copies and their currency.
Stated simply, "Which copy of the entity bean instance did you want for
operation on? Oh, that's in transit to this other client and your code will
have to wait for the proper vendor synchronization -- at an entity bean
level." This is why a session bean is safer, IMHO.

> I agree with this last paragraph in principle, but there are external
> considerations...

I agree with John's approach as well. In terms of J2EE, you want maximum
reuse of entity beans with any 'custom' interpretations housed in a session
bean or web layer. This way, granularity of control on the logic belongs
with the session bean rather than specific methods of the entity bean. I
think this becomes more flexible as your project moves forward through
varying application servers or database vendors.

Regards,
Bob Kranson

Reply to this Message

John C. Bollinger - 26 Sep 2003 17:20 GMT

>>>I'm in the early stages of a J2EE project that will use entity beans
>>>(EJB 2.0)as the primary persistance mechanism. One of the main design
[quoted text clipped - 10 lines]
> is handled by the container. In this case I'm not sure where the
> extra bugs will come from.

The extra bugs come from placing responsibilities for two different
kinds of tasks on the same code. On the other hand, if you go with CMP
then there is a fairly rigid partition between any business logic you
might incorporate and the container-supplied persistence logic, so maybe
it wouldn't be as bad. (But see also below.)

>> As a practical matter, it also removes the possibility of using
>>container-managed persistence.
>
> Why is that?

I guess that I was mainly thinking that you would want to trigger
business logic based on modifications to the persistent state of your
entity beans. You cannot do that with CMP because you have no hook --
the container provides the complete persistence implementation. There
are alternatives, of course; the main ones that come to mind at the
moment being
    (1) clients only mutate the entities via business methods, not directly;
    (2) clients are expected to invoke a business method after mutating an
entity; and
    (3) it is not necessary to trigger business logic when an entity is
mutated.

If (1) then you distribute what might otherwise be the session bean
logic among all your entity beans. This is likely to increase the
maintenance cost of your application, and might conceivably cause actual
trasaction-related problems.

If (2) then you are setting yourself up for programming errors. Just
don't do it.

If (3) then I withdraw my comment. I'm having trouble seeing how an
object model would work if this case applies, however.

>>Business logic is the bread and butter of session beans, although they
>>can do persistence, too. Entity beans are designed specifically as a
>>persistence mechanism.
>
> Or were they designed to be components that support persistence?

I'm not certain that I fully understand your question. From the EJB 2.0
spec, section 9.1: "an entity bean is a component that represents an
object-oriented view of some entities stored in a persistent storage,
such as a database, or entities that are implemented by an existing
enterprise application." Is that last part what you're getting at? If
so then you are right, but I don't think the distinction is germane to
the present discussion. The point is that the fundamental job of an
entity bean is to present a view of a logical object that resides
somewhere else. When that somewhere else is a persistent store, entity
beans' primary purpose is to function as a persistence mechanism.

(Perhaps I am using the term in an imprecise way. By "persistence
mechanism" I mean to imply both storing data persistently and retrieving
data from persistent storage.)

[...]

Perhaps none. Perhaps transaction-related problems. Possibly higher
maintenance costs. Possibly increased likelihood of bugs.

Difficulties with synchronization across multiple data objects are
likely, should such functionality be required (transactions don't fully
solve this problem, especially if the goal is to avoid situations where
rollbacks are necessary).

John Bollinger
jobollin@indiana.edu

Reply to this Message

Entity Bean Usage

Free Magazines