> 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".
