I also am questioning entity beans, after 5 months of intensive
development with them. If you run Hypersonic in server mode and watch
the sql output to the console, it should be readily apparent why... CMP
produces *WAY* too many queries for fine-grained entity beans.
The biggest problem is finder methods. Since all beans are lazy-loaded,
iterating through the finder results of 1000 beans will produce 1001 SQL
calls. There isn't any reason specwise that beans cannot be
eager-loaded, but few (if any) appservers seem to support this.
Does anyone know if there is any support for eager-loading of finder
results in Orion? There doesn't appear to be from the documentation.
I'm really disappointed in the entity bean concept. CMP should give us
faster development times, faster code (with caching), and database
independence, but at the moment we get *none* of the above. By stating
in the blueprints that entity beans should only model course-grained
objects and _not_ "one row of the table" they are effectively saying DO
NOT USE CMP, because what is a CMP bean if not one row of a table? I
noticed that most of the new J2EE patterns Sun recently posted are aimed
at BMP. Sun's schizophrenia on this really pisses me off; with one face
they like to show off entity beans and CMP because MS doesn't have it,
with another they tell us to go back to the bronze age of handwritten
SQL because the technology doesn't work. Grrrrr.
Jeff
>-----Original Message-----
>From: Dan North [mailto:[EMAIL PROTECTED]]
>Sent: Tuesday, March 20, 2001 4:41 AM
>To: Orion-Interest
>Subject: Fwd: Why Entity EJBs?
>
>
>Hi Johan.
>
><two-pence-worth>
>
>I've been developing EJBs in a very (a) intensive and (b)
>short development
>cycle for about 5 months now. I've found that my methodology
>has leant
>towards what the JRF guys are talking about, but in a less formal way.
>
> From the backend forwards: I tend to use entity beans for
>storing/retrieving and most manipulation of data - ie. I have
>quite "fat"
>beans rather than just purely getters and setters. I then use session
>beans for workflow that doesn't seem to belong with any
>particular single
>bean, such as generating reports or anything that requires a few home
>interfaces' finders. I also use session beans for their transactional
>integrity when populating new beans from an HTML (JSP) form,
>especially
>when several beans will be created from a single form's
>contents and I want
>the whole lot to be atomic.
>
>We tend to use JSP and regular form beans for most of the
>other workflow
>stuff, and sometimes we'll have quite complex finder methods
>in the EJBs
>that join across several tables.
>
>The benefits to EJBs, and specifically orion, for me are:
>- Database independence: we're deploying on MS SQL Server but
>it's trivial
>to deploy to eg. Oracle for scalability or Hypersonic for
>local testing.
>
>- Network independence: I need to change no code to cluster orion on
>several hosts and also to split its responsibilities between
>being a web
>server on one host talking to another orion instance being an
>app server on
>another host.
>
>- Speed of development: I don't have to worry about how or
>where my data is
>being stored - I have orion's _fantastic_ OR mapping to do that for me.
>
>
>It seems to me that the JRF is taking the "best practice"
>approach, which
>is a fine and noble thing to do, but then overcomplicating the
>issue by
>wandering off into its own specification.
>
>All my SQL for each package is in one place (orion-ejb-jar.xml), and I
>don't have to worry about scalability or portability. If it
>says J2EE on
>the box, it'll usually have J2EE in the box. (Apart from the
>usual niggles
>with app servers being behind spec - again orion is pretty
>good for being
>up-to-date in this regard.) So I have all the benefits of JRF
>but with the
>backing of a technology as widely-adopted as J2EE.
>
></two-pence-worth>
>
>Disclaimer: I don't work for orion, I just love their product.
> And J2EE
>has been the most useful technology I've discovered since I
>picked up OO
>about 10 years ago!
>
>Regards,
>Dan.
>
>ps. That passage in the EJB book about having a session bean
>talk straight
>to a database is again (imo) a throwback to the technology
>being pretty
>immature and inefficient when the book was written. I have
>had no problems
>with orion's ability to manipulate and cache data for me
>comparably well
>with direct database access - but with the added benefit of
>lots of data
>integrity checking and no SQL on my part. In fact you get two
>levels of
>caching - the database and the app server.
>
>
>>Date: Tue, 20 Mar 2001 09:22:52 +0100 (CET)
>>From: Johan Lundberg <[EMAIL PROTECTED]>
>>Subject: Why Entity EJBs?
>>To: Orion-Interest <[EMAIL PROTECTED]>
>>X-Mailer: Orion ListServer
>>Reply-To: Orion-Interest <[EMAIL PROTECTED]>
>>Sender: [EMAIL PROTECTED]
>>X-MIME-Autoconverted: from 8bit to quoted-printable by
>druid.evermind.net
>>id KAA23094
>>
>>Hi
>>
>>The more I study the J2EE technology, the more I
>>wonder why I should use it.
>>
>>The main reasons why I would use it are these:
>>- Forget about the database layer while only using CMP
>>entity beans.
>>- Faster.
>>- Scalable.
>>- Easier to manage transactions.
>>- Clear separation between client-workflow-persistence
>>(JSP - Session beans - Entity beans).
>>
>>
>>In our current system we use simple JSP, JavaBeans and
>>a few connections to our database.
>>We have made a few mistakes but we envisage cleaning
>>up the system by starting from scratch. It is
>>important that we choose the right technology but I
>>get more and more sceptical about the EJB technology.
>>
>>We have experienced, when doing listings from a search
>>page, that reading from the database and instantiating
>>a few beans (not EJBs) takes a long time. The fastest
>>way is to loop the resultset in the JSP-page, but it
>>does have a few drawbacks and I would prefer to use
>>another architecture.
>>
>>I thought that the pooled entity beans would speed up
>>the system and started to study EJB.
>>
>>Then, Richard Monson-Haefel states in his book that
>>listings shall be done directly between the Session
>>bean and the database. Otherwise it would be too slow.
>>I don't want to bother with SQL anymore and I would
>>like to forget about the database layer, but it seems
>>very difficult to get away with this requirement.
>>
>>To communicate between the JSP, the Session beans and
>>the Entity beans, I get advised to use Data Access
>>Objects. If I were to ignore the Monson-Haefel advise
>>I would first create a bunch of Entity beans from a
>>finder method, instantiate a collection of DAOs and
>>send them back to the requesting Session bean. I
>>wonder what kind of performance I would get from this
>>system? I guess that this can become very heavy
>>weight.
>>It will probably become even more heavy weight when
>>n-m OR-mapping becomes available.
>>
>>This will force us into a solution were we would have
>>to use clusters and the scalability features of EJB
>>comes handy. Is this the strategy from Sun - to make
>>us buy more SUN servers?
>>
>>Now, what did I miss? Is there something that I have
>>completely misunderstood? Please tell me what strategy
>>we should use while developing CMP entity beans with
>>Orion's OR-mapping features.
>>
>>I have found that another paradigm and framework that
>>will simplify the development and reduce the amount of
>>SQL-coding.
>>
>>http://jrf.sourceforge.net/ejb.html
>>
>>http://jrf.sourceforge.net/
>>
>>Why shouldn't we use this framework?
>>
>>Best regards
>>
>>/johan
>>
>>
>>_____________________________________________________
>>Do You Yahoo!?
>>[EMAIL PROTECTED] - skaffa en gratis mailadress på
http://mail.yahoo.se
--
Dan North
VP Development - Cadrion Software Ltd - +44 (0)20 7440 9550
CONFIDENTIALITY
This e-mail and any attachments are confidential
and may also be privileged. If you are not the named recipient,
please notify the sender immediately and do not disclose the
contents to another person, use it for any purpose, or store
or copy the information in any medium
