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
