----- Original Message -----
From: "Kenworthy, Edward"
<[EMAIL PROTECTED]>
To: "'jBoss'" <[EMAIL PROTECTED]>
Sent: Friday, December 08, 2000 2:53 AM
Subject: RE: [jBoss-User] CMP
>
> I'll start by talking about EJB1.1
>
> The basic problem is that it is simplistic. It doesn't
support complicated
> relationships (eg many-to-many, many-to-one etc etc) and
the beans it
> generates are inefficient in some, common, circumstances -
eg where you want
> to populate a list of all your Customers with those
Customer's names, so
> that a user can pick one to work with. With EJB1.1 if you
want to look up
> the Customer EJB entity bean's name the AppServer will
load the *ENTIRE* EJB
> entity. So it will read the customer's name, address, etc
etc and all other
> details from the database and instantiate an EJB entity.
Gulp! This is
> horrible particularly if you have lots of Customers -
having lots of EJB
> entity instances in memory at once is not a recipe for a
happy AppServer.
Hi Edward,
I am happy to see your message. I'm just starting to use
Java along with J2EE, JDBC, EJB (etc.) and am coming from a
strong Perl background. After setting up some simple CMP
beans and doing a trace on the server activity, I was
shocked (!) to see all the work done for extremely simple
operations.
I'm certainly not an efficiency guru, but it seems to me
that much of CMP isn't there quite yet. It's very easy to
use and for smaller applications with too much hardware it
would probably be fine.
> EJB2.0 (not finalised yet) is a major improvement. It
partially solves the
> issue with complex relationships, doesn't handle demand
loading at all, and
> completely fixes the issue with "all I want is the names
of all my
> customers".
This is good to know. I figured that other people would be
having these same problems, and that some of them might even
be involved with writing future specs :-)
> The other "problem" with CMP and I think this applies to
1.1 and 2.0 is that
> it encourages people to map their entity classes 1:1 to
their EJB entities
> (I know as it's what we did initially because it appears
to be the easiest
> approach). This is bad because the EJB model is a
coarse-grained component
> model, individual EJB instances (especially EJB entities)
have a significant
> memory and processor overhead.
This is more of a design issue, I think, and really depends
on your application. If you're writing a straight order
entry system (web shopping cart, etc), then it makes sense
to model your data with more information in each object --
for instance, putting more information into a "profile"
which includes payment, shipping address and billing address
rather than having separate tables for each and linking them
together.
However, if you're doing multiple things with these
objects -- harvesting demographic information, tracking
customer service requests, whatever -- then I think it makes
sense to keep the objects as granular as possible and glue
them together with behaviors from stateless session beans.
Yes, this means there will be more objects "floating around"
in the container, but that's the container's problem. I
don't mean to be flip about this, it's just that I don't
want to spend a lot of time modelling my data in a
particular (and IMO unnatural) way because the container
can't handle it quite yet. Perhaps that's just my faith in
Open Source -- if it's a problem for me, then it's also a
problem for the authors, who are much smarter than I am and
will figure out a way around it. Marc's recent e-mail about
how JBoss manages all these objects rewards my faith :-)
(And so does my experience with countless other OS
projects.)
> The final, not problem, but limitation of CMP is that you
should definay
> *not* access the underlying database from outside of
EJB-land, and you can't
> integrate with legacy databases.
I got this impression too. This rubs me the wrong way a
little -- probably since Perl is so good at glueing
heterogenous systems together -- but's it's not
insurmountable. Just some more thoughtful design work.
I hope other folks can chime in about CMP. I'm still
learning and would love to hear about experiences elsewhere
and in the real world.
Chris
--
Chris Winters <[EMAIL PROTECTED]>
Internet Developer
http://www.optiron.com
--
--------------------------------------------------------------
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
Problems?: [EMAIL PROTECTED]
