Discussions

J2EE patterns: EJB design: finding the right Entity Beans

  1. EJB design: finding the right Entity Beans (14 messages)

    EB design in practice relies on using patterns and determining the correct level of granularity. However, finding the "right" components has remained an art. Here we prescribe how to find the right Entity Beans.We propose a methodology of finding right Entity Beans for an EJB framework. We welcome your feedback.

    We propose a Create, Get, Set, Remove (CGSR) matrix that is a akin to a CRUD matrix used for depicts interactions between business events (in rows) with entities (in columns).

    The steps are as follows:

    1.List the Entity Objects in the system from the logical object model (LOM).
    2.List the business events in the systems from the Use Cases.
    3.Draw a CGSR matrix with the rows with Business Events & columns as Entity Objects. The intersection cell denotes the type of interaction. If entities were modeled as Entity Beans, a business event can Create a bean instance, Get or Set values of a bean instance or Remove the instance.
    -----------------------------------------------------------
    Entity Objects
    -----------------------------------------------------------
        E1 E2 E3 E4 E5 E6 E7
    -----------------------------------------------------------
    M1 CGSR C C G GS R
    -----------------------------------------------------------
    M2 C C G G
    -----------------------------------------------------------M3 C CGSR C
    -----------------------------------------------------------
    M4 CGSR C G
    -----------------------------------------------------------
    M5 C
    ------------------------------------------------------------
    M6 CGSR
    -----------------------------------------------------------
    M7 CGSR R R G R
    -----------------------------------------------------------
     

    4.Arrive at the list of entity beans from the CGSR matrix:
    a)Every entity bean in the system maps on to one or more of these Entity Objects in the LOM.
    b)Maximum number of entity beans possible corresponds to total number of Entity Objects in the system
    c)The type of interaction b/w events and Entity objects decide the number of entity beans in the system. This is explained with the following example:
    -----------------------------------------------------------
    E1 E2
    -----------------------------------------------------------
    M1 CGSR CGSR
    -----------------------------------------------------------
    M2 CGSR
    -----------------------------------------------------------
         
    Two ways in which beans can be classified are:
    1.E1, E2 map to EntityBean1
    2.E1 maps to EntityBean1 and E2 to EntityBean2

    With option 1, event M2 could cause referential integrity problems, with "Create" and "Remove" operation. If M2 were to interact with E2 only in "Get" or "Set" mode then option 1 is possible.
                      
    d)Mark all the cells with a "*" wherever the type of interaction is a Create or Remove. The resultant matrix is as shown below:

    Business Events Vs.Entity Objects
    -----------------------------------------------------------
    E1 E2 E3 E4 E5 E6 E7
    -----------------------------------------------------------
    M1 * * * *
    -----------------------------------------------------------
    M2 * *
    -----------------------------------------------------------
    M3 * * *
    -----------------------------------------------------------
    M4 * *
    -----------------------------------------------------------
    M5 *
    -----------------------------------------------------------
    M6 *
    -----------------------------------------------------------
    M7 * * * *
    -----------------------------------------------------------

    e) Corresponding to each Entity Object list the business events with a '*'.
    E1 -> M1, M7
    E2 -> M1, M2, M3, M7
    E3 -> M1, M2, M3, M7
    E4 ->M3
    E5 -> M4, M6
    E6 -> M4, M5
    E7 -> M1, M7

    f) Group the entities that have the same business events. Example:
    G1:E1, E7, E8 (M1, M7)
    G2:E2, E3 (M1, M2, M3, M7)
    G3:E4 (M3)
    G4:E5 (M4, M6)
    G5:E6 (M4, M5)
    g)Number of entity beans = number of groups of entity objects.
    h)Each group of entity objects represents one entity bean. Thus the entity beans for the above example are:
    G1 :Entity Bean 1
    G2 :Entity Bean 2
    G3 :Entity Bean 3
    G4 :Entity Bean 4
    G5 :Entity Bean 5

    One needs to review this scheme in the light of the following observations:
    -One-to-many relationship between any two entities grouped together to form a bean may force one to go for bean-managed persistence
    -The grouping is primarily based on Create/Remove operations as depicted in CGSR matrix. Additionally, one may have to consider Get/Set operations for improving performance. Suppose an entity with fewer fields is grouped with an entity with far greater number of fields using the grouping scheme suggested. Now, if the Get /Set operations on the fields of the smaller entity are more frequent, then the performance degrades due to loading of all the fields. Keeping the entities separate may be preferable in this case.
  2. Hi!

    Your pattern looks systematic.

    Did not understand everything.
    What is a CRUD matrix?
    What is the difference between CRUD and CGSR?
    4. c) what is "b/w" in "The type of interaction b/w events and Entity objects decide the number of entity beans in the system."?

    P.S.:
    hint for better readability of your pattern:
    do not use the br-tag of html many times,
    instead use the pre-tag as parenthesis
    (to retain your original layout)

    Hey! And no LAUGHING at my bumpy english!
  3. hi ,
    your writeup seems interesting ,but it is unfortunate that I did not understand a thing. Please do not use short names.
    thanks
    Sudershan vellore
  4. Hi,

    Your pattern seems to be very interesting. But am not sure whether it is to find the EB or to reduce the number of EB in a system.

    You said that find the Entity objects in the system from LOM. Then u explain the way who to group the Entity Objects into a Entity Bean.

    Can u please explain me what is the drawback of making all the Entity Objects as Entity Beans and also what is the advantage of grouping Entity Objects into a Entity Bean.

    Am new to EJB world so any explanation regarding this will be very useful for me.

    Regards
    Shagun
  5. Please refer to more details on this article on the site..
    href="EJB" rel="nofollow">http://www.infy.com/corporate/thought-papers/CRN-0011-01.pdf">EJB Design:finding the right Entity Beans</a>.
    Please get back to me if you have any questions.
    Thanks
    Rajeshwari
  6. Hi Rajeshwari,
          The link you have provided does not work. It looks like it's moved. Please provide the valid link.
    Thanks
    Krishna

    > "http://www.infy.com/corporate/thought-papers/CRN-0011-"01.pdf
  7. Hi,

    The new url is

    http://www.infy.com/knowledge_capital/thought-papers/CRN-0012-01.pdf

    Lakshmanan
  8. I read both your article and paper. It is a respectable and valuable effort to formulate a proper way to model entity objects with entity bean. Currently, it is very common that Entity Bean is as a object to interact with the database, which is OK in terms of modeling and definitely not good for performance.

    Regarding your paper, I have several questions:
    1. How do you define 'Right Entity Beans'?

    2. It makes sense to represent two closedly related entity objects by one entity bean. But if we go down the the programming details, does that mean we can only use BMP insteadof CMP? I believe in CMP, you can only map one table to one Entity Bean.

     

  9. hi Rajeshwari

    Nice article and really value added.
    I could understand how to minimise no of EJB to based on entity.

    Do u think mapping two entity with sinle EJB
    will work? i think BMP is the only option.

    See i have 6 tables. Tables are very similar in structure(in short only primary field is changing).

    Will it good option to go for BMP bean? OR Create seperate entity bean for each?

    Tell me what advantages/disadvantages will i get in both cases?


    Regards
    Santosh
  10. I feel that it is not a good idea to have one CMP Entity bean per table. Instead having a BMP for a set of tables is better as it will reduce the number of remote invocations. Although today's Application Servers do not support multiple tables in CMP's, it is better if we design BMP's for multiple tables having similar structure.
  11. Well, the Bible (EJB Spec) says developers should persist with CMP. There are quite some advantages with CMP... What do you think?

  12. Hi,

     The other way i look at this pattern is,
    Join the all Logical Entities in in to single
    entity bean based on their life cycle. i.e if
    the creating/removal of the entities happen at
    same time, instead of making them two entity beans
    with two remote calls just make it as a single bean
    there by reducing the number of remote calls.
    Correct me if iam wrong ?

  13. If one is using CMP, then one will have to have an entity bean for each table that represents a logical entity (in the ER diagram) and for each table that represents a relationship (in the ER diagram) provided the relation has attributes to itself.

    Only relationship tables which do not have any other columns than the foreign keys do not count.

    Surajit
  14. Hi:

    Since this article was written in 2000, many thigs have chnaged in the ejb world. Now in EJB 2.0 we are blessed with relationship. So perhaps I feel your theory needs a good review. What you have proposed can be done through relationships and by using CMP.

    Anyway, it is a good article, but please make it more lucid to improve readability.

    Regards,

    Dheeraj
  15. Hi:

    Since this article was written in 2000, many thigs have chnaged in the ejb world. Now in EJB 2.0 we are blessed with relationship. So perhaps I feel your theory needs a good review. What you have proposed can be done through relationships and by using CMP.

    Anyway, it is a good article, but please make it more lucid to improve readability.

    Regards,

    Dheeraj