new EJB pattern?


EJB design: new EJB pattern?

  1. new EJB pattern? (2 messages)

    Dear EJB-profis,

    A few days ago I had a little idea for improving part of the
    design of some EJB system I was working on. The system is an N-Tier system consisting of some entity beans and some stateless session beans. We are using BEA's Weblogic Server 5.1 in combination with TOPLink for Weblogic for the realization of our system. There are some many-to-many relationships between our entities, and we are currently using TOPLink's Object-to-Relational mapping for persisting these relationships.

    In using TOPLink we came accross some nasty problems (for example, cache transparency problems), but I don't want to go into the details of these problems in this posting. Fact is that we had a lot of trouble, and that we have lost our trust in TOPLink.

    As most of the above mentioned problems were related to many-to-many relationships, I thought of a way to minimize the risk of using TOPLink.

    To explain the idea that I got I need to explain a bit more about how we implemented many-to-many relationships first.

    We have converted all N-to-M relationships to 1-toN relationshsips first by defining new entities that should represent the N-to-M relationships. These entities consist of two foreign keys connecting the entities of our N-to-M relationship, and are implemented as normal Java objects.

    The other entities are implemented as entity beans. These beans consist of a set of attributes and a vector of so called ValueHolders for holding references to the entities that represent the N-to-M relationships (the Java objects mentioned above).

    SO our entity beans have to parts: the part consisting of the entities attributes, and the part containing the dependents of the entity (the vector of ValueHolders).

    Persisting the first part goes without many problems, but persisting the second part doesn't. SO it might make sense to cut the second part loose from the first part.

    Here's the idea: We split our entity bean into to classes, say: Entity and EntityWithDependents. Entity implements logic to get and set it's attributes, and persists these attributes using CMP. EntityWithDependents inherits from Entity, and extends Entity with logic to persist the dependent objects.

    The advantages of this idea are twofold:
    1. Our classes are much cleaner
    2. We can easily replace an implementation of EntityWithDependents with another without neding to replace the Entity implementation. For our porject this means that we are now less dependent on TOPLink.

    In our design an Entity Beans, say X, consist of the following classes and interfaces:

    XHome (Home interface)
    X (Remote interface, implements interface XBusinessLogic)
    XBean (implements XBusinessLogic)

    As you can see we are using the business logc pattern for enabling the compiler to find inconsistencies between X and XBean.

    Using the (new?) idea explained above an Entity X with dependent objects would consist of the following classes and interfaces

    XHome (Home interface)
    X (Remote interface, implements interface XBusinessLogic)
    XBean (implements XBusinessLogic)
    XWithDependentsBusinessLogic (extends XBusinessLogic)
    XWithDependents (remote IF, implements XWithDependentsBusinessLogic)
    XWithDependentsBean (extends XBean, and implements XWithDependentsBusinessLogic)

    You could also split the Home interface. That would create the possibility to deploy both X and XWithDependents at the same time. I am not sure what advantages that would have, but I guess you could realize lazy entity instanciation like this. If clients are not interested in the dependent objects, they could just instanciate an X entity. This would not cause the application server to instantiate all dependents as well. I suppose that would improve performance.

    We did not try this idea out yet. We are not even sure if we ever will in this project, because it has temporarily been put on hold.

    I would just like to hear your opinion on this idea. Does it make any sense to you? Could this be a new pattern, or did it already yexist in some other form?

    I look forward to your reactions.

    Best regards,

    Mark Nankman

    Threaded Messages (2)

  2. new EJB pattern?[ Go to top ]

    The following URL discusses modeling relationships as objects, which appears to be similar to what you have described.
  3. new EJB pattern?[ Go to top ]

    Out of curiosity, what version of TOPLink are you using? Can you send me (via email if you prefer) any details of the cache problems you have seen.