"Juan Lorandi (Chile)" wrote:
> Hmmm, this is getting somewhere.
> I fell there's something I can't see yet, help me out. (rest inline).
>
> > > <flame-bait>
> > > Supposedly, the beans provided by third parties will not
> > mutate over the development.
> >
> > Whose development cycle? Yours or theirs? How are you going
> > to stop either?
>
> You don't. You just don't break contract compatibility in the middle of
> YOUR dev cycle(unless you're certain the component version you're using
> won't cut the cheddar for your prj.)
>
My point is you may not have the much control. Take this very real example.
You're working on release 1.1 of your product which used version 2.3 of product
x. You don't have a license to redistribute product x because that would cost
$1M. Before you finish version 1.1 the vendor of Product x ships version 2.4
and stops shipping version 2.3. They've changed their underlying data model but
kept the high level interfaces constant. But since your using CMR to their data
model, your code won't work with version 2.4. You cannot ship version 1.1 of
your product even when it is completed because version 2.3 of Product x is no
longer available.
>
> > Actually, reducing coupling between components will increase
> > the reusability of
> > third party components. This will lead to broader markets,
> > increasing sales, and
> > more R&D.
>
> Because it boils down to coupling of components, right?
Right. Use stable well defined common interfaces and allow each vendor to
extend those as they see fit. Tying into to the low level data model is only
going to mean losts of low volume specialized components.
>
>
> One more question(as I'm still reading EJB 2.0 spec). Loosely coupled
> components(using ejb-ref's) won't be
> able to leverage EQL fully, won't they?
Are you referring to EQL queries over data models from more than one component?
Yes, you probably want to limited in that way. Such queries increase the
coupling again. However, you don't need a firewall here either. If performance
is an issue, it's possible for the vendor of a component to provide entity
beans which are designed to be included in third party jars and provide the
common well defined view of their data model I talked about above. These beans
are distinct from the primary entities in the vendors component and their
separate packaging reflects that fact.
-- Victor
-------------------------------------------------
"I've figured out the difference between scientific
knowledge and business knowledge. Scientific knowledge
depends on facts, logic, and the rigorous testing of ideas
in the laboratory and the field. Business knowledge
depends on the assertion of pet biases with great
confidence and exorbitant billing rates." --Bob Lewis
===========================================================================
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".
