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 ?
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.
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".
