You're killing me! Go get 'em Greg...
Regards,
-Chris.
> -----Original Message-----
> From: Gregory Peres [SMTP:[EMAIL PROTECTED]]
> Sent: Tuesday, December 14, 1999 3:17 PM
> To: [EMAIL PROTECTED]
> Subject: Re: Persisting Dependant Data (What about Persisting
> Objets?!)
>
> > 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 problem with this is that most vendors are afraid of the EJB zealots
> who
> scream bloody murder if anyone moves from the specs. If it is not defined
> in the spec venders are going to continue avoiding it. Object persistance
> +
> performance is a dificult task... Cheers to the application server vender
> who can do this.
>
> Standards are meant to be used as a guide line... They are not intended to
> be a law.
>
> The question I have for any WebObjects users or even Apple's
> representative
> reading this message: Why are you not supporting EJB in the product? (I
> think WebObjects is awesome!) Is it because you don't want to have to
> eliminate 90% of your features from the product to meet spec? (The GUI
> framework rules!) I see too many market analysts ignoring the market share
> WebObjects has and not even reviewing it properly because it doesn't
> support
> EJB. A WebObjects vrs EJB paper would be cool.
>
> > 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.
>
> From my understanding of CMP... It is to provide an object oriented
> environment to develop an application that does not burdened me with the
> pain of having to write SQL. When I think of working in a CMP
> environment
> I dream of the ability to persist Entity Beans not just the "data". The
> easiest way I know to make this dream a reality is with an OODBMS. Java
> is
> about objects, NOT rows and columns. Until the general population
> understands this we are not going to see anyone jump up to the real CMP
> challenge: Seamless Object Persistence (I have seen too many vendors
> back
> away from this already.) CMP would be easy to use (from a users
> standpoint)
> if they could persist real objects and not fuss with a RDBMS at all.
> (Dreaming here but, hey... I can! Today app servers already have this
> ability in their products but hide it.)
>
> I am concerned with making flexible, scalable, distributed, fast, object
> oriented applications. Not necessarily the portability of my code. If an
> application server can provide me with an environment that allows me to do
> this, in a timely manner - great! Why would I ever consider switching?
> Why
> do I even care if my model is portable between products? It comes down to
> the time old saying... Use the right tool for the right job.
>
> Where I see EJB as an advantage is for projects that have a lot of
> junior/intermediate developers. For people who know enough to make
> something but, not enough to make it work. (I don't mean this as an
> insult
> to anyone.) Most people from the Smalltalk world (Oh no! Not one of
> them!
> :P) developing large scale server-side applications (Chrysler, OOCL, FP&L,
> ...) would probably gasp at the thought of using EJB. (I have to deal
> with
> a Smalltalker every day. I also get the Java sucks because... speech ever
> day too.) EJB provides a solid starting ground for people. It helps
> people
> move towards the right solution. I applaud EJB for this. But, when it
> comes time to "Jerry McGuire" (show them the money) on a large project can
> EJB really cut-the-mustard? Or, are we going to have to break the spec to
> deliver a solution? (Should I use more analogies to get my point across?!
> hahaha.)
>
> > 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.
>
> Is there any open source groups working on this currently? I have tried
> to
> map a pure object model to RDBMS and it is not easy. (I wasn't even
> close.)
> Persistence has spent most of their companies history perfecting this. I
> don't think it is "easy" by any shot.
>
> > 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.
>
> Why use an RDBMS then? There isn't a single O/R mapper out there that
> does
> not hide my object model (which can have M:M relationships) from the
> method
> of persistence entirely. PowerTier is on the verge of doing this for me
> but, there are still things I have to do in my object model because the
> data-model forces me to. There isn't really much I can do if I want a
> flexible environment to design in unless I use an OODBMS. (I realize I am
> an object purist and I often have give-in to the SQL-demons to do a
> project
> but, I would rather not have to sell my soul every time I do a project. --
> PS: I am still complaining about the natives in Java. :P)
>
> Someone will probably say to use RDBMS because it is the "standard".
> Point
> considered. Why not upgrade the standard to be objects? I think objects
> would make an excellent standard. We all know the reason why we use
> RDBMS:
> Our executives (Who by the way are technical geniuses!) read InfoWorld and
> make us.
>
> Join the object revolution!
>
> > 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.
>
> I just hope that one day we all realize that we are dealing with objects,
> not just data. I realize from a marketing stance, and from a business
> stance that RDBMS are the leaders in data storage arena right now. In a
> galaxy far, far, away... It used to be flat files, and after that came
> IMS... When is the SUN going to set on RDBMSs? (Pun intended.)
>
> When I think EJB I think objects. -> Then I think of persisting them. ->
> Then I think about a RDBMS. Not the other way around.
>
> Java Data Objects (JDO) sounds interesting but, it is too early to bet on
> it's success right now and the FAQ does not make me excited about it's
> potential integration with EJB.
>
> http://www.techmetrix.com/lab/trendmarkers/tmk1299-2.shtml - Link everyone
> may be interested in. I just pulled it from JavaLobby. Haven't read it
> yet...
>
> Greg - Everyone should read more Kent Beck.
>
> PS: We need a meta-class library in Java! :P~
> PPS: Templates?! Have we lost our minds?
>
> > --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
> >
>
> ==========================================================================
> =
> 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".
