> Hi John & Marcel -
>
> This is an interesting topic and one that I guess lies at the
> heart of the way many EJB systems are architected. It seems to
> me that using this Session to Entity layer would tend to restrict
> your transaction abilities. Would you mind sharing your
> requirements for transactions?
No, I don't see any restrictions. We control transactions per method on the
Session bean. The Entity beans then could be made TX_MANDATORY to enforce
this rule.
> Also, how do you handle the
> possibility that more than one Session Bean may try to access
> the same Entity Bean? Or does your design preclude that?
Exactly, as John described in his original posting, the Session bean is the
only level at which you allow calls from other components. The Entity bean
is only a helper to the Session bean.
> Thanks for any info - Sean
You're welcome, let me know if you see any flaws in this approach.
Regards,
Marcel
>
> >
> > Hi John,
> >
> > Your current architecture resembles ours very much. The way
> > you want to
> > divide functionality across session beans and entity beans,
> > is what we have
> > done using session beans and normal java helper classes. In
> > an upcoming
> > project we plan to try out entity beans instead.
> >
> > Regards,
> >
> > Marcel Schutte
> >
> > > -----Original Message-----
> > > From: A mailing list for Enterprise JavaBeans development
> > > [mailto:[EMAIL PROTECTED]]On Behalf Of John Abbey
> > > Sent: donderdag 6 januari 2000 19:55
> > > To: [EMAIL PROTECTED]
> > > Subject: [EJB-INT] Entity Beans: Approach Validation
> > >
> > >
> > > I've done some development of Session EJB components that have
> > > various services (i.e. Error management, object relationship
> > > management). In addition to the basic "business" services, the
> > > EJBs had methods to access/update the object's data. This was
> > > done manually with our own SQL. The reason we chose Session
> > > beans was because of the immaturity of entity support within the
> > > Application server that we used for development.
> > >
> > > The tool we're using now supports Entity beans and I was
> > > wondering if the following architecture is sound and if any of
> > > people within this community have used a similar approach.
> > >
> > > The methods that I originally coded manually in my Session beans
> > > to perform data access/update could be changed to used very thin
> > > Entity "Data" beans. Basically I would instantiate the Session
> > > bean and when I wanted to retrieve data from it, I would simply
> > > use the object's designated Entity "Data" bean to access the
> > > data. In addition, changes to the object could occur within the
> > > Session bean, be validated, and if validation was successful,
> > > transfer the update logic to the object's designated Entity bean.
> > >
> > > This approach would allow me to used my existing Session objects
> > > for real business functionality, while data access/update could
> > > be offloaded (using CMP) to Entity beans.
> > >
> > > To clarify, this is what each component would be responsible for.
> > >
> > > Session Beans
> > > -------------
> > > Business Methods
> > > Object Validation
> > > Attribute Validation
> > > Object relationship management
> > > Business Error Services
> > >
> > > Entity Beans
> > > -----------
> > > Thin DB access layer used by Session Business Objects
> > >
> > > Thanks so much for any input. I look forward to hearing
> > from all of you.
> > >
> > > John Abbey, AMS eCustomer
> > >
>
> ==================================================================
> =========
> 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".
