somebody suscribed a whole lotta of criticalmass people to this list; can't
we have a subscribe/unsubscribe confirmation??
JP
> -----Original Message-----
> From: Carla Marcyniuk [mailto:[EMAIL PROTECTED]]
> Sent: Tuesday, March 20, 2001 5:53 PM
> To: Orion-Interest
> Subject: RE: Why Entity EJBs?
>
>
> 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
> >
> >
> >
>
>
