EJB design: Can a entity bean call another entity bean?

  1. Can a entity bean call another entity bean? (3 messages)

    Let's say there are an entity bean called Student bean to encapsulate the student's current study information, and another entity bean called Course bean to store course description and other details.

    Student bean has a method called getCourseName(). In this method, shall we use Course bean to return the course name, or we code again the SQL statement to fetch the course name from database? From object-oriented view, it seems like better use the Course bean because it encapsulates the course data in the database such as accessing it and modifying it. But when I code it, an TransactionRolledBack exception was raised. Does this exception related to the settings like TX_SUPPORT, TX_REQUIRED..? If so, what should I set or any others attribute that I didn't mention? Thanks in advance.
  2. Yes, there is nothing in the spec that says u cannot. In your example, the Student bean is a client to the Course bean. The Course bean need not know whether the caller is a servlet/session bean/another entity bean. You would need to set TX_REQUIRED for the getCourseName() method in the Course bean, so that the Student bean always gets the latest value of the course name. As far as possible, try and keep such entity-to-entity bean calls restricted to getXXX() methods.In case entity-to-entity bean calls get complex, it is better to have a session bean handle the process.
  3. My feeling is that having a getCourseName method in the student session bean is itself wrong. You can't have methods in one session beans to get data related to other entities.
    The student entity should just return a courseId in the data to the seesion and session then get other required data before it returns to the the client.
    This is what i have done and my argument was that entities should only manage what they encapsulate. By getting course name in the student bean itself , you are making an assumption that every data request to the student entity bean also intends to read the course name, which may not be true.

  4. If you are going to return a key, it seems it would be better to return a primary key object rather than the courseID. In that way, you do not expose the implementation details of the RDMBS to clients. In this way, if the key changes (e.g., perhaps it changes to courseId and deptID), the changes will be localized.

    In traditional OO, one would tend to return a Course object rather than a key. Any one have any arguments pro or con in regards to returning a course object? Here are my thoughts:


    Returning the Course object means the client doesn't need to know if Course is an entity bean or just just a regular object. That is, the client doesn't need to know how to obtain it.

    IMHO, it is more natural (but I admit that "natural" is in the eye of the beholder).


    If it is an entity bean, perhaps the client should know this so the cost of the access is obvious.

    Just my thoughts. I am interested in hearing others.