From: Javier Borrajo <[EMAIL PROTECTED]>
> I've read the OBC white paper and found it very interesting.
>
> It seems Oracle is bypassing entity beans completely.
> Is it because Oracle 8i does not support entity beans or because
> entity beans are no good ?
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.
> 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".
