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!
______________________________________________________________
Steve Muench, Lead XML Evangelist & Consulting Product Manager
BC4J & XSQL Servlet Development Teams, Oracle Rep to XSL WG
Author "Building Oracle XML Applications", O'Reilly
http://www.oreilly.com/catalog/orxmlapp/
----- Original Message -----
From: "Winston Gnananayagam" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Thursday, June 21, 2001 16:47
Subject: Re: Are Entity Beans(CMP/BMP) really necessary???
| Hi Ken,
| Thanks for the reply. I understand from the message, that
your
| approach would be to use session beans to do search queries for accessing
| data, instead of using finder methods. Then load the appropriate CMP bean,
| if necessary to interact/update the data that one or more clients deal
with
| to maintain a persistent state. Please let me know, if I interpreted your
| design correctly.
| If, I had interpreted it correctly, I feel that the CMP bean
is
| primarily used only for data updation. Where most of the complex data
| retrieval logic is being implemented on the session bean. Wouldn't it be
| more better to implement the data updation logic in a normal java class.
| This way we could avoid all the data marshalling/unmarshalling over- heads
| that's inherent with a CMP bean.
| Thanks,
| Winston.
|
|
|
|
|
|
| ----- Original Message -----
| From: "Kenneth D. Litwak" <[EMAIL PROTECTED]>
| To: <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>
| Sent: Thursday, June 21, 2001 6:55 PM
| Subject: Re: Are Entity Beans(CMP/BMP) really necessary???
|
|
| > I don't know that entity beans are necessary. On the other hand, I
| do
| > think that having an object whose persistent state is managed for me by
| the
| > container (in either BMP or CMP) is desireable. At the same time, I
think
| that
| > there are lots of things one can do with entity beans which make them
| > aperformance problem: finder methods which return masses of data; 2.
| Ussing
| > them for single database access operations (I got the data one time and
| need it
| > exactly one time); 3. Allwoing clients direct access to entity beans
| >
| > IMHO, the way to use an entity bean is generally would be the
| following
| > scenario:
| > 1. Session bean returns one or more rows/objects from a
database
| > 2. User selects a row that he/she cares about, in an
application
| which
| > geneally would have the user interacting with the row/object multiple
| times.
| > 3. Session facade finds the entity bean's orw/object and uses
the
| > entity bean.
| > This makes for a less brittle architecture, and uses entity
beans
| in a
| > conservative way.
| >
| > Ken Litwak
| > >
| > >Hello All,
| > > After trying to build a robust EJB model that needs to
| scale
| > >and perform well. I have pretty much come to the conclusion of avoiding
| any
| > >use of Entity Beans(CMP/BMP) at all in the design.
| > > In my perspective, I see Entity Beans as nothing but a
| > >"replication" of the underlying data in an OO fashion. Though, there is
| > >nothing wrong with this, Entity Beans seems to come with a lot of
| overhead.
| > > Yes, a CMP bean gives added functionality of
| > >accessing/updating the underlying data without having to write any code
| from
| > >the developer perspective. But, this seems to come with a major
| performance
| > >degradation. Its completly dependant on how well the container is
| > >implemented by the vendor. Ofcourse, its not possible to write any
| complex
| > >data-retrieval logic on a CMP. Defining a coarse-grained bean seems to
be
| > >very difficult on a CMP bean. I'm not sure, if a CMP bean can handle
any
| > >underlying data thats NOT relational in nature. Dont know, if a CMP
bean
| > >could ever be implemented, which doesnt care of the underlying data
| > >format(XML, flat file's, RDBMS) and still be portable. I'm not sure if
| the
| > >new EJB 2.0 spec, defining EJB QL and Local Interfaces would really
| > >alleviate any of these issues.
| > > When considering BMP's, it does give better control
| over
| > >the underlying data to the developer. But, it still comes with a lot of
| > >overhead. Some, J2EE design patterns(DAO, ValueObjects, Value List)
| suggests
| > >different ways to avoid these overheads or pitfalls(like network
| chattiness,
| > >seperation of Data access logic, etc.). But, somehow it seems to me
that
| the
| > >Entity Bean itself is inherently flawed and using a host of design
| patterns
| > >to overcome this seems like a futile excercise.
| > > For now, most of my design seems to be in this fashion.
I
| > >have defined DAO's which has the logic to access underlying data. The
| DAO's
| > >returns a DataModel representing the data when called upon. These
| DataModels
| > >that contains the data is wrapped by a SFSB. The SFSB implements some
| > >business methods and iterating methods which would use the DataModel
| > >containing the data. Ofcourse, we could use the ValueObject pattern on
| top
| > >of this to send minimal data needed by the client.
| > > I feel this above design is lot more coarse-grained
| ,gives
| > >better control over the underlying data, transactional and comes with
| less
| > >overhead.
| > > I might be wrong in my above assertions. Do correct me,
| > >before u shoot me down. Is there any potential issue, I might have
| > >overlooked in trying to avoid Entity Beans completly from my design???
If
| > >this question has already been discussed in this list, please do point
me
| to
| > >the appropriate thread.
| > >Thanks,
| > >Winston.
| > >
| >
|
>===========================================================================
| > >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".
