Discussions

From "Java Server Programming J2EE Edition" to "Enterprise Java with UML" every book that i have read, and most of the Entity EJB tutorials, all have used aggreagation/composition whereby one entity EJB holds a referenece to one or more entity EJBs. "Enterprise Java Performance" even states that embedding a reference to an entity EJB in another entity EJB is very much object oriented. Now they say, that with the advent of EJB 2.0, now there is a standard way of managing entity to entity relationships.
However, IBM redbooks on EJB design and VisualAge, and Sun J2EE Design Patterns, both are against entity to entity relationships. One red book even states the difference between EJBs and normal objects stating that with EJBs there is no association. J2EE Design Patterns catalog states entity-entity associations are not elegant when using entity EJBs and suggests using a session bean for managing entity-entity relationships. VisualAge has its own process whereby it generates a Link between the two associated EJbs generating some other classes and sometime one has to even modify the code.
Firstly, can some one please suggest why entity-entity design is not elegant?
Secondly, what is the preferred solution to this problem.
Note: This problem is not like more than one entity objects in the domain model which are better modelled as dependent objects. But once, two entities have been agreed to be made entity EJBs and are associated in some way, only then this problem arises.

I'm not familiar with the exact books you mentioned, so I can only give you my view of things.
Entity-to-entity relationships are a fact that exists in common business structures. When a Salesman has several Customers, it just does. You can't restructure the data so that it doesn't. What you can do is decide how to manage these relations in your EJB code. In EJB1.1 hardcoding the relationship management in the entity bean usually produced an in-ellegant implementation. Several aggregation techniques has arrised to organize such tasks, such as managing the relationship in a seperate session bean.
Because these types of structures are so common, the EJB spec leaders decided to address them in a uniform way, in order to take the cumbersome tasks of relationship management off the hands of the developer. EJB2.0 addresses relationships using CMR, "Container Managed Relationships". I can think of no design reason not to use CMR, now that it is available. Is it possible that the redbook was written before EJB2.0? If not, could you please list the redbook's design rationale?

Hi,
Thanx for your reply. However, take a look at he Aggregate Entity Design Pattern. http://developer.java.sun.com/developer/restricted/patterns/AggregateEntity.htmlIn one portion it states "According to the EJB 2.0 specification, a dependent object is defined as follows:............" This means the authors were quite knowledgeable of EJB2.0 spec and whatever it is going to do to deal with entity-entity relationships. However, the still detest enity-entity relationships as:

".....
Impact on relationships
Direct mapping of an object model directly to an EJB model does not take into account the impact of relationships between the objects. The inter-object relationships are directly transformed into inter-entity bean relationships. As a result, an entity bean might contain a reference to another entity bean (that is, the entity bean holds a remote reference to another entity bean). However, maintaining remote references to distributed objects involves different techniques and semantics than maintaining references to local objects. Besides increasing the complexity of the code, it reduces the flexibility because the entity bean must change if there are any changes in its relationships.
There is also no guarantee that the entity bean references to other entity beans remain valid over time. Such references are established dynamically using the entity's home object and the primary key for that entity bean instance. This implies a high maintenance overhead of reference validity checking for each such entity bean-to-entity bean reference.
...

...one way to model this (entity-entity) relationship is to store the dependent object entity bean's primary key in the coarse grained object. When the coarse-grained object needs to access the dependent object, it will result in an entity-to-entity invocation.

The sequence diagram for scenario is shown below. The Aggregate Entity uses the dependent object references to look up the required dependent entity beans. The dependent object in this case is a proxy to the dependent entity bean as shown.

...."

And the authors suggest in the end:

"While this may address the requirement of using a dependent entity bean from a parent entity bean, it is not an elegant solution. Instead, to avoid the complexity of designing and managing inter-entity relationships, consider using a session bean to help manage the relationships among entity beans. In our experience, we have found that the session façade pattern helps us to avoid this problem and to provide a better way of managing entity bean to entity bean relationships.

So, we recommend, that as a best practice, try and avoid entity-to-entity bean relationships."

Now I am in real trouble. I am unable to understand that when we talk of object model, no one is bothered about entity relationships, rather it is the only design choice for associated classes. However, when the same object model is converted to EJBs, (Please note that this is the case when there have to be two associated entity EJBs. If an object needs to be persistent but need not be accessed dierctly by the client, its made a simple dependent object and not a entity ejb. In whcih case, the object model does change while converting to EJBs)..why they say things like:
"The inter-object relationships are directly transformed into inter-entity bean relationships. As a result, an entity bean might contain a reference to another entity bean (that is, the entity bean holds a remote reference to another entity bean). However, maintaining remote references to distributed objects involves different techniques and semantics than maintaining references to local objects. ..-=-> //HERE: -> (I am lost) Besides increasing the complexity of the code, it reduces the flexibility because the entity bean must change if there are any changes in its relationships. There is also no guarantee that the entity bean references to other entity beans remain valid over time. Such references are established dynamically using the entity's home object and the primary key for that entity bean instance. This implies a high maintenance overhead of reference validity checking for each such entity bean-to-entity bean reference. " -> Why this thought is not the case with the simple object model?
Paying a terrrible price, I got hold of the book "Enterprise Java Performance" and in one section it states, that the ...MOST object oriented way of showing relationships between entity beans is to have a reference of one ejb in another.. i.e. the same as simple object model..?? No one other the the J2EE DP or VisualAge docs has so far talked of this issue.. J2EE DP docs authors as mentioned above are quitee aware of EJB 2.0 ..but then why all this?

Please note that the authors are not talking of network traffic that has been solved by EJB 2.0, they are not talking of portability and persistence of entity EJB references, that also has been solved by EJB 2.0. In fact, they are giving a design guideline that has nothing to do with EJB 1.1. or 2.0.
Regards,
Hasan

"..EJB1.1 hardcoding the relationship management in the entity bean usually produced an in-ellegant implementation. Several aggregation techniques has arrised to organize such tasks, such as managing the relationship in a seperate session bean.
Because these types of structures are so common, the EJB spec leaders decided to address them in a uniform way, in order to take the cumbersome tasks of relationship management off the hands of the developer. EJB2.0 addresses relationships using CMR, "Container Managed Relationships". I can think of no design reason not to use CMR, now that it is available. Is it possible that the redbook was written before EJB2.0? If not, could you please list the redbook's design rationale? .."
Once again, as I mentioned the authors of J2EE DP were quite aware of the EJB 2.0 spec while recommending not to have entity-entity EJb relationships in design. They mentioned problems like manageability etc. So thay may be ".. If the data moves from one table to another, one of the Entity EJBs changes but nothing else does.." (quoted from some other forum)

This is basically the confusion point. I think this is one reason why the J2EE DP discourages entity-entity EJB relationships. However, my confusion is that this type of relationship is very object oriented and also not any architect has disfavored this design when uing simple objects., then why with EJBs?
Hasan

I think you are getting mixed messages because the situation your descibe changes with your view point. For instance, a salesman has contacts. Contacts also move jobs, and are often maintained by different systems on different databases.

Should you have a software layer which encourages object graphing and loading aggregrate data, together with cascade deletes and all those issues. No is the simple answer, and maybe the more realistic one. Some self contained projects may be able to envision a pure OO design, with EJB references, agregation, cascading and so on. However, in week two of going live the address database is moved out of your control and a data feed replaces it. And a week later you have to take a feed of customer names from someplace else. And your entire view of the project falls apart.

The only place that such modelling is proven to work is within relational databases, reimplementing these relationships in a data caching software abstraction layer (EJB) is wasteful and potentially very dangerous (for the project).

So what it comes down to is risk assessment and how complex a software architecture you want, given that the database does it all for you.

I do not use EJB aggregation, I tend to stick it in session beans, simple because I control which data is loaded and aggregated when - so a screen to change a salesmans name doesn't go chasing down all his contact data as well. It also means I can control dirty data checking and so on.

One final aspect of all this is the auditing you implement. Many systems no longer delete data, flagging it as dead, or moving it to audit tables. Aggregating EJB's may confound this approach unless well considered.

"...
To conclude, in the pattern above I read "entity beans" to be "remote entity beans..." and that J2EE DP was written before EJB 2.0 was finalized and so it needs updation.

However, Jonathan has provided the answer to my original problem that even with the remote issues removed, the entity-entity EJB relationship design is flawed at best as it hinders flexibility. Tthough I am still trying to make sense of the whole situation / scenario [attributable to my inexperience only] but I can "sense" something wrong now with enity-ewntity EJB design model. Thanx Jonathan.,
There is one more issue as pointed by someone at scea_j2ee forum, that how to implement Aggregate Entity with CMP is still unclear.

Hi.
Entity to entity relations are a fact. They exist in most projects (any project that models an ERD) and you can't make a design choice not to support relationships.
What you can do, and I belive this is what Jonathan mentioned, is model these references as relationships between objects that are not Entity Beans. These are still entities and the still talk to one another, they are just not implemented using EBs.
Just like with any other implementation, implementing your entities with EBs has it's limits: the App server probably only supports your own relational DB, and not fetching of data from an external system. This is a common problem in OO, and a good way to overcome it is to provide a standard interface for the EB and implement it using whatever you need (EBs, direct access to ERP, etc). This is possible, although cumbersome, with EJB2.0 local interfaces. If the risk of moving some of your entities to an external system is realistic, this is a good approach, IMHO. Anyway, all implementations that are based on frameworks are limited, including EBs. I don't think that means you shouldn't use that framework at all. Use it whenever you can, and when you can't, implement the functionality yourself.

I'm not entirely sure what the concern is regarding managing EB relationships. Some people like their EBs to keep hold of PKs to other EBs, then "lazy load" when the related object is asked for through a "getter".

In the past, I have used session beans to hook up EBs with each other. But after that point, the EBs do maintain their relationships. I'm talking BMP only now, of course.

Essentially, one would have a "smart" EBReference implemenatation which can convert between EJBObject, Handle and PKs. For instance, an Order Bean could have it Shipment stored in the database using the PK for it. In ejbStore(), the PK would be stored in the database. Optionally in ejbLoad, an EJBObject could be constructed. There would be methods such as setShipment() which can except an ejb object, handle or pk that a session bean would invoke to associate Shipment with Order. A method such as getShipment() would look at its corresponding EBReference object to smartly do what is needed to yield an EJBObject cast to the appropriate local/remote reference, i.e. in this case Shipment.

So I'm really not sure why there would be any problem with an EB holding a "reference" to another EB whether it is done so directly through an EJBObject reference or through a EBReference helper.

I think Johnathan said very well. There is also a business side of it. What EJB (or J2EE altogether) envison is a world where Container, beans, clients are all produced by different vendors. When You are selling an entity bean, the entity reference becomes hard coded association. Now 2.0 comes out an idea that you actually can assemble beans together if they fall into the same domain - that is CMR. So the only thing changed in different deployment is the descriptor.
To have a smart EBReference is fine. To be able to lazy load the bean is great. However, J2EE doesn't envison you (as bean programmers) doing it. That's the container's job.
In my opinion, session bean managing the relationship was a pattern to use when CMR was not there.

You hit the nail on the head when you said if one is trying to assemble an application using disparate entity beans, then hard coded relationships managed explicitly or through CMR are not a good idea.

Though I am not aware of that reality - buying off the shelf EBs and making them work - it is more likely that one would purchase multiple EB components with well defined relationships. These would then be defined through CMR or whatever mechanism the vendor has chosen, directy EB to EB or managing through SB.

So what I'm hearing then is that if all your EBs are part of the same domain (I'm interpreting this to mean I developed all of them) then it shouldn't really matter whether I use CMR, EBReference of SB to manage relationships. I am convinced of any alleged "flexibility" of managing relationship through a SB. EB relationships in EB can be explicitly "broken" and "created" at will. I haven't had the pleasure to do EJB 2.0 yet, so cannot comment on whether this is possible to CMR. I forget. does CMR work with BMP or only CMP?

The pattern you allude was written with EJB2.0 PFD1 in mind. They mention "dependent objects", which are no longer available in EJB2.0. Dependent objects were replaced by local EBs.
This pattern suggests modelling related objects as "dependent objects" and loading the entire graph in a corase grained entity bean. These dependent objects can, in a sense, be implemented using local EBs in EJB2.0.
Local EBs and CMR were added to EJB2.0 with the EJB1.1 problems in mind. They solve many of the problems listed in the pattern you mentioned. This does not mean that entity beans should now be as fine-grained as possible. Entity beans should represent your business data in a reasonable OO way. They should not have to adhere to the DB schema, and the EJB2.0 spec takes some measures to ensure thats the case (such as the abstract schema/client interface seperation). However, many of the problems that existed with remote EBs are now solved in local ones.
To conclude, in the pattern above I read "entity beans" to be "remote entity beans". That is one of their main assumptions (disucssing network load problems, addressing distributed referencing issues, container-load issues, etc). Without this assumption, the rest of the rationales are "weaker", IMHO. They still hold, but you can get much more fine-grained before they become significant.

TechTarget provides technology professionals with the information they need to perform their jobs - from developing strategy, to making cost-effective purchase decisions and managing their organizations technology projects - with its network of technology-specific websites, events and online magazines.