Sounds interesting, but the url is not valid.
The webserver states that that page doesn't exist.
Frank
-----Original Message-----
From: A mailing list for Enterprise JavaBeans development
[mailto:[EMAIL PROTECTED]]On Behalf Of Steve Muench
Sent: Thursday, September 30, 1999 4:41 PM
To: [EMAIL PROTECTED]
Subject: Re: Doubts about Entity beans, Should we use them?
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".