Please take me off this list as I have no interest in this conversation.
-----Original Message-----
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]On Behalf Of Juan Lorandi
(Chile)
Sent: Tuesday, March 20, 2001 12:11 PM
To: Orion-Interest
Subject: RE: Why Entity EJBs?
I'm using EJB 1.1 CMP; It gives me as much DB independence as I need. I have
to rewrite some finders when porting from DB to DB; hopefully EQL will
remove this burden too. Orion performs caching of instances, check out
exclusive-write-access and validity-timeout atrributes for entity-deployment
tag in orion-ejb-jar.xml.
However, if you have a distributed environment, cache's like the one in
Orion are a threat to data integrity-- so they *must* be deactivated.
Also, an orion-dependant feature, the boolean isModified(), which in WLS is
called boolean isDirty(), plus a correct use of declarative transactions
allow to minimize the impact on the DB.
I believe CMP is the way to go, but it is very much server-dependant. The
(apparent) poor performance of CMP is due to the need for this solution to
address many things we all want from the server, such as data integrity,
distribution across hosts of the business logic, declarative transactions
and security. There's a price inherent to all this features, and the larger
the spec, the higher the price we all must pay, basically, by leveling down.
MS's single vendor approach actually levels up, but when they don't have the
answers pre-packaged, all crumbles down and somehow we(as developers) must
pay for the loses.
Eventually, the servers *will* perform as expected, but until the spec
matures, we will be stuck with some minor problems. I'm now living in Chile,
and the budgets are pretty tight here, but still, the customer'd rather pay
for an extra box to scale up than to pay extra to the programmers to do a
more optimized job and scale out. I'm aware that this is vastly simplifying
the issue, but the point still stands.
Perhaps the true problem is that we, all the J2EE developer community, are
pushing it too far *and* too broad. This is what happened with CORBA,
leaving us with very little common ground. Some servers implement mor of the
spec, some less. Some scale(but forbid Singleton's, for instance) and some
don't. And there is no single way of making two OTS from two different
vendors to cooperate. CORBA was even taller than the Everest, so nobody
climbed it.
Of course, I also have those rush moments where I wonder why I quitted my
older job, but that's definitely not the time to contribute to anything.
My 2c,
JP
> -----Original Message-----
> From: Jeff Schnitzer [mailto:[EMAIL PROTECTED]]
> Sent: Tuesday, March 20, 2001 1:31 PM
> To: Orion-Interest
> Subject: RE: Why Entity EJBs?
>
>
> 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
>
>
>
