Quick answers to two of your questions, not in the order you asked them:
(4) JDO isn't likely to become a first-class member of J2EE, and (3) EB will
continue to evolve to overcome its shortcomings.
Elaboration:
If a significant number of users -- not necessarily an army, but at least an
intelligently vocal minority -- pressure vendors to implement support for
JDO, I have to believe JDO can shed its current status as a political pariah
and earn greater respect through concrete vendor implementations.
However, at the moment it does suffer from lack of vendor support (and even
lack of support from within Sun, to a certain degree) and isn't likely to
become an official J2EE technology for a few reasons; some of the reasons
are good, some are questionable. It seems the basic arguments concern
intrusiveness, complexity, and J2EE vs. J2SE persistence approaches.
One perspective sees JDO as conflicting with the container-based
architecture of J2EE. Any managed persistence scheme will require an
uber-controller, or manager, to inject itself into the lives of persistent
object developers. In the J2EE world, such tasks are assigned to the
container. Now, container vendors might make use of JDO to support the
container's persistence management mechanism (the JDO spec suggests this
very thing), but JDO's persistence manager itself shouldn't require users to
possess any programmatic or metadata-based knowledge of it. In other words,
it shouldn't be intrusive; nothing other than the basic existing container
plugin methods should intrude into developer's lives. With the level of
intrusiveness already defined in terms of the container, why introduce any
further intrusiveness, especially when no new functionality is gained? If
performance is the only reason, then improve performance, don't add new
models.
Too, the container is supposed to make things simple for all the J2EE roles,
requiring a fairly straightforward implementation for vendors (whether
through a literal container artifact approach via codegen and stubgen or
whether through a simple interceptor pattern) and straightforward deployment
for users (ok, so most container deployment schemes don't live up to this).
Another knock against JDO is that it is unnecessarily complex to implement
for vendors and developers. Personally, I disagree with this. Heck, folks
like Rickard can make anything simple to implement, not to mention the fact
that today's CMP is currently at least as complex. Neverthess, it's a common
sentiment that container-based management will evolve to become the most
simplistic of scenarios while other approaches, such as JDO, introduce an
unacceptable layer of complexity and require users to know too much about
the management model.
As CMP evolves to shore up its faults, the attractiveness of JDO as a J2EE
developer's persistence solution diminishes. Perhaps it will remian
attractive in the non-J2EE realm, for J2SE users. Or perhaps the connector
architecture will take even that possible niche. I don't know. But again, I
have to believe that it's up to the users and architects who actually write
applications -- not we architects of servers and containers -- who will make
this decision. The success of Castor (an excellent pseudo-JDO implementation
from the smart folks at http://www.exolab.org) and its integration with
JBoss, for example, is proof that a popular user-crafted project can keep
the JDO initiative alive despite J2EE political and commercial vendor
disapproval.
But will JDO keep up once Sun and vendors evolve and simplify CMP to fulfill
its original promise? In the absence of strong user advocation, I think not;
not as long as container-based J2EE prospers as a brand as well as a
technology, and not as long as JDO doesn't change to mesh with that model.
Sean
-----Original Message-----
From: A mailing list for Enterprise JavaBeans development
[mailto:[EMAIL PROTECTED]]On Behalf Of Anup Maliyackel
Sent: Monday, March 26, 2001 11:50 AM
To: [EMAIL PROTECTED]
Subject: Re: Entity beans vs DAO(Data Access Objects)
Hi
As the person who started this thread, I still haven't got an answer to my
original query.
1)Everybody (including sun) agrees to some extent that entity beans are
performance bottlenecks and they don't scale well. Can somebody elaborate
on this?
2)How do different implementations of Entity beans differ in terms of
clustering in different app. servers?
3)If entity beans are not the way to go,what next? ; Session Beans+DAO; JDO
etc?
4) what is the status of JDO specs? Can we expect something anytime soon?
Regards
Anup
James Cook
<[EMAIL PROTECTED] To:
[EMAIL PROTECTED]
M> cc:
Sent by: A Subject: Re: Entity beans
vs DAO(Data Access
mailing list for Objects)
Enterprise
JavaBeans
development
<EJB-INTEREST@JAV
A.SUN.COM>
03/26/2001 08:37
AM
Please respond to
A mailing list
for Enterprise
JavaBeans
development
----- Original Message -----
From: "Filip Hanik" <[EMAIL PROTECTED]>
> you don't have to lock a stateless session bean since only one client can
> access it (theoretically) at one time :)
Your original statement, "well, consider a clustered server environment
where
you will have to keep transactional locks synchronized across servers in a
distributed transaction." refers to the nature of a distributed transaction
and
the "weight" it brings to the entity beans involved. I am pointing out that
this
distributed transaction and the involvement of XA resources and a
transaction
manager will be present even if you use Stateless Session Beans. It is not
a
valid argument regarding the weight of Entity Beans. :)
If you are referring to something else, such as synchronized instances of
Entity
Beans within a container, this is not the way it works. At least I haven't
seen
an EJB container yet that attempts to synchronize EB instances across VMs.
As a
matter of fact, WebLogic was the only container that synchronized instances
of
Entity Beans *within* its container.
jim
===========================================================================
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".
