EJB entity CMRs

[Vladas Razas]

Since my EJB experience comes from HF EJB I will ask here.
It says that if you establish container managed relationship (CMR) between 2 beans you must have local interfaces. If I take sample from book: Movies and Directors. Each movie has 1 director and each director might have many movies. Does that mean if I want to have remote access to both Movies and Directors beans I have to have 2 interfaces for each of them: local and remote?
Best regards

[Magnus Stattin]

Hello Vladas
In a real world situation you will probably have Entity beans behind a layer of Session beans that act like facade for the Entity beans. This is made for performance reasons to limit the number of expensive remote calls.
This architectural design is called the session facade pattern, see:
http://java.sun.com/blueprints/patterns/SessionFacade.html
This way you can have relations between the entitybeans and still making that information availible to remote clients through the session bean facade.
Best
/Magnus

[Philippe Maquet]

Hi Vladas,

Does that mean if I want to have remote access to both Movies and Directors beans I have to have 2 interfaces for each of them: local and remote?

Yes, but only if you want so. For the rest, I agree with what Magnus wrote above.
Best,
Phil.

[Vladas Razas]

Thank you guys! Heh, I doubt EJB is the best design I ever seen. There are so many inconveniences. But it works and it does a lot of job. Just I believe it could be more "beautiful".
They could remove remote interfaces from entity beans
Regards

[Magnus Stattin]

I agree with you that the remote interfaces for entitybeans are somewhat obsolete. In EJB 1.1 only remote interfaces existed and some of the design flaws that makes EJB less beautiful than it could have been is an inheritage from EJB 1.1.
Some people are for reason like this reluctant to use entitybeans at all (See Rod Johnson - J2EE design and development, one of the best books I have ever read on this subject). He and others argue that Entitybeans will never be distributed object by themselves and their transactions will be managed by the sessionbeans in front them. With those two advantages taken away you might just as well use a more beautiful and simpler solution for the database access such as Hibernate.
Best regards
/Magnus

[Vladas Razas]

What's the Hibernate?
I think entities are still big part of EJBs. If there were no entities, I think there would be much less reasons to use EJB at all and switch to something lower lvl like RMI, RMI-IIOP. But IMO EJB is a thing that not only needs adding new features.. I believe it has a lot of potential in improving it's own design.
Put CMR aside is there any more reasons not to expose/make entity remote interface? I am still wandering. If I would have entity which I am sure is not going to participate in CMR, is it still wise to implement facade for them?
My best regards!

[Magnus Stattin]

I think entity-bean is a big part of EJB and will remain so. At the same time it is the most controversal part of the EJB. Hopefuly it will be improved further in the future.
Hibernate is an opensource project for object/relational persistence that solves many of the same problems as entity-beans do. It is much more lightweight and have support for things as transactions and caching.
http://www.hibernate.org
Even if you use something like hibernate for persistence you can still session-beans to get the benefit of component-based architecture and location transparancy.
I believe that it always is a good reason to use the session facade, this is a attempt to show why.
It is two things when it comes to EJB that have a much bigger impact on performance than other things. The first thing is remote calls that can take up to 100 times longer than a local call. The other thing is roundtrips to the database. By designing the system so that these calls and roundtrips are as few as possible will improve the overall performance and limit the cost of hardware.
If you give a remote client a reference to say a movie-bean and that client need to get all fields from that movie, as name, description, year, director and so on, the client needs to make separate remote calls to get them. At the same time every method call to get a field will run in a separate transaction which will force the container to syncronize the bean with the database before and after each call. You could make the client start the transaction but it would make it to involved in the beans business and make them too tightly coupled.
With a session-bean acting as a facade the calls to get all fields could be made local between the session-bean and the entity-bean. The session-bean would then populate a value object and send that back to the remote client.
That would make only one remote call and the session-bean would start the transaction and the entity-bean method would take part in that transaction so it would mean only one database roundtrip as well.
/Best regards
[ December 13, 2003: Message edited by: Magnus Stattin ]

[Vladas Razas]

but we have those home business methods for batch operations..