O/R Mapping and EJBs

[JeanLouis Marechaux]

hi all,
Do you have experiences with O/R mapping tools like Toplink or CocoBase in a professional environment ?
Is one better than the other ? What should I consider in order to choose one rather than the other for my applications (AppServer=WebSphere 4).
Any information or link to info are welcome.
Thanx.

[Bill Siggelkow]

I have a fair amount of experience with CocoBase and had mixed results. To get the most bang for the buck out of CocoBase you probably want it to generate the EJBs ... however, I had problems with the generated code ... sometimes things didn't update or delete as expected ... also, maintaining the mappings can get hairy if you have lots of FK relationships ...
If I had to make a choice these days, I would go either straight CMP and/or BMP with DAO objects. Personally, I have used DAO type objects with BMP and found this to be a good practice. You can use the DAOs both for the Entity Beans and directly from the stateless session beans for faster reads.
I don't have experience with TopLink.

[ruilin yang]

A related question:
Does CMP of EJB 2.0 support table relationships ?
Can CMP of CMP map Object/Tables ?
Thanks
Ruilin

[JeanLouis Marechaux]

Another related question.
Why should I use an O/R mapping tools instead of the EJB mechanism for persistence ?

[Jim Bertorelli]

Originally posted by Bill Bailey:
Another related question.
Why should I use an O/R mapping tools instead of the EJB mechanism for persistence ?

You need to use ORMapping tools when you already have a database ready. Say, if you are webenabling a legacy application, you already have your database stuff ready. But when you try to use it in your OO paradigm, your application objects do no match with the relational structure. OOMapping tools help you interface your Objects with the relational tables.
EJB's mechanism is useful when you a building a new system altogether. In this case, you'll take care that your objects match the tables.
HTH,
Jim.

[ruilin yang]

Entity beans are best implemented as coarse-grained objects due to the hight overhead associated with each entity bean. Therefore, use composite entity to model, represent, and manage a set of interrelated persistent objects rather than representing them as individual fine-grained entity object beans. I fully understand the advantage of using the coarse-grained composite entity bean.
However, my questions are:
1) what are the guidelines to do the design in the above manner?
2) how to decide/group entity objects to implement as a composite entity bean? What are strateges ?
3)In order to implement composite entity bean, is it true we can only use BMP or CMP (of EJB 1.1)can do it, too ?
4) The present O/R mapping tools are still useful to implement the composite entity bean ? Or we have to manually figure out the mapping and implementation of the composite entity bean ?
I am not clear about the implementation. I need help from the book author to give me some lights.
Thanks
Ruilin

[This message has been edited by ruilin yang (edited December 05, 2001).]
[This message has been edited by ruilin yang (edited December 05, 2001).]

[Kyle Brown]

Originally posted by ruilin yang:
Entity beans are best implemented as coarse-grained objects due to the hight overhead associated with each entity bean. Therefore, use composite entity to model, represent, and manage a set of interrelated persistent objects rather than representing them as individual fine-grained entity object beans. I fully understand the advantage of using the coarse-grained composite entity bean.

Well, that used to be true with EJB 1.0 and to a lesser extent 1.1. However,with EJB 2.0 this is certainly no longer true. Now that we have local EJB's Entities are much lighter weight objects. In fact, Ed Roman and Floyd Marinescu's new EJB patterns book (upcoming) list the coarse-grained composite Entity as an AntiPatternn for EJB 2.0. Likewise, Richard Monson-Haefel is a proponent of fine-grained local EJB's in 2.0. Now, if you had an application server that handled things fine-grained Entity EJB's in 1.1 anyway (like WebSphere) it wasn't quite as bad as it was in other servers, so I'd simply have to say "it depends..."

[BOLD]
However, my questions are:
1) what are the guidelines to do the design in the above manner?
2) how to decide/group entity objects to implement as a composite entity bean? What are strateges ?
3)In order to implement composite entity bean, is it true we can only use BMP or CMP (of EJB 1.1)can do it, too ?
4) The present O/R mapping tools are still useful to implement the composite entity bean ? Or we have to manually figure out the mapping and implementation of the composite entity bean ?
I am not clear about the implementation. I need help from the book author to give me some lights.
Thanks
Ruilin

[This message has been edited by ruilin yang (edited December 05, 2001).]
[This message has been edited by ruilin yang (edited December 05, 2001).][/B]

------------------
Kyle Brown,
Author of Enterprise Java (tm) Programming with IBM Websphere
See my homepage at http://members.aol.com/kgb1001001 for other WebSphere information.

[ruilin yang]

Kyle,
Thanks for your update me.
Than what are advantages of fine grained EJB in EJB 2.0 ?
Can I image that the advantages are:
1) less burden on developer because the mapping between O/R has become straightforward and he/she does not need to figure out the mapping anymore ?
2) We can use CMP for most problems since mapping become simple: each row int a table to an entity bean ?
3) However, I image the fine grained entity bean still causes too much coupling between objects. This seems we still need coarse grained entity bean or object ?
I still lack of understanding on this. Please give me more detailed explanation ?
Thanks
Ruilin

[JeanLouis Marechaux]

Here are some points I need to clarify.
1) I don't need O/R mapping if I only plan to use BMP (and no CMP at all)
2) Can I use CMP without any O/R mapping tool ?
(I guess Yes, but then, there are limitations I would like to list)
3) If I plan to move to EJB 2.0, does a O/R mapping tool will still give me added-value ?
Thanks in advance Gurus
[This message has been edited by Bill Bailey (edited December 05, 2001).]

[JeanLouis Marechaux]

5) O/R mapping seems to be proprietary.
TopLink has a release for WebLogic and one for WebSphere, so changing the app server means a TopLink release change.
In that point , CocoBase seems to be a better product.
Any comments and opinions ?

[Thomas Paul]

Originally posted by Kyle Brown:

Well, that [implementing entity beans as coarse-grained objects] used to be true with EJB 1.0 and to a lesser extent 1.1. However,with EJB 2.0 this is certainly no longer true.

Wouldn't this tie a bean to a particular physical implementation? The Sun book, "Core J2EE Patterns" which just came out doesn't agree with this conclusion. I just finished reading Richard Monson-Haefel's book, "EJB - Third Edition" and could find nothing that would lead one to believe that EJB 2.0 entity beans should be fine-grained objects.

[JeanLouis Marechaux]

Originally posted by Thomas Paul:
could find nothing that would lead one to believe that EJB 2.0 entity beans should be fine-grained objects.[/B]

Thomas,
Don't you think the local interface has been introduced to allow fine-grained objects ?

[ruilin yang]

With the local interface and enhanced CMP of EJB 2.0, are the following still advantages for coarse grained Bean :
1) reduced Database Schema dependency
2) Improved manageability by reducing Entity Bean
3) Facilitates Composite Value Object Creation
4) Eliminates Inter-Entity Relationships
Please comments
Ruilin

[JeanLouis Marechaux]

Anyone for a CMP and EJB 2 question ?
Ruilin, it seems we are a little bit stuck with our mappings interrogations.
If someone have useful links about mappings, EJB 2 and CMP, please let us know.
Thanks

[Thomas Paul]

Originally posted by Bill Bailey:
Thomas,
Don't you think the local interface has been introduced to allow fine-grained objects ?

No. It was introduced to allow one EJB to access another without doing a remote call. Since many of the server vendors were providing this functionality in a vendor-specific way, this avoids the problem of adding vendor-specific code to your applications.
[This message has been edited by Thomas Paul (edited December 06, 2001).]

[JeanLouis Marechaux]

Originally posted by Thomas Paul:
[b] No. It was introduced to allow one EJB to access another without doing a remote call. Since many of the server vendors were providing this functionality in a vendor-specific way, this avoids the problem of adding vendor-specific code to your applications.
B]

Thanks Thomas.
It seems I had misundertood the local Interface concept.
My understanding is now the the Local interface can be used for Inter-component calls, when and only when the components are in the same EJB container.
So it does not address the client to EJB calls (fine-grained/coarse-grained)
Is that correct ??
If yes, something is puzzling me.
What occurs when you have 2 App server (load balancing).
You never know which one will , so you can't forecast the use of a Local or Remote interface ??
I really need to buy an EJB 2.0 book... Is that covered in the book you won Thomas ?

[This message has been edited by Bill Bailey (edited December 07, 2001).]

[Thomas Paul]

Local interfaces can only be used between EJBs when they are in the same container. Servers that provide load-balancing are required to handle the issue of remote vs local without the programmer having to do anything special. I would imagine most servers would be written to simply give you an EJB on the same physical server when you make a local request.
I don't know if that is covered in the book I won (I haven't read it yet) but it is covered in Enterprise JavaBeans - 3rd Edition

[JeanLouis Marechaux]

Originally posted by Thomas Paul:
.....and could find nothing that would lead one to believe that EJB 2.0 entity beans should be fine-grained objects.

(About Kyle comment)
Thomas, could you give me your opinion about this.
If we admit that calls between objects in the same container are done using the local interface, then we can admit this kind of call can be done using a fine-grained pattern.(no network overhead here).
Moreover, a client should call Entity Bean only through a session bean (facade). Then, in this approach, remote invocation does not concern Entity beans but only Session bean.
Can't we conclude then that in EJB 2.0, entity beans should be fine-grained objects because they should be accessed by local objects only. ??

[This message has been edited by Bill Bailey (edited December 07, 2001).]

[Thomas Paul]

The reason that I disagree with this has nothing to do with remote vs. local. The overhead of creating a single EJB as compared to a regular Java object is about 20:1.

[JeanLouis Marechaux]

Originally posted by Thomas Paul:
The reason that I disagree with this has nothing to do with remote vs. local. The overhead of creating a single EJB as compared to a regular Java object is about 20:1.

I'm sorry but I've missed something in your explanation.
If you have a couple of minutes, could you explain a little bit further please ?
Do you mean you recommend to access Entity beans thru Java objects and no thru session beans ?

[Thomas Paul]

Originally posted by Bill Bailey:
I'm sorry but I've missed something in your explanation.
If you have a couple of minutes, could you explain a little bit further please ?
Do you mean you recommend to access Entity beans thru Java objects and no thru session beans ?

No. I recommend that you use coarse-grained entity beans rather than fine-grained entity beans. And I also recommend that you avoid using entity beans altogether unless you need their functionality.
Let's imagine a situation where a user does a search and gets 50 hits from a table. Does it make sense to create 50 entity beans and then serialize them in order to send them to a servlet or JSP? Or does it make more sense to simply create 50 Java objects and serialize them to send them to the client? I think the latter makes a lot more sense. (By the way, the worst possible thing to do would be to send 50 remote references to the servlet as every getName(), getAddress() would be a remote call!)
As far as coarse-grained vs. fine-grained, I simply don't understand the argument that an entity bean should represent a row in a table. This ties a logical object (the entity bean) to a physical implementation (a database table). Now any change to the database would require changes to all the entity beans. And since it is quite common to have one logical piece of information made up of data from multiple tables, this means that the session beans are forced to manipulate multiple entity beans in order to perform one simple function.

[JeanLouis Marechaux]

Thanks Thomas and the thers for all the comments I received.
I gonna open another topic soon, 'cause this one does not deal with O/R mapping anymore, but rather with J2EE pattern using EJB 2.0.
And I still have a lot of question about EJB 2.0 in practice....

[Kyle Brown]

Originally posted by Thomas Paul:

Originally posted by Bill Bailey:
[b] Thomas,
Don't you think the local interface has been introduced to allow fine-grained objects ?
-------
No. It was introduced to allow one EJB to access another without doing a remote call. Since many of the server vendors were providing this functionality in a vendor-specific way, this avoids the problem of adding vendor-specific code to your applications.
[This message has been edited by Thomas Paul (edited December 06, 2001).]

Thomas,
That's not entirely true. It's one of the reasons that they were introduced, but not the only one.
Remember back to the first "final release" of EJB 2.0? It had this abomination in it called "Dependent objects". These were fine-grained objects that you could query (with EJB-QL) and build relationships with, but which were not EJB's, and which could not be exposed outside of the Entity EJB that contained them.
This proposal was soundly rejected by the vendors and the community, and they sent Sun back to the drawing board. What Sun came up with instead (by dusting off an older proposal) was the Local EJB idea. That way you have lighter-weight objects that you can form relationships with, and that you can query on with EJB-QL. It's not a coincidence that the introduction of Local EJB's corresponded with the death of Dependent Objects. One is a replacement for the other. So yes, Local EJB's WERE meant to be fine-grained objects, and to map to (in some cases) single database tables.
When you consider the type of EJB relationships, and the way in which they're defined, about the only thing that makes sense is that you're thinking about mapping them to foreign keys in a relational database.
In fact, Richard Monson-Haefel's new edition of Enterprise JavaBeans gives a wonderful set of examples (in Chapter 7) of how these relationships map directly to foreign-key relationships in database tables. He even addresses the "Cascading-delete" modifier, which only makes sense in this regard.

Kyle

------------------
Kyle Brown,
Author of Enterprise Java (tm) Programming with IBM Websphere
See my homepage at http://members.aol.com/kgb1001001 for other WebSphere information.
[This message has been edited by Kyle Brown (edited December 10, 2001).]