Some comments below...
> -----Original Message-----
> From: david [SMTP:[EMAIL PROTECTED]]
> Sent: Thursday, December 23, 1999 8:10 AM
> To: [EMAIL PROTECTED]
> Subject: Persistence Design Choices in EJB's
>
> My company has most of it's Business data already in relational databases.
> We've decided to use EJB's on our AppServer. As I look at designs which
> extend and reuse what I've got, I'm concluding the following:
>
> * Entity Beans (CMP)
> - I should not use these if the underlying database is being updated by
> both
> the EJB and my non-EJB systems, due to Data dis-integrity issues caused
> by
> "out-of-synch" cache.
>
Not necessarily true. If an EJB implementation caches in this manner, you
should be able to set caching policies to selectively turn such caching off.
> - For portions on my systems that are "Read-Only" or "net-new" this is
> fine.
>
> * Entity Beans (BMP)
> - I should use a non-cacheing implementation, unless I can guarantee
> synchronization with the updates generated by the non-EJB systems on the
> underlying DBMS.
>
Same comment as per CMP. Beans will synch with datasource state at
transaction boundaries (per the spec).
> * Session Beans
> - I can use JDBC inside the session bean. This is essentially a BMP
> without
> a Finder Method.
>
Not really true at all. A session bean does not represent a persistent
entity, but rather represents a "service".
> I have total control over the Business Interface(s) offered
> by my Session Bean. I can use a seperate interface for each role played by
> my session bean.
>
> I'm tending toward the Session Bean approach for the following reasons:
> 1. I have full control over the Interface(s) offered by the Bean. From a
> multiple release cycle, as my deat requirements change, this allows me to
> keep prior interfaces available without being impacted from business
> domain
> type changes.
>
> 2. I don't want any Session Beans other than ours accessing the database.
> I
> could rely on administrative security on Entity Beans, but the Session
> Bean
> approach seems to ensure that the architecture is not comprimised, where
> the
> Entity Bean approach allows un-informed administrators to grant access to
> my
> entity beans potentially comprimising the architecture. Before long there
> will be client UI's directly calling my Entity Beans. Since my Business
> has
> been involved in many acquisitions, my Business domain types are often
> impacted. This appears to me to have a ripple effect into the Interface of
> any Entity Beans that I build. Thus due to the cohesion created by client
> access the potential change impact on consumers of my entity bean seems
> very
> large.
>
> Am I missing something?
> David Marshall
>
>
> __________________________________________________
> Do You Yahoo!?
> Thousands of Stores. Millions of Products. All in one place.
> Yahoo! Shopping: http://shopping.yahoo.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".
===========================================================================
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".
