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