> 8.i currently does not support entity beans. We completely
> believe that entity
> beans are not a solution to light weight, fine grained
> persistence. We are
> going to provide entity beans, as they are required, and they
> are actually
> useful in certain cases.
>
A couple of questions pop up here.( In case you're wondering how come I'm
referencing a posting a week old - I wrote this email sometime back but
there were some email delivery problems :-)
The idea of using session beans talking directly to the database makes alot
of sense as far as querying the system is concerned. What about
transactional updates ? Are you and Javier talking about using session beans
to directly update the system ? Does that result in a weak object model ?
That may not be bad in the kind of non - trivial systems you're talking
about - but I'm curious.
Do the session beans in such systems represent your presentation layer or
the object model ?
I'm also interested in finding out how many business systems have a light
weight, fine grained
persistence. I thought a majority of the business systems have coarse
-grained objects and entity beans are essential for most systems. I feel
session beans are to be used for :
a). Performing "some" complex queries which can do complex joins and bypass
entity beans.
b). Provide the interface to the client for transactional updates which in
turn don't do updates directly but talk to the entity beans .
I thought a lot of systems fall in this category verses a small number of
systems falling in this category ? Isn't this so?
> > I am not happy with entity beans myself, all our work now is with
> > stateless session beans, very much Tuxedo-like. We run
> against existing
> > Oracle databases and I think the caching etc is best done
> by the RDBMS.
>
> This was the original intent of EJB - at least my original
> intent. I think
> entities are useful, but one shouldn't take a silk purse and
> turn it into a
> sow's ear.
>
> I like to hear experiences like yours.
>
> > Regards
> >
> > Javier Borrajo
> > www.tid.es
> >
> > >I believe you will quite like the approach that
> > >the Oracle Business Components for Java framework
> > >enables for building CORBA and EJB based apps
> > >from components.
> > >
> > >See
> http://technet.oracle.com/product/tools/appjava/info/techwp20/wp.html
> > >
> > >Your suggested session-bean centric approach is exactly
> > >what we concluded as well working closely with lots of
> > >folks in our Oracle Applications division building
> > >large-scale, as you put it "non-trivial", applications.
> > >
> > >We found that "non-trivial" apps need "non-trivial" power
> > >in their leverage of the database. Complex, hand-tuned
> > >SQL to join, shape, project, and filter business information
> > >for a specific application task is something that a
> > >well-performing app cannot live without. This is SQL that
> > >an application developer has to write, not a DBA/installer
> > >kind of person. And's it's NOT the kind of SQL that looks
> > >like SELECT <all-200-columns> FROM <table> WHERE <primarykey> = ?
> > >of course. :-)
> > >
> > >The BC4J framework provides a component called a "View Object"
> > >which lets you use arbitrary SQL to work with business information
> > >in any shape you need, while not sacrificing the encapsulation
> > >of the business component logic in your entities that they
> cooperate
> > >with. Our entities are managed by an EJB session bean or a
> > >CORBA server, your choice.
> > >
> > >Hope this helps.
> > >
> > >________________________________________________________
> > >Steve Muench, BC4J Development Team & XML Evangelist
> > >http://jdeveloper.us.oracle.com/jdeveloper/30wp/wp.html
> > >http://technet.oracle.com/tech/xml
> > >----- Original Message -----
> > >From: Muly Oved <[EMAIL PROTECTED]>
> > >To: <[EMAIL PROTECTED]>
> > >Sent: Thursday, September 30, 1999 12:13 PM
> > >Subject: Re: Doubts about Entity beans, Should we use them?
> > >
> > >
> > >| On Thu, 30 Sep 1999 12:30:06 -0500, Richard Monson-Haefel
> > ><Richard@MONSON->Wrong. There is nothing that says BMP is
> less efficient
> > >then CMP at run time. It may take more
> > >| >time develop (unless using something like CocoBase) but
> there is no
> > >reason why it would be less
> > >| >peformant. Containers can do optimizations like
> caching but this is
> > >vendor specific.
> > >|
> > >| SELECT FNAME,LNAME FROM EMP
> > >|
> > >| BMP will generate:
> > >| SELECT PKEY FROM EMP
> > >| And then for every record in the table
> > >| SELECT FNAME,LNAME,ADDRESS,... FROM EMP WHERE PKEY=?
> > >|
> > >| It is much more complicate (if possible) to a container
> to optimize this
> > >select. CMP continer or some other tool can do by far better job in
> > optimize
> > >the original request.
> > >|
> > >| I may be wrong but I fill BMP is a dead-end for future
> optimization.
> > >(vendor specific but critical)
> > >| cache in the application server is also not the answer
> as the database
> > may
> > >be shared and there still need to retrive the full list of
> primery key.
> > >| Also the database is doing caching much better any way.
> > >| The key point here, as I understand, is that CMP or
> other tool can do
> > much
> > >better job. if not today maybe in the future, but BMP code
> will not be able
> > >to enjoy this improvment.
> > >|
> > >|
> >
> >=============================================================
> ==============
> > >| To unsubscribe, send email to [EMAIL PROTECTED] and
> include in the
> > >body
> > >| of the message "signoff EJB-INTEREST". For general
> help, send email to
> > >| [EMAIL PROTECTED] and include in the body of the
> message "help".
> > >|
> > >|
> > >
> >
> >=============================================================
> ==============
> > >To unsubscribe, send email to [EMAIL PROTECTED] and
> include in the body
> > >of the message "signoff EJB-INTEREST". For general help,
> send email to
> > >[EMAIL PROTECTED] and include in the body of the
> message "help".
> > >
> >
> >
> ==============================================================
> =============
> > To unsubscribe, send email to [EMAIL PROTECTED] and
> include in the body
> > of the message "signoff EJB-INTEREST". For general help,
> send email to
> > [EMAIL PROTECTED] and include in the body of the message "help".
> >
> >
>
> ==============================================================
> =============
> To unsubscribe, send email to [EMAIL PROTECTED] and
> include in the body
> of the message "signoff EJB-INTEREST". For general help,
> send email to
> [EMAIL PROTECTED] and include in the body of the message "help".
>
>
===========================================================================
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff EJB-INTEREST". For general help, send email to
[EMAIL PROTECTED] and include in the body of the message "help".
