EJB 2.0 design question


EJB design: EJB 2.0 design question

  1. EJB 2.0 design question (9 messages)


    Its a rephrase of an earlier question which remained unanswered.

    I have a sqlserver DB schema as

    orders (master table) with orderType & ~10 other fields.

    orderItemsMetal (7 fields)
    orderItemsBoard (4 fields)
    orderItemsWood (12 fields)

    orders table has 1-Many with one of orderItemsXXXX tables based on orderType and tables are populated by stored-procedures.

    orderItemsMetal has 1-Many with orderItemsMetalDetails and similarly orderItemsWood has 1-Many with orderItemsWoodDetails.

    How do I design this in CMP 2.0. Ideally, the tables structures should remain the same and in normalized form.

    I will really appreciate your response.

    Chris Richard

    Threaded Messages (9)

  2. EJB 2.0 design question[ Go to top ]

    First question to ask/answer is what value would modeling this in CMP be? If you're just going to be doing simple gets/sets and having no additional business logic on the entity bean, I wouldn't recommend using entity beans. The overhead is probably not worth it and you could accomplish the same functionality by using straight JDBC or an object/relational framework like OJB (from the Apache Jakarta site).

    Am I correct in assuming that the orderItemXXX tables are similar and that you're trying to represent your orders object as having a collection composed of any combination of the other three? If so, I don't think that it will work. Generalization (inheritance) relationships usually don't translate well into CMP. CMP is not necessarily an object/relational framework and from my observations wouldn't support that too well.
  3. EJB 2.0 design question[ Go to top ]

    1. For a J2EE app. staying close to standards, Entity Bean is the first choice. Mainly because JDO is not proven yet and most of the reliable O/R frameworks are way expensive. Dont know much about OJB.

    2. orderItemXXX tables have same primary keys but very different structure otherwise. They even have 1-Many with different children tables. I know this kind of problem is not mentioned in any of the design-patterns, that's why looking to find the best way to implement this in a typical J2EE environment.

  4. EJB 2.0 design question[ Go to top ]

    The criteria for entity beans seems to vary depending on who you talk to. The general approach that I take and that I hear most often is that if your entity beans are only going to have get/set methods for the entity bean's properties, don't waste the resources. Entity beans in that case are much too heavy for this use. The last thing that you want to do is use the entity beans improperly and then turn into one of those people who post and complain on this board how bad EJBs are. :)

    I typically don't use or recommend using entity beans as the only mechanism for persistence. I usually mix it up a bit with some entity beans and some JDBC logic. Entity beans are best saved for when there is complex logic associated with performing an operation on an entity bean. Entity beans should probably not be used for queries. In that case you're almost always better off doing direct JDBC.

    For example, take the typical banking scenario. If I have an entity bean and only expose getters/setters for attributes like account number and balance, this would be a bit of a waste of the extra resources needed for the entity bean because I could solve it just as simply with direct JDBC access. However, let's say that there are some specific business rules for doing a deposit or a withdrawl and modifying the state of the account. This would be a decent use of the entity bean and would also fit in nicely to the model where a session bean coordinates operations of multiple entity beans in a transaction (i.e. a transfer between two accounts where the withdrawl logic happens on one and a deposit happens on the other).

    In summary, don't think of entity beans as an object-relational or persistence framework. Save them for times where you want to define business logic on an entity bean that ensures that the entity remains in a valid state. For getter/setter-type operations, just go with straight JDBC.

    For the second thing, the approach that I'd recommend examining first, and an approach that I've become quite fond of, is to use a session bean with some data access objects or data commands. I like the data command idea present in the EJB design patterns book. My data access objects always seemed to have the intent to get bigger and more complex. The downside is that data commands give you more classes, but I can accept that as I like the overall results it adds to the design. It seems like you might have some complex logic here for retrieving and maintaining that data. You can code that logic into the session bean and let it use the data commands to query or manipulate the data in the database.

    Remember that design patterns only cover a small, defined problem, and often problems will need to be resolved by applying some sort of composite design pattern. Also remember that J2EE and EJB are not all-or-nothing solutions, and in fact are design patterns too. Just as not all design patterns match any given problem, there are some scenarios in which EJBs such as entity beans just don't provide the right solution. They're just a bunch of tools that are available to enhance the software development effort. The fact that EJB is a standard should not prevent you from considering other technologies, especially given that JDBC is a standard too.
  5. EJB 2.0 design question[ Go to top ]

    I don't think this question is answerable, as you have simply specified a schema. How you put data into this schema using CMP depends upon the object model of your beans.

    If you have 7 Entity Beans:


    then any old CMP can map these Beans 1:1. No problem. This looks like the obvious way to do this to me. If you don't want to do this, we can't help you unless we know the Object model of your Beans.

    I suspect though that you are thinking of trying to use the complex relationships functionality of CMP2.0. However, what I see above doesn't look like a Bean (a single entity) whose data is spread across multiple tables (which is what CMP2.0 is all about).
  6. EJB 2.0 design question[ Go to top ]


    You can suggest an object model but I dont think there's any complication from object model's perspective. Having an Order object, it will have a collection of one of MetalItems, WoodItems, BoardItems which should implement a common interface ISpecItems. And will have a collection of SpecDetails objects. This is very much the client-view of the persistance model.
    Now being newbie in CMP 2.0, I dont know the best way to do this in CMP 2.0.

    You can also suggest an alternate DB schema as long as its not too much denormalized.

    Thanks for reply.

  7. EJB 2.0 design question[ Go to top ]

    Assuming you do want EJBs, because you do have some object-oriented business logic going between your local beans, let's see how to do it:

    I suppose the subclasses (orderItemsMetal etc.) carry the same primary key? Then, using CMP 2.0, you could define a one-to-one relationship between e.g. orderItemsMetal and orderItems, where the orderItemsMetal side is actually optional. Tell your appserver's persistence layer to use the primary key of orderItemsMetal as the foreign key pointing to the related orderItem (this may not be possible with all appservers, see below).
     When you have a orderItemsMetal bean, you can safely and easily navigate back to the orderItem. You could even make the remote/local interface of the orderItemMetal bean extend the interface of orderItem, and delegate all calls to these methods to the orderItem to make things look more like true inheritance.
      In the orderItem bean, you will have lots of cmr accessor methods, with all but the one corresponding to the type code returning null at any time.

    Note that the PK column of orderItemsMetal now doubles as a foreign key mapping a container-managed relationship. This leads to problems creating a "orderItemsMetal" using pure EJB, because according to spec, you are only allowed to set cmr fields in the ejbPostCreate method, but the PK has to be specified in the ejbCreate method. The solution in BEA Weblogic is to also map the PK column using a container-managed field with the rows's scalar type. I do not know if and which other ejb servers support mapping the same DB column in multiple ways.

     Fortunately, the last point doesn't seem to be a problem in your case since you're talking of stored procedures for creating.

      There was a discussion of an inheritance pattern on tss some time ago. Though flawed, it was probably as good as it gets using ejb as it is, so you may be interested. If someone still knows the thread id ...?

    my 2 cents,
  8. EJB 2.0 design question[ Go to top ]


    - yes the PK is same for orderItemsXXX beans. I never knew that some side of the relationship can be optional. Can you shed some more light on this? or point me to some technical material. I have been through Richard Monson's EJB book and Ed Roman's Mastering EJB but without any solution to this problem.

      In the orderItem bean, you will have lots of cmr accessor methods, with all but the one corresponding to the type code returning null at any time.
    This is over my head for now.

    that's not true. stored-procedures are part of current Microsoft implementation and as we go to J2EE, there should not be any stored-procedures.

    I have that article on EJB inheritence but its little shaky. Somehow I assumed this is a common relationship in real life applications but probably this is not the case. I wish JDO was more mature. JDBC is not an option (who wants to maintain those bulky SQL statements today??).


  9. EJB 2.0 design question[ Go to top ]

    First: Sorry for some confusion; I though you wanted to factor out common fields of your various order item tables, but upon re-reading your initial posting, this doesn't seem to be the case.

    One thing that's still not quite clear to me: Can the same order contain wood items as well as metal items? If not, then you don't need all the complicated inheritance stuff I posted earlier. In orderBean, just create one collection-valued cmr field for each order item type. You make each OrderItemXXXLocal interface (for XXX in Wood,Metal,...) extend the SpecDetails interface. Then, in orderBean, you write a custom method getSpecDetails that returns a collection of SpecDetails by calling the respective getOrderItemsXXX. So you even get polymorphic read/write access! Some code:

    public abstract class OrderBean
       implements javax.ejb.EntityBean {
    public abstract int getOrderType();
    public abstract Collection/*OrderItemMetalLocal*/ getOrderItemsMetal();
    public abstract Collection/*OrderItemBoardLocal*/ getOrderItemsBoard();
    public abstract Collection/*OrderItemWoodLocal*/ getOrderItemsWood();
    public Collection/*SpecDetails*/ getSpecDetails {
      switch(getOrderType()) {
        case ORDER_TYPE_METAL:
           return getOrderItemsMetal();

    woodOrder = orderItemHomeLocal.createOrder(ORDER_TYPE_WOOD);

    Should work, I think.

    About "optional" relationships: In fact, when seen from the Java side, one-to-one relationships in EJB are always optional-to-optional. If the other side is missing, the cmr accessor just returns null. You can also call the setter with a null argument. Of course, the integrity constraints in your DB may still stop you if your foreign key is non-nullable.

    About inheritance: Of course it is a recurring real-life pattern, but EJB is not :-)

    About "technical material": Your best bet is to read the EJB spec itself, it's a bit repetetive, but it gives the least common denominator of what you can expect from an EJB server.

    Hope that helped?
  10. EJB 2.0 design question[ Go to top ]


    An Order can only have one of wood/metal/board. That's why I always thought its a common problem because most of the systems I have been working upon (financial, warehouse mgmt, procurement) have these kind of scenarios.

    If your suggested solution works, that's wonderful. I will give it a try (most probably with JBoss/mySql) and hope it will work. Otherwise, I will get back to serverside.com again.

    Thanks for your time.