I really think there needs to be more tunables in terms of controlling when
database calls are made and obviously tighter integration with the database
optimization process to enhance performance of generated SQL.

BEA offers a "db-is-shared" tag and notes it isn't really too useful because
most databases will not be exclusively used by the app server but what if
this became more granular and when I created a CMP I could have a DD tag
stating that the table(s) was exclusively for the use of
the app server (in terms of writes)? The container may not have to load as
often.


I'd hate to see this technology die over performance - Just my $.02

>From: Steve Muench <[EMAIL PROTECTED]>
>Reply-To: Steve Muench <[EMAIL PROTECTED]>
>To: [EMAIL PROTECTED]
>Subject: Re: Are Entity Beans(CMP/BMP) really necessary???
>Date: Thu, 21 Jun 2001 17:14:05 -0700
>
>Winston, you're definitely on to something... and
>your points are validated by our experience
>using J2EE in practice to build large apps within
>Oracle. EJB gives you lots of flexibility, including the
>flexibility to *not* use Entity Beans if you
>don't want to. In fact, the J2EE Design Patterns book says:
>
>   "Data Access Objects Fill a Gap in the J2EE
>    App Architecture Between Responsibilities of
>    Application Developers and Those of Service
>    Providers. They Represent an Excellent Opportunity
>    to Add Value.
>
>    In the Future, Custom DAO's will most likely be
>    replaced by sophisticated object/relational tools."
>
>I gave a talk at JavaOne (Session #2197) called
>"Building the Java Pet Store Demo Using a J2EE
>Design Patterns Framework", wherein I pointed out
>many of the issues that Winston highlights here
>about Entity Beans. Oracle's own applications
>developers bumped into all of these issues while
>trying to decide what is the best way to use
>J2EE for optimal performance and least overhead.
>
>The talk illustrated and demoed how a powerful J2EE
>framework like Oracle's "Business Components for Java" framework
>can be used to build lightweight, EJB-compliant applications
>that consciously eschew heavyweight EJB Entity Beans
>in favor of a Session Bean facade over lightweight BMP-managed
>entity (java beans). It illustrated how using this approach
>allows you to get the full power of your database's SQL query language
>for performant applications, without sacrificing the ability
>to work with pending changes to your lightweight entities
>in the cache and without sacrificing the ability to centralize
>business logic into a single entity class. Finally, by demoing
>a version of the Java Pet Store that was reimplemented using
>the BC4J framework and deployed to the Oracle J2EE Container,
>it showed how much less custom design-pattern implementation
>code is needed and demonstrated how the framework implements
>all of the J2EE Design Patterns for you -- DAO, Session-Entity
>Facade, Generic Value Objects, Views/Joins of entity data, etc. --
>so you don't have to.
>
>On June 25th, any JavaOne attendee can access the PDF
>version of my talk at http://java.sun.com/javaone,
>referencing session #2197.
>
>More info available on Business Components for Java
>at http://otn.oracle.com/products/jdev/content.html
>
>
>Hope this helps!

_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com

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

Reply via email to