• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

Entity Relationships

 
Ranch Hand
Posts: 34
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
 
Cowgirl and Author
Posts: 1589
5
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Posts: 34
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Posts: 1589
5
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
 
Bartender
Posts: 1872
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Posts: 34
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Posts: 1589
5
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Posts: 34
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
 
Ranch Hand
Posts: 277
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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,
reply
    Bookmark Topic Watch Topic
  • New Topic