I finished an article about how to use JDO in BMP Entity Beans. Here is the link:
Beside that, my point of view on how to integrate EJB's and JDO is given.
Please let me know any comments and suggestions, your input is welcome.
Interesting article. I've been using Kodo JDO (http://www.solarmetric.com) with jBoss, and it works well, although my application is still small...
I think that using an ORM implementation which is independent of the EJB implementation you are using is good from a portability point of view, especially if that ORM implementation is standards based. It's good to see that many vendors are producing JDO implementations.
I have one question. You say:
"Plugging into Entity Beans means pluging into J2EE. Therefore, the example benefits from
the J2EE power: security, transactions, distribution."
Why 'Entity Beans'? In the work I've done so far I simply use JDO from SLSBs, which (I think) gives you the 'J2EE power' that you mention. What is the advantage of using a BMP Entity bean?
> Why 'Entity Beans'? In the work I've done so far I simply
> use JDO from SLSBs, which (I think) gives you the 'J2EE
> power' that you mention.
Yes and no. Whenever the pc is inside an Entity, it is fully "guarded" by the bean, concerning security, transaction, lifecycle, distribution. The disadvantage of this is that the bean is inside the large EJB framework, we all know that these services cost resources. So the client always works with remote objects, inside the bean you can use EJB 2.0 local interfaces.
From within session beans, you can implement without such an overhead. But when dealing with the clients, you have pass pc's to them (Which is not defined by JDO, both serialization and bringing a PC back into the PM for update. We are so sorry about that, our customers want things like that). Or you build "wrappers" around the pc to pass them to the clients. But this is a lot of overhead during development and maintanance. I already finished successfully a project with this tech (session wraps entity), and it was _really_ fast. The guys from the front-end were happy about my serializable transport objects (I call them arrays with methods, because they do nothing more), but the development process itself was not as efficient as I excpected.