4 Replies Latest reply on Feb 20, 2002 6:30 PM by Huy Nguyen

    Entity EJB associations

    Hasan Saleem Newbie

      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.


        • 1. Re: Entity EJB associations
          Ignacio Newbie

          IIRC what Sun J2EE Design Patterns says is that you shouldn't abuse on EJB relations (still talking about patterns prior to EJB 2.0 and CMR and local interfaces).

          If I understand right, entity EJB relations are very related with business logic, so keeping them in session beans make sense; you make your business logic scalable and keeps complexity in just one bean. An example that I am programming right now:

          I have a relation between beans A and B that was programmed as CMR. Now there should be a boolean value on this relation (call it "available") that modifies the relation itself. So I have to delete the CMR from the entity beans, make custom finders and displace the logic to session beans. Half the work would be done if I coded on session beans from the beginning (don't misunderstand me, I keep on CMR whenever I can).

          As i see it, currently J2EE patterns are a bit outdated, and even more, some of them are against others.

          Remember that in theory an entity EJB is supposed to only care about persistence. Using a Customer EJB to locate his Billing is something that was not intended. You can do it, but knowing that your bean can become innecesarily complex.

          • 2. Re: Entity EJB associations
            F Zemen Newbie

            How a container handles relationships is an important factor, for example when and how it goes about loading collections.

            I like using CMR with low load, high business logic systems, for example a sales management application that monitors orders, sales leads, contacts etc. where no more than several dozen thousand people might hit the application occasionally during a given business week.

            On the other hand, high end transaction processing systems that have constantly high loads and very high peak loads have performance requirements that can often be better handled by not using CMR. One example is a a system that accepts up to a milion messages per day where each message contain anywhere from a dozen relationships to a few hundred. Traversing relationships is not a good approach here.

            • 3. Re: Entity EJB associations
              Hasan Saleem Newbie

              I guess local interfaces in EJB 2.0 solve the problem


              • 4. Re: Entity EJB associations
                Huy Nguyen Newbie

                U dont have problem in the first place. What it means now is that you want to use CMR coupled with Container-Managed persistent. This is the easiest way to manage entity bean relationships. Well refering to the reply from JBOSSUser previously for performance consideration.