Simon Blake wrote:
> It isn't any work at all - just use a JDO like product - or some other
> mechanism,
> there are lots around and they do the job rather well!
Simon and others have made some excellent points regarding the viability of
entity beans in the real world. I think, however, that entity beans in EJB 2.0
do provide real value because they give us the flexibility to model complex
domains. However, the most important aspect of EJB 2.0 CMP is that it provides
us with a standard component model for modeling persistent business objects.
The word "standard" is important here.
I've noticed that people tend to argue against entity beans in favor of "other"
O/R mapping frameworks. That is fair, but what if we decided that EJB 2.0 CMP
will be the "standard" persistent object component model for Enterprise
JavaBeans. Wouldn't it be better if all EJB developers were familiar with the
same O/R mapping framework? That would make our skills more valuable because
they can be used with any project. We learn the EJB 2.0 CMP model once, and use
it everywhere. CMP in EJB 2.0 is very flexible and it's designed specifically
for the EJB environment and even includes a query language that is fairly easy
to learn. Since the CMP 2.0 model is abstract, it can be implemented
differently by vendors who compete on the basis of performance. (It would be
nice to have one model and only one implementation as Microsoft does with its
technologies, but that would mean one vendor and who wants that?)
Enterprise JavaBeans isn't a new paradigm or even a wildly different approach.
The ideas behind it our not new. Two things make EJB important in the world of
transactional component based systems: (1) It provides a standard component
model and (2) its flexible to implement. The first is the most important in
this context because it justifies why organizations and developers should adopt
EJB. EJB 2.0 CMP is a standard for persistence in EJB. If everyone uses
different O/R frameworks with EJB then developers won't have as much job
mobility, managers will have a more difficult time finding qualified candidates,
engineers will have a more difficult time comparing products. These are reasons
why a standard component model are important and why standardizing the
persistence layer in EJB is important. EJB 2.0 CMP is a good model for this --
it may not be perfect but its a good start.
The second part helps vendors. CORBA demonstrated the importance of
standardizing a component model, but it went to far and was too restrictive for
vendors. It was also to complex and difficult to learn for developers. EJB is
becoming more restrictive, but I think Sun is trying to achieve a balance
between setting a standard that can be implemented consistently, while overly
not restricting vendors. EJB is also fairly easy to learn, which explains, in
part, why it has been so successfull.
If we do not standardize on a persistence model now -- on one that works well in
the EJB transactional environment -- then our skills and the market will
fragment and EJB will not survive. If we abandon EJB 2.0 CMP than eventually
we'll realize that we need a standard component model for persistence -- the
realities of using many different persistent frameworks will make this
realization inevitable. Let us not wait until its painful or impossible to
standardize our persistence component model. Lucky, we have a standard and a
good one, its EJB 2.0 CMP. If you don't like it, don't use it or better yet use
this period to send comments to Sun to improve it. That's what I do, because I
believe in this idea of a standard and I want to see it succeed.
Richard
--
Richard Monson-Haefel
Author of Enterprise JavaBeans, 2nd Edition (O'Reilly 2000)
Co-Author of Java Message Service (O'Reilly 2000)
http://www.EjbNow.com
===========================================================================
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".
