Composite Entity and EJB 2.1


EJB design: Composite Entity and EJB 2.1

  1. Composite Entity and EJB 2.1 (1 messages)

    Before EJB 2.0+, it was considered a good practice to implement BMP and they said that it had better performance. As of the 2.0 ejb spec, CMP is considered to have a better performance since the container provider is allowed to use strategies other than standard java code, like native libs a stuff.
    Now, is it really a better idea to implement the composite entity pattern as described in Core J2EE patterns, which requires the use of BMP, with the new EJB spec or can I just implement standard CMP entity beans for small entities that have like two or three fields (but also must have a insert/delete/update interface for the client)? Which one has better performance? Pros? Cons?



    Threaded Messages (1)

  2. Java Blueprints[ Go to top ]

    Thank you for anyone who's read it.
    I found the answer for it myself. It's on:

    Brief Description
    Mapping an object model to an Enterprise JavaBeansTM (EJBTM) object model is a common design problem in JavaTM 2 Platform, Enterprise Edition (J2EETM) applications. Given a network of inter-related objects, you must choose whether each object should be implemented as an entity EJB or a plain old Java object, and manage the relationships between the objects. Remote entity beans are best suited for modeling coarse-grained business entities. Modeling fine-grained entities as remote entity beans creates problems performance problems such as excessive remote communication. Choosing to use Bean Managed persistence means:

    Dependent objects, which are objects whose data are meaningful only in the context of a relationship to another object, are especially prone to these problems. For example, in many applications, an Account object is meaningless outside of its relationship to its associated parent Customer object.

    The Composite Entity design pattern offers a solution to modeling a networks of interrelated business entities. The composite entity's interface is coarse-grained, and it manages interactions between fine-grained objects internally. This design pattern is especially useful for efficiently managing relationships to dependent objects.

    Before the EJB 2.0 specification, entity beans were always heavyweight and remote. The local, lightweight entity beans introduced with EJB 2.0 are intended for efficient modeling of fine-grained business entities and dependent objects. Efficient local access eliminates many of the problems listed above.

    So that's right, the composite entity is no longer the best way to go.... Thanks anyway...