-
1. Re: Java data objects(JDO) VS Entity beans
gabrielm Jul 9, 2002 6:09 AM (in response to sk4567)There has been a lot of talk about this on JavaLobby.com or TheServerSide.com
JDOs have JDO-QL to create relationships.
JDOs are not RMI-powered, so you need a Session bean as a facade, if you want to access them remotely. -
2. Re: Java data objects(JDO) VS Entity beans
gabrielm Jul 9, 2002 6:11 AM (in response to sk4567)There has been a lot of talk about this on JavaLobby.com or TheServerSide.com
JDOs have JDO-QL to create relationships.
JDOs are not RMI-powered, so you need a Session bean as a facade, if you want to access them remotely. -
3. Re: Java data objects(JDO) VS Entity beans
psabadin Sep 18, 2002 12:34 PM (in response to sk4567)IMHO, JDO WILL BE the way to go but is not today. Menescu (in his J2EE patterns book) says such and I totally agree. HOWEVER, I launched my project in this direction trying to use JBoss with Castor JDO (Months ago, yet). All worked fantastic ... until the docs and forums could not help me get past some undocumented needs. Had to scrap volumes of work and went pure EJB 2.0 (JBoss). IMO the commercial JDO vendors are not far ahead (if at all) of the open-source products. JDO IS NEW AND IMMATURE - IT WILL COME BUT IS NOT HERE YET.
Bottom line: If you want to get real apps built, don't play with fire and push the technology curve too far (unless you are the infrastructure builder). Your project risk will be huge. Give new technologies time to get settled out AND DOCUMENTED.
For that matter, IMO, EJB 2.0 (CMP, CMR, etc.) is even something of a gamble but too powerful to ignore. I'm sweating through it (Thanks JBoss.org). -
4. Re: Java data objects(JDO) VS Entity beans
ben.alex Nov 12, 2002 5:29 PM (in response to sk4567)IMHO the best current advantage of entity beans is that you can draw on a vast body of knowledge concerning real world implementation. Sure, there are performance matters that need to be considered, but conversely there are many patterns and models to improve performance (direct JDBC for reading, custom dtos, extensive use of client-side caching etc). Add in complex (cross-server) transactional support, and we've found entity beans the way to go for now. There is no shortage of people who have successfully implemented very large projects using entity beans and sound architectural patterns.
Ben -
5. Re: Java data objects(JDO) VS Entity beans
timfox Nov 26, 2002 9:25 AM (in response to sk4567)Yes you can (and I have) built full-on production sites using ejb2 entity beans.
But considering IMO almost all these sites are simply using entity beans as domain objects behind a session facade, then it does seem overkill.
Even with local interfaces, every entity bean method call has to traverse the whole transaction, security, caching, pooling stack (those interceptor thingies in jboss) thus giving a performance hit.
So I would expect to see JDO as a replacement for entity beans as the technology becomes more mature and when sun finally integrates it into j2ee.
For now, entity beans can be fine if done properly - some tools provide ability to avoid the whole j2ee call stack if you know you're not going to need it. (eg mvcsoft).
As I say, we're using JBoss in production with ejb 2 cmp beans and it runs fine.
JDO is the future but not quite yet.
And anyway, if JBoss goes AOP, whether it is an entity bean of a jdo object become dynamically changeable aspects quite separate from the object itself.