Tim Shephard wrote:
> I'm probably flogging a dead horse, but I wanted to pipe in with a me too here.
>
> Using EJBs as facades for our object graphs has been our approach all along. I
>suppose this is what happens in a relational world trying to limp into an object
>oriented one.
>
> Unfortunately, we've found problems with this.
>
> 1. Bean managed persistence was really our only choice. (though I've been told
>toplink was an option at one point).
>
> 2. Some of our sub-objects are Entity beans in their own right. Our approach so far
>is to give facades to these sub objects in certain places. This will be an issue
>when sharing starts to take place.
>
> 3. Caching. Having these complex objects built by complex sql queries begs the
>question of caching. This is an area that EJB is sorely lacking.
>
> 4. Locking causes us a lot of grief as well, when we have to understand how the
>sharing in 2 and whatever caching we can think of in 3 will affect our designs.
>
> To be bold, I'd like to say that EJB is the beginning of a useable object oriented
>database for business applications. The relational model was great, but it only
>handled state, while EJB brings behavior into the mix. Unfortunately, it is fairly
>obvious that the spec is still in its infancy ..
--> Perhaps you may want to consider using a real object-database .... which does
handle complex graphs of objects, object caching, object-level locking and server-side
queries and indexes. EJBs are a far cry from an object-database .... but can serve
well as a component facade for services that
need to access complex graphs of objects.
cheers,
Nipun
>
>
> On Fri, 15 Jan 1999 09:03:34 -0600, Chip Wilson <[EMAIL PROTECTED]> wrote:
>
> >see below
> >
> >> That may depend on the application type. One part of our application
> >> (at the moment fat-client arch.) consists of an asset analysis of our
> >> customers. We have a graph like this (simplified):
> >>
> >> Customer
> >> - Asset
> >> - Asset
> >> - ...
> >> - Liability
> >> - Liability
> >> - ...
> >>
> >> One type of assets is a surety of another person, potentially a customer
> >> too.
> >> So this graph can become quite complex.
> > [Chip Wilson]
> > Consider using coarse grained entity beans to represent sections of
> >the instance graph. The instances that you wish to traverse may then be
> >requested from the coarse grained bean, which will result in them being
> >serialized and sent to the client for "traversal." Changes to the graph can
> >similarly be serialized and sent back to the coarse grained entity in the
> >context of a transaction for updates.
> >
> > In your example, you probably need a coarse grained entity called
> >Customer, which can be found based on various criteria. This customer
> >entity is referred to by proxy, but when you want to traverse the part of
> >the instance graph pertaining to assets, you ask the Customer entity for
> >that section of the graph and work with it on the client.
> >
> >> The ability to traverse this graph is essential for our application. If
> >> EJB
> >> is unsuitable to support this ability, that would be a reason for us to
> >> choose
> >> another technology.
> > [Chip Wilson]
> > I see no reason why EJB cannot meet your needs. I look at entity
> >beans as facades into the domain layer of my application. Each facade has
> >an associated graph of domain instances to which it (the facade) provides an
> >interface. Similarly, session beans are facades into the application model
> >layer.
> >
> > The corresponding instance graphs for multiple entity bean instances
> >must be disjoint, even if they represent the same persistent objects. This
> >will require work to handle concurrent access to the same persistent objects
> >from multiple entity beans.
> >
> > ==========================================================================
> >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".
