No. This would require a standardization of storage abstractions and query
languages for EJB - the equivalent of the SQL standard for EJB's. What would
be ideal is to split off of the transactional/access/communication component
abstractions from the persistence/query component abstractions in EJB.
If this were done, session beans look an awful lot like servlets. Entity beans
look an awful lot like services.
The persistence can be identified with entities, which gives us the current
(attempted) model of EJB 1.1.
The problem is, not many out there realize that there is a dichotomy here, and
the pieces of the current EJB spec can be manipulated as orthogonal axis of the
design space. The coupling rules between persistence/query and
transactional/access/communication can then be clearly defined.
Making no distinction between these two axis causes a lot of problems by
significantly increasing the complexity of the analysis and vastly increasing
the complexity of the implementation and maintenance of the hydra one has
created.
It's not like there's many ways to boil water. Persistence drives location.
Communication drives locality. Networks partition, machines crash, and things
rarely live forever.
Whoops. I started to rant there.
----- Original Message -----
From: Sachin Aggarwal <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Friday, August 27, 1999 5:04 PM
Subject: Re: Dependent objects vs. Fine grained objects as entity beans?, was
RE: design question with entity beans
I don't want to store OrderItems as a seriazed String attribute in the
database. In business applications there are often some reports that run
directly against the database and they need to be able to access the order
items and their attributes.
In this scenario which should be pretty common I didn't think I could go to
my deployment descriptor for the OrderBean and map a Vector instance
variable to a seperate relational table and provide the "join field" to
connect the orderItems with the order.
Am I missing something ?
> -----Original Message-----
> From: A mailing list for Enterprise JavaBeans development
> [mailto:[EMAIL PROTECTED]]On Behalf Of Chris Raber
> Sent: Friday, August 27, 1999 3:31 PM
> To: [EMAIL PROTECTED]
> Subject: Re: Dependent objects vs. Fine grained objects as entity
> beans?, was RE: design question with entity beans
>
>
> Sachin,
>
> Making OrderItems a dependent object does not necessarily
> imply that you
> must hand code the JDBC for the dependent object. I am not
> sure where this
> intuition comes from, it must be based on the limitations of
> certain CMP
> implementations.
>
> -Chris.
>
> > -----Original Message-----
> > From: Sachin Aggarwal [SMTP:[EMAIL PROTECTED]]
> > Sent: Friday, August 27, 1999 2:55 PM
> > To: [EMAIL PROTECTED]
> > Subject: Re: Dependent objects vs. Fine grained
> objects as entity
> > beans?, was RE: design question with entity beans
> >
> > Thanks for your input on this issue. It's good to see
> different opinions
> > or
> > such issues.
> >
> > From an application/bean developers point of view: if
> you're using CMP it
> > is
> > a somewhat significant step to make orderItems as an
> attribute of Order
> > and
> > use jdbc to populate the attribute on load , and managing
> it's saving to
> > the
> > db on store. This breaks the isolation of the database
> layer from the
> > business objects layer and also makes us have to write
> extra code to do
> > work
> > that we want CMP to do.
> >
> > I'm still not convinced about it causing serious
> performance problems.
> > Further if I understand correctly the performance problem
> will be even
> > less
> > with Java2. Is that what you are saying Imre ?
> >
> > Further I agree that it can create a problem if later the
> object needs to
> > modeled is independent objects rather than dependent objects.
> >
> > Just my two cents worth.
> >
> > Sachin.
> >
> > > -----Original Message-----
> > > From: A mailing list for Enterprise JavaBeans development
> > > [mailto:[EMAIL PROTECTED]]On Behalf Of Imre Kifor
> > > Sent: Friday, August 27, 1999 7:06 AM
> > > To: [EMAIL PROTECTED]
> > > Subject: Re: Dependent objects vs. Fine grained objects as entity
> > > beans?, was RE: design question with entity beans
> > >
> > >
> > > Chris,
> > >
> > > I fully intended to send my posting to the list, I just
> > > mistakenly replied
> > > to Rickard instead of Robert who asked the question in the
> > > first place.
> > > Anyway, my point is that one should strike the right balance
> > > when deciding
> > > on what is dependent data and what is full-fledged entity bean.
> > >
> > > I have noticed that lately there have been a lot of postings
> > > promoting high
> > > granularity, monolithic beans claiming performance advantages
> > > and ignoring
> > > well established object-oriented and systems-level practices.
> > > The situation
> > > almost seems like "since there will be only one page read, my
> > > application
> > > will run much faster if I set the [virtual memory] page size
> > > to 10MB". Which
> > > is very true if you are alone on the machine and all your
> apps fit in
> > > physical memory. It is hardly scalable though.
> > >
> > > On another note, if you look inside an efficient ejb
> > > implementation, you
> > > will notice that managing context pools, passivation and
> > > activation calls
> > > are negligible compared to the large granularity swapping
> > > that needs to take
> > > place with large beans in a highly-loaded system.
> > >
> > > Once again, I am not proposing to reduce the granularity of
> > > beans across the
> > > board, I am only advocating restraint from the "entity beans
> > > must be large
> > > granularity or else..." advice I have been noticing on the
> > > list. The right
> > > heuristic, IMO, for determining whether a chunk of data
> > > should be modeled as
> > > dependent data or a full-fledged bean is whether it should be
> > > shared or not
> > > among other bean instances. After all, the whole point of
> application
> > > servers is to allow efficient sharing of prepared data among
> > > a large number
> > > of clients.
> > >
> > > Stay tuned for my rumbling about "2nd generation entity
> > > architectures"...
> > >
> > > Imre Kifor
> > > Valto Systems
> > >
> > > -----Original Message-----
> > > From: Chris Raber <[EMAIL PROTECTED]>
> > > To: [EMAIL PROTECTED] <[EMAIL PROTECTED]>
> > > Date: Friday, August 27, 1999 8:53 AM
> > > Subject: Dependent objects vs. Fine grained objects as entity
> > > beans?, was
> > > RE: design question with entity beans
> > >
> > >
> > > >Imre,
> > > >
> > > >I realize you intended this message to not go to the list,
> > > but I am glad
> > > you
> > > >sent it here! I respect your opinion. If you don't mind I'd
> > > like to keep
> > > >this debate going for a bit.
> > > >
> > > >I agree that a core consideration is whether OrderEntries
> > > ever becomes a
> > > >"dependent object" of some other bean. If it does, then it
> > > probably needs
> > > to
> > > >manager its own life cycle, and therefor should be an entity
> > > bean in its
> > > own
> > > >right (ownership of life cycle is the principle heuristic
> > > here). However if
> > > >the likely hood of the heuristic is very low, I don't think
> > > the overhead of
> > > >an entity bean is warranted for such fine grained objects.
> > > That overhead
> > > >includes the book keeping the container has to do,
> passivation and
> > > >activation, management of instance pools... Surely we do not
> > > want every
> > > >domain object instance in our application managed in this manner?
> > > >
> > > >Another heuristic is whether "finder" functionality is
> > > required around sets
> > > >of the object which span the owning parent. If this is the
> > > case, then again
> > > >promotion to entity status is warranted.
> > > >
> > > >At the risk of giving you the podium, I would like to
> here more about
> > > >"second generation entity architecture" which IYHO mitigates
> > > the concern of
> > > >fine grained entities being too heavy weight.
> > > >
> > > >Regards,
> > > >
> > > >-Chris.
> > > >
> > > >> -----Original Message-----
> > > >> From: Imre Kifor [SMTP:[EMAIL PROTECTED]]
> > > >> Sent: Friday, August 27, 1999 2:06 AM
> > > >> To: [EMAIL PROTECTED]
> > > >> Subject: Re: design question with entity beans
> > > >>
> > > >> If you ever plan to share OrderEntries among other
> entities (either
> > > Orders
> > > >> or various other derivative aggregates like BackOrdered),
> > > you will be
> > > >> better
> > > >> off not modeling OrderEntry as a dependent object. In my
> > > experience, it
> > > is
> > > >> far more difficult to upgrade a dependent object to bean
> > > status than vice
> > > >> versa. Keep in mind that according to the spec "[...] the
> > > object A fully
> > > >> manages the lifecycle of the [dependent] object B." in 9.1.2.
> > > >>
> > > >> Another issue is scalability. Your specific Order may not
> > > contain a large
> > > >> number of OrderEntries, however, as a more general
> > > principle, the larger
> > > >> the
> > > >> granularity of your beans, the less your beans will
> > > perform under heavy
> > > >> load. Just imagine the swapping your OS would go through
> > > if it had 1MB or
> > > >> 10MB virtual memory pages and not enough physical memory.
> > > >>
> > > >> To be more concrete, the larger your beans are (in number
> > > of methods,
> > > >> number
> > > >> of possible clients and size of state) the less
> advantageous the
> > > >> separation
> > > >> between ejb objects and bean instances is. That is under
> > > heavy load, of
> > > >> course. If you have the luxury to keep everything swapped
> > > in (i.e. in
> > > >> activated state), then this is not an issue.
> > > >>
> > > >> Moreover, for very good reasons, the spec does not allow
> > > passing regular
> > > >> Java objects (i.e. dependent data) by reference among
> > > local beans. If you
> > > >> consider the overhead of serializing/deserializing
> > > dependent data with
> > > >> every
> > > >> call, you most probably will be better of making the call
> > > to the (local)
> > > >> bean instead and sharing the same "dependent data" instance.
> > > >>
> > > >> A good, second generation entity architecture will also
> > > help you if you
> > > >> decide to lower the granularity of your beans. Of course,
> > > with everything
> > > >> else in life, balance is the key :-)
> > > >>
> > > >> Imre Kifor
> > > >> Valto Systems
> > > >>
> > > >> -----Original Message-----
> > > >> From: Rickard Vberg <[EMAIL PROTECTED]>
> > > >> To: [EMAIL PROTECTED] <[EMAIL PROTECTED]>
> > > >> Date: Friday, August 27, 1999 12:57 AM
> > > >> Subject: Re: design question with entity beans
> > > >>
> > > >>
> > > >> >Hey
> > > >> >
> > > >> >Robert Krueger wrote:
> > > >> >> suppose I have to model an entity (say Order), that
> aggregates a
> > > vector
> > > >> >> of other entities (say instances of OrderEntry) and I
> > > would like to
> > > >> >> avoid the performance problem of reloading/storing all
> > > the aggregated
> > > >> >> entities (because there possibly is a large number of
> > > them) on each
> > > >> >> access to methods of entity bean class Order. would it
> > > be ok to put
> > > >> >> methods that access the db directly (like addOrderEntry,
> > > >> >> getOrderEntries) into the entity bean Order and not
> > > model OrderEntry
> > > as
> > > >> >> an entity bean? does this violate the spec or is it bad
> > > design and
> > > >> there
> > > >> >> are much better patterns for modeling the problem
> > > without performance
> > > >> >> problems? are there data integrity problems with
> this approach?
> > > >> >
> > > >> >What Chris and Vlada talked about are possible solutions.
> > > >> >
> > > >> >An Other Solution is to make the OrderEntry an EntityBean
> > > and include
> > > >> >the following method in Order:
> > > >> >public Enumeration getEntries()
> > > >> >{
> > > >> > // Find from OrderEntry home!
> > > >> > return oeHome.findByOrder(this.id);
> > > >> >}
> > > >> >
> > > >> >I.e. do it "lazily", but keep the interface simple.
> > > >> >
> > > >> >/Rickard
> > > >> >
> > > >> >--
> > > >> >Rickard Vberg
> > > >> >
> > > >> >@home: +46 13 177937
> > > >> >Email: [EMAIL PROTECTED]
> > > >> >Homepage: http://www-und.ida.liu.se/~ricob684
> > > >> >
> > > >>
> > > >=============================================================
> > > ============
> > > >> ==
> > > >> >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".
>
>
===========================================================================
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".
