OTN just went live with a new look (and site structure!) today...
Sorry. Here's the right URL for the whitepaper...
http://technet.oracle.com/products/jdev/index2.htm?Info&info/techwp20/wp.htm
l
________________________________________________________
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: Suneet Shah <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Thursday, September 30, 1999 3:37 PM
Subject: Re: Re: Doubts about Entity beans, Should we use them?
| Hi Steve,
|
| The url below does not seem to be working. could you send the correct url
| please.
|
| thanks.
|
| Suneet Shah
|
| -----Original Message-----
| From: Steve Muench <[EMAIL PROTECTED]>
| To: [EMAIL PROTECTED] <[EMAIL PROTECTED]>
| Date: Thursday, September 30, 1999 5:12 PM
| 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".
