> Again, the *only* business logic that I would migrate to entity
> beans is logic that is intrinsic to that entity alone, is
> independent of any specific use case, and is shared by all
> applications that may use the entity.
Very well put, and exactly what I had in mind.
> I'm curious, do you have a reference that states that entity
> beans were designed for more than distributed object persistence?
> I'm sure there's something there, but I was only able to find
> these:
No. Entity beans is a new model, so you will not find much literature
about it, and the EJB specs deal with the API contracts, as you pointed
out, not in how to use them.
I am not developing an open source Java object persistence
implementation that will server as a CMP engine. That gave me a good
perspective on the cost/benefit of entity bean compared to other forms
of object persistence. The conclusion is that entity beans serve well
(as you also pointed out) to abstract business data as part of the
business process, but not as a mere persistence mechanism (which many
developers confuse it for).
I'll be a bit more specific.
Given an O/R persistence engine each of the servers can access the
database through a Java object interface very efficiently. Database
servers are designed to deal with distributed servers and concurrency --
whether you access them directly through JDBC, through a persistence
layer, or through EJB, you get the same results.
In an n-tier environment your client will access data remotely by adding
RMI on top of the persisted Java objects. The pros are better
distribution, the cons are the RMI (or even IIOP) performance hit. But
this still does not require the existence of EJB entity bean.
(I am all familiar with the argument that EJB entity beans provide a
portable API, but I am assuming that another portable API will exist for
Java object persistence that will not require an EJB server)
Using EJB instead of RMI increases the overhead as you add multiple
layers of interfaces (home/remote/instance), more complex calling
semantics (security/synchronization/lifecycle). But at the same time you
immediately gain the benefits of TP (transaction processing) monitoring.
Issues like limiting the number of instances, transparently distributing
the application, handling security, object lifecycle management, etc are
not present in RMI or plain IIOP.
> The EJB 1.1 spec, section 8.1, says "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."
I was actually referring to (spec not in front of me right now) to where
it states that entity beans should be used for coarse grained objects,
not for fine grained objects. If your database consists of many fine
grained objects, you are advised to use entity beans only for the large
blocks.
This advise takes into account the performance hit of EJB, and the fact
that the EJB model is best for handling the business data + process, not
just the plain data.
> The EJB spec is mostly focused on the mechanics of how entity
> beans work, and doesn't get into how to use them much. The SBDG,
> however, does get into the use of entity beans and it doesn't
> talk about using them beyond data access.
The real important issues with EJB are either not discussed in the EJB
spec, or are touched over with small remarks that a few people pay
attention to. The spec is one of the best API specs I've seen, but sadly
it leaves some of the practical wisdom behind.
Anyway, with all these discussions I've considered writing something to
explain the technical issues behind entity beans. There's nothing like
writing an implementation to understand what it does best and what it
does only partially good.
arkin
>
> -Paul Hodgetts
>
> ===========================================================================
> To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
> of the message "signoff EJB-INTEREST". For general help, send email to
> [EMAIL PROTECTED] and include in the body of the message "help".
===========================================================================
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff EJB-INTEREST". For general help, send email to
[EMAIL PROTECTED] and include in the body of the message "help".
