aspose file tools*
The moose likes EJB Certification (SCBCD/OCPJBCD) and the fly likes Entity Relationships Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of Soft Skills this week in the Jobs Discussion forum!
JavaRanch » Java Forums » Certification » EJB Certification (SCBCD/OCPJBCD)
Bookmark "Entity Relationships" Watch "Entity Relationships" New topic
Author

Entity Relationships

Matt Gaunt
Ranch Hand

Joined: Sep 05, 2003
Posts: 34
Hi All,
I have been going through the Head First book and am a little confused regarding Entity beans and CMRs.
On page 386, it says, 'The type of a relationship field MUST be the local component interface of the entity'. What I'm unsure about is the LOCAL part of this statement. Is it saying that relationships can only be made with local Entity components, as in components interfaces which extend EJBLocalObject, as opposed to extending EJBObject? This doesn't seem right to me, but if someone could clarify, that would be great.
Best Regards
Matt Gaunt
Kathy Sierra
Cowgirl and Author
Ranch Hand

Joined: Oct 10, 2002
Posts: 1572
Howdy, yep, you can have a container-managed relationship with ONLY the *local* component interface of another entity bean. So you're right, that means with something that extends EJBLocalObject and NOT EJBObject (or, a Collection of things that extends EJBLocalObject, when the relationship partner has a multiplicity greater than one.)
This restriction is what gives 2.0 Containers the ability to do CMR in the first place (in EJB 1.1 you couldn't do it); it means that both references are within the same JVM, so the Container can do all of the management it needs to, in whatever way it chooses, since it is fully in charge of the participants.
It might seem like a restriction, and it is in the sense of not allowing you to shift the different beans into different nodes. But... that's why local interfaces should be thought of as a very special case, used almost ENTIRELY for CMR, and not used for just general performance optimization.
Good question, though. The EJB 2.0 team agonized for a long time over this whole local interface and CMR thing. The entire specification was nearly final before they practically wiped it clean and started over to get what they have today.
Cheers,
Kathy
Matt Gaunt
Ranch Hand

Joined: Sep 05, 2003
Posts: 34
Thanks for the quick reply Kathy. If this is the case, would that mean for an application involving a person entity bean and a school entity bean, I would require a remote entity bean and a local entity bean to represent the person and the school if they have a 1 to many relationship.
So that a remote client could get a component interface to a person, which would have a CMR to the schools local component interface. Or on the other hand, the remote client get a component interface to a school, which would have a CMR to the persons local component interface.?
So to represent the two entity types, we would actually have 4 entity beans?
Best Regards
Matt Gaunt
Kathy Sierra
Cowgirl and Author
Ranch Hand

Joined: Oct 10, 2002
Posts: 1572
Howdy -- you're almost there
But for the two entity *types* you still need only two entity *beans*. The difference is that you'd need four INTERFACES. So for each bean, you could have both a local and remote interface, if you want to expose the bean to both local and remote clients.
So for example, you could have:
1) Person bean
2) School bean
1) Local interface for Person, that School bean uses for its CMR field
2) Local interface for School, that Person uses for its CMR field
1) Remote interface for Person, that a remote client with a reference to a Person will use
2) Remote interface for School, that a remote client with a reference to a School will use
OK, but having said all that... in general, that's not the way you'll probably want to do it. From a good practices perspective, you'll generally want something more like:
1) Local interfaces for both Person and School. They both uses these to reference each other in CMR fields.
2) Remote interface for a Session bean that remote clients use when they want to access some service that makes use of Person and/or School.
3) Then the real question becomes, HOW does the Session bean access Person and School? Here's where your real choice is:
* Local -- benefit is performance, and chances are, the session bean's sole purpose in life is to act as a service that uses these beans
* Remote -- benefit is that you are not forced to keep the entity beans and this session bean on the same node in the network.
So... you STILL might want a Remote interface for Person and School, but generally this is exposed to a Session bean who is acting on behalf of another client, rather than exposing the entity beans (even with a Remote interface) directly out to the world.
But in either case, you still have only TWO entity beans -- Person and School. They don't have to know or care how others are accessing from the outside; they care and know ONLY that they refer to each OTHER through local interfaces, since they enjoy a "special" relationship (i.e. CMR).
cheers,
kathy
Philippe Maquet
Bartender

Joined: Jun 02, 2003
Posts: 1872
Hi Matt,
So to represent the two entity types, we would actually have 4 entity beans?

Not 4 beans, but well 4 interfaces (2 remote + 2 local).
Regards,
Phil.
Matt Gaunt
Ranch Hand

Joined: Sep 05, 2003
Posts: 34
Thanks Kathy and Phillipe for your explaination on this. Is starting to come together now and make a little more sense. So as I understand it, I would have 2 beans, 4 interfaces, and thus 4 descriptions in my deployment descriptor (unless I use the Session bean method mentioned by Kathy previously).
Best Regards
Matt Gaunt
Kathy Sierra
Cowgirl and Author
Ranch Hand

Joined: Oct 10, 2002
Posts: 1572
Howdy -- actually, in the DD you'd still have just TWO descriptions for your bean, because you'd be deploying it just one, but with TWO different interfaces listed in the description for that bean. So you'd have one entry for each of the two entity beans, but each of those entrys would list BOTH a local and remote interface class (for both home and component/remote interfaces).
Does that make sense?
Here's a little example of a Movie bean DD that has both a local and remote interface set:
<ejb-jar>
<display-name>MovieJar</display-name>
<enterprise-beans>
<entity>
<display-name>MovieBean</display-name>
<ejb-name>MovieBean</ejb-name>
<home>headfirst.MovieHomeRemote</home>
<remote>headfirst.MovieRemote</remote>
<local-home>headfirst.MovieHome</local-home>
<local>headfirst.Movie</local>
<ejb-class>headfirst.MovieBean</ejb-class>
<persistence-type>Container</persistence-type>
<prim-key-class>java.lang.String</prim-key-class>
<reentrant>False</reentrant>
<cmp-version>2.x</cmp-version>
<abstract-schema-name>MovieSchema</abstract-schema-name>
... continues on...
cheers,
Kathy
Matt Gaunt
Ranch Hand

Joined: Sep 05, 2003
Posts: 34
Cool. All clear for me now.
Thanks heaps for your explaination. And by the way, the book is fantastic. Suits me and my way of learning to a tee.
Best Regards
Matt Gaunt
Keith Rosenfield
Ranch Hand

Joined: Nov 25, 2003
Posts: 277
Hi All:
This question is for Kathy.
You said -
So... you STILL might want a Remote interface for Person and School, but generally this is exposed to a Session bean who is acting on behalf of another client, rather than exposing the entity beans (even with a Remote interface) directly out to the world

How do you provide a Remote interface that is only exposed to a Session bean and not "out to the world"? It was my understanding that if you provide a remote interface you by default expose a bean "out to the world".
Thanks,


Keith Rosenfield<br />SCJP<br />SCWCD<br />SCBCD
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: Entity Relationships