Sorry about that. The technique is along the lines of the "Composite"
pattern. But, as with anything else useful, it also has "Decorator" and
"Iterator" flavors. Or if you prefer, think about it as a simply extending
the java collections to ejb.
Imre Kifor
Valto System
-----Original Message-----
From: James Cook <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED] <[EMAIL PROTECTED]>
Date: Saturday, February 27, 1999 1:59 PM
Subject: Re: Inter-Object Business Rules & EJB Transactions
>I'm not sure I understand completely. Is there a design pattern that I may
>refer to in order to read more about this technique?
>
>jim
>
>> -----Original Message-----
>> From: A mailing list for Enterprise JavaBeans development
>> [mailto:[EMAIL PROTECTED]]On Behalf Of Imre Kifor
>> Sent: Saturday, February 27, 1999 12:27 PM
>> To: [EMAIL PROTECTED]
>> Subject: Re: Inter-Object Business Rules & EJB Transactions
>>
>>
>> I would choose a very different solution while still sticking to the EJB
>> paradigm. In addition to having only individual "person" objects (either
>> session or entity beans, it doesn't matter), try modeling collections of
>> persons as well. You can easily create generic EJBSets and even EJBTrees
>> that you can later subclass to get, for example, the tree of
>> subordinates in
>> your "People project". As soon as you start modeling sets (or
>> aggregates) of
>> elements as ejb objects you open up your designs to quite powerful yet
>> simple and efficient mechanism. Using sets or trees of people, you can
>> update your database with one ejbStore operation while still
>> propagating the
>> changes to all individual elements in your hierarchy of ejb
>> objects. And you
>> do all this in the ejb framework, not using *any* proprietary server
hooks
>> or native stuff.
>>
>> We have used the techniques like the above successfully with our clients
>> where set access and aggregate operations were just as frequent (and
>> absolutely required) as individual element access and operations.
>>
>> <PITCH>
>> We will be adding samples using our (quite simple) EJBSet and EJBTree
>> bundled beans to address aggregation and set operation requirements in
the
>> EJB framework.
>> </PITCH>
>>
>> Hope this helps,
>>
>> Imre Kifor
>> Valto Systems
>>
>> -----Original Message-----
>> From: James Cook <[EMAIL PROTECTED]>
>> To: [EMAIL PROTECTED] <[EMAIL PROTECTED]>
>> Date: Friday, February 26, 1999 8:46 AM
>> Subject: Re: Inter-Object Business Rules & EJB Transactions
>>
>>
>> >Just a general comment about the direct JDBC method here:
>> >
>> >I agree that if this was about pure performance I would want to
>> modify the
>> >database directly. The question becomes, why use objects if we intend on
>> >modifying the database? (Please don't expound on the other advantages of
>> >objects, I am trying to make a point :-)
>> >
>> >My business objects contain business rules. I cannot simply modify the
>> >database when I feel like it, unless the same business rules are
>> implemented
>> >there. This is what we are trying to get away from. I realize that the
>> >example below may seem simple enough to go direct to the db, but I could
>> >have complex business rules behind such a simple change. I don't know of
>> any
>> >way to make these changes without going through the object itself.
>> >
>> >That stated, please agree or disagree with this. If agree, the previous
>> >questions/dilemmas still stand.
>> >
>> >thanks,
>> >jim
>> >
>> >> -----Original Message-----
>> >> From: A mailing list for Enterprise JavaBeans development
>> >> [mailto:[EMAIL PROTECTED]]On Behalf Of Jim Frentress
>> >> Sent: Thursday, February 25, 1999 7:36 PM
>> >> To: [EMAIL PROTECTED]
>> >> Subject: Re: Inter-Object Business Rules & EJB Transactions
>> >>
>> >>
>> >> > -----Original Message-----
>> >> > From: James Cook [SMTP:[EMAIL PROTECTED]]
>> >> > Sent: Wednesday, February 25, 1998 1:31 PM
>> >> > To: [EMAIL PROTECTED]
>> >> > Subject: Inter-Object Business Rules & EJB Transactions
>> >> >
>> >> > Imagine an organizational chart for your company comprised of
>> >> many People
>> >> > EJBs. Some People have descendants that represent their
>> >> subordinates, and
>> >> > these people have subordinates, etc. I have multiple clients
>> >> that can make
>> >> > changes to these objects.
>> >> >
>> >> > Suppose I have a business rule whereby, if a People EJB gets a
>> >> bonus, the
>> >> > same
>> >> > bonus is applied to all of his/her subordinates. (Wish this was real
>> >> > life!)
>> >> >
>> >> > Stage set, here are the questions:
>> >> >
>> >> > 1) Would this business rule be enforced within a session EJB or
>> >> the People
>> >> > (entity) EJB?
>> >> >
>> >> i'd do this with a direct jdbc call. no point in
>> touching all the
>> >> affected entity beans directly to accomplish this (what if there
>> >> are 10,000
>> >> subordinates - a single jdbc call will definitely be better).
>> your choice
>> >> where you attach the method for doing it - ejbean or not.
>> >>
>> >> > I will assume a session for the next questions...
>> >> >
>> >> > I can imagine a recursive routine that applies the bonus to the
>> >> People EJB
>> >> > in
>> >> > question, gets a list of children, and calls itself for each child.
>> This
>> >> > will
>> >> > effectively traverse the branches.
>> >> >
>> >> see above, don't waste time touching all the entity
>> beans. do it
>> >> directly to the pstore and let the beans sync themselves. note
>> that your
>> >> container must support this and you must have this support
>> turned on (ie
>> >> Tengah dbIsShared must be set to true or this won't work).
>> >>
>> >> > 2) Do the EJB transactions provide me with protection to prevent
>> someone
>> >> > else
>> >> > from modifying the first People EJB while I'm off changing children.
>> >> >
>> >> if you start a tx and make a mod that record in your
>> >> pstore will be
>> >> locked (implementation of the lock varies by vendor and even
>> >> product version
>> >> within vendor).
>> >>
>> >> > 3) Likewise, must I acquire some kind of lock on my entire set of
>> People
>> >> > objects prior to making my changes. What if someone deletes a People
>> EJB
>> >> > after
>> >> > I get a list of children?
>> >> >
>> >> see 1st note about a better method.
>> >>
>> >> > 4) If one of my child People EJBs cannot have a new bonus
>> >> applied (due to
>> >> > some
>> >> > other business rule) will/can all of the other object
>> changes be rolled
>> >> > back?
>> >> >
>> >> yes, your update is atomic (ACID rules will be followed
>> >> or you need
>> >> to switch containers).
>> >>
>> >> > 5) One of the major strengths of the EJB framework is the concept of
>> >> > transactions. Are there any online resources to learn more
>> >> about how these
>> >> > work?
>> >> >
>> >> JDBC spec. TPC specs.
>> >>
>> >> > Thanks,
>> >> > jim
>> >> >
>> >> >
>> >>
>>
==========================================================================
>> >> > =
>> >> > 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".
