Why are we NOT using entity beans?
1. Oracle 8i does not support them yet and we want to run as much of our
data-manipulating Java code inside the database.
2. Our data model is 70+ tables and growing ... we do not want to develop
and manage 70+ entity beans classes+deployment descriptors+JNDI
entrys+...
3. Our transactional requirements are low. We use a single Oracle database,
no need for 2PC, all the transactions can be managed with JDBC
commit and rollback methods.
4. We use properties files and XML files to store SQL so that all of our
querys
and updates/inserts/deletes are automatically managed by our Java server
classes
using reflection. No need for an entity bean per table or similar O-R
mapping schemes.
A single server-side reflection-wise Java class can
select/update/insert/delete
any of our domain objects using this scheme.
5. We use "listing mechanisms" that deliver Vectors of Java class instances
for our
clients to display the way Richard Monson-Haefel explains in his
book/website.
We do not need ejbFind methods for that.
6. We have a lot of faith in Oracle cache mechanisms, so no need to cache
data on
our Java server objects. We try to do as much stateless computing as we
can.
Stateless session beans (Java clients, RMI, automatic transactions) and
servlets
(HTML and Java clients, HTTP, manual transactions) look great for this.
7. CMP is very propietary rigth now, IBM WebSphere AE 2.02 did not support
Oracle (vesion 3 beta2 does), other appservers we were evaluating did
not
support CMP at all. Others support it but are too expensive...
8. CMP means we must develop and manage all those 70+ classes... Even a
simple
CMP entity bean is worse than no bean at all and that's what we get with
4 above.
Regards
Javier Borrajo
www.tid.es
>> 8.i currently does not support entity beans. We completely
>> believe that entity
>> beans are not a solution to light weight, fine grained
>> persistence. We are
>> going to provide entity beans, as they are required, and they
>> are actually
>> useful in certain cases.
>>
>
>A couple of questions pop up here.( In case you're wondering how come I'm
>referencing a posting a week old - I wrote this email sometime back but
>there were some email delivery problems :-)
>
>The idea of using session beans talking directly to the database makes alot
>of sense as far as querying the system is concerned. What about
>transactional updates ? Are you and Javier talking about using session
beans
>to directly update the system ? Does that result in a weak object model ?
>That may not be bad in the kind of non - trivial systems you're talking
>about - but I'm curious.
>
>Do the session beans in such systems represent your presentation layer or
>the object model ?
>
>I'm also interested in finding out how many business systems have a light
>weight, fine grained
>persistence. I thought a majority of the business systems have coarse
>-grained objects and entity beans are essential for most systems. I feel
>session beans are to be used for :
>
>a). Performing "some" complex queries which can do complex joins and bypass
>entity beans.
>b). Provide the interface to the client for transactional updates which in
>turn don't do updates directly but talk to the entity beans .
>
>I thought a lot of systems fall in this category verses a small number of
>systems falling in this category ? Isn't this so?
>
>
>> > 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.
>>
>> This was the original intent of EJB - at least my original
>> intent. I think
>> entities are useful, but one shouldn't take a silk purse and
>> turn it into a
>> sow's ear.
>>
>> I like to hear experiences like yours.
>>
>> > 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".
>> >
>> >
>>
>> ==============================================================
>> =============
>> 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".
