Hi everybody,
I finished an article about how to use JDO in BMP Entity Beans. Here is the link:
http://www.intellibo.com/ibo/international/ejbjdo.pdf
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.
Kind regards,
Thomas
-
EJB and JDO (2 messages)
- Posted by: Thomas Poeschmann
- Posted on: February 26 2002 07:51 EST
Threaded Messages (2)
- EJB and JDO by Tom Davies on February 26 2002 18:21 EST
- EJB and JDO by Thomas Poeschmann on February 27 2002 04:01 EST
-
EJB and JDO[ Go to top ]
- Posted by: Tom Davies
- Posted on: February 26 2002 18:21 EST
- in response to Thomas Poeschmann
Thomas,
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?
Tom -
EJB and JDO[ Go to top ]
- Posted by: Thomas Poeschmann
- Posted on: February 27 2002 04:01 EST
- in response to Tom Davies
Tom,
> 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.
cu
Thomas