Chris,
My requirement were based more out of the need to hide data sources from my
bean code. However, app server portability would be nice. Different
departments in large organizations often go out pick their own products.
Sharing components would be nice.
Also, a standard based solution that makes cmp more powerful would also be
nice. Its much easier from a development / management point to deal with a
single vendor integrated solutions than multi-vendor where you have to hold
your breath to see if they talk to each other in complex situations.
Regards,
Tom
>From: Chris Raber <[EMAIL PROTECTED]>
>Reply-To: A mailing list for Enterprise JavaBeans development
><[EMAIL PROTECTED]>
>To: [EMAIL PROTECTED]
>Subject: Re: Persisting Dependant Data
>Date: Tue, 14 Dec 1999 09:45:22 -0800
>
>Chip,
>
>I think we are in violent agreement. My understanding is that future EJB
>specs will tighten down CMP w/regard to dependent objects.
>
>Also there is a new group rising from the ashes of ODMG which address
>object
>persistence services (both OR mapping and ODBMS). A future where EJB layers
>on top of a standard Java object persistence specification is likely.
>
>Regards,
>
>-Chris.
>
> > -----Original Message-----
> > From: Chip Wilson [SMTP:[EMAIL PROTECTED]]
> > Sent: Tuesday, December 14, 1999 9:09 AM
> > To: [EMAIL PROTECTED]
> > Subject: Re: Persisting Dependant Data
> >
> > Hi Chris,
> >
> > I agree that there is no standard way to implement CMP. I'm not
>convinced
> > that
> > the spec should specify a standard way to accomplish this. This seems
>to
> > me to
> > be an area for product differentiation in the functionality dimension.
> >
> > The flexibility Tom didn't want to lose was not the ability to change
> > application servers, but rather the ability to change datasources
>without
> > impacting his entity bean code. I think a good CMP implementation, even
> > if
> > proprietary, could offer this kind of flexibility, arguably making it
> > superior
> > to BMP with regard to this one feature.
> >
> > On the other hand, it doesn't seem hard to implement a BMP framework
>that
> > would
> > allow you to change datasources without affecting the entity beans, so I
> > could
> > make the case that a good BMP implementation could offer this
>flexibility
> > as
> > well.
> >
> > In an exchange I had with Tom off the list, we discussed this further
>and
> > I
> > encouraged him, as I do everyone, to implement entity beans using BMP
> > until
> > better implementations of CMP are available. If an app server provided
> > all of
> > the complex mappings necessary to map a domain model to a relational
> > database, I
> > would not rule out CMP merely because it was proprietary and
>non-portable
> > to
> > other app servers.
> >
> > I would think that the most we could hope for from future specs would be
>a
> > portable way of specifying the meta data for mapping the domain objects
>to
> > a
> > given dB schema.
> >
> > --Chip
> >
> > Chris Raber wrote:
> >
> > > Chip,
> > >
> > > I agree with your sentiment. However, there is no standard way for a
>CMP
> > > implementation to provide the functionality you suggest (the spec
> > doesn't
> > > deal with this), so you are no better off using a CMP implementation
> > than
> > > using BMP and an OR tool.
> > >
> > > -Chris.
> > >
> > >
> > > > The flexibility you gained came from using CMP. The fact that you
>had
> > to
> > > > hand-code the persistence of dependant objects came from using a
>poor
> > > > implementation of CMP.
> >
> > Original Post:
> >
> > >
> > > > > What i have been doing thus far is
> > > > > adding the persistence code to the entity bean and let it control
> > the
> > > > > dependant object. Is this the right way of doing things?
> > > > >
> > > > > The thing that i don't like about that approach is that the Order
> > bean
> > > > has
> > > > > the flexibility of having its data source changed without impact
>to
> > the
> > > > > component. If the component now contains hand coded persistance
> > code, it
> > > > > then become unportable. I would be very keen on knowing how is
>the
> > best
> > > > way
> > > > > to approach this common problem.
> > > > >
> > > > > thanks in advance.
> > > > > Tom << File: Card for Chip Wilson >>
>
>===========================================================================
>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".
>
______________________________________________________
Get Your Private, Free Email at http://www.hotmail.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".
