Moving ER-thinking to OO


EJB design: Moving ER-thinking to OO

  1. Moving ER-thinking to OO (1 messages)

    Hi everybody!

    I’ve been, for a while, trying to learn the nuts ant bolts of application servers and J2EE. Right now I’m trying to grasp and explore the fundamentals of container-managed persistence and the mapping between the OO-model and the relational model. I really like the idea of cmp (becoming a cmp-fanatic), but I have some apprehensions about it, which are the following:

    1. The xml file (or whatever) which map the beans to a physical table is depending on the application server in use. This reduces portability.
    2. A large-scale model (about 200 cmp’s) will result in large and complex mapping files. These files, the relationship part of the ejb-jar.xml and the mapping file will in my opinion not be easy to handle, especially not for beginners. If the relationship is between an inside or outside jar it will be even more complex. Remember that the subject it quite complex. It doesn’t only include an understanding of the used syntax in the xml-files, but also of OO, ER and the paradox in-between.

    Furthermore, the relationships could physically be solved differently from vendor to vendor. Orion, for example, creates an associative table for every many relationships and WebLogic, as I understand it, use, in case of a one to many relationship, a foreign key in the side of many (I have actually not used Weblogic so this is only a good guess). The point is, the solution could look different from vendor to vendor.

    So, what is one solution (probably a stupid one)? What happens if one move ER to OO, i.e. you model the relationships, as it would be an ER-model and just express the relationship (and not elsewhere) by a field in the bean. For an example:

    public abstract class OrderBean implements EntityBean
    // Fields

    public abstract class OrderLineBean implements EntityBean
    // Fields
    Order order // Foreign key

    Now I don’t have to characterise the relationship in the ejb-jar.xml and I don’t not have to create the syntax for mapping collections as a foreign key or to an associative table. I could also deploy these, if I want to, in different ear-files and let a session bean take care of the transactions.

    This thought or whatever, is probably due to the fact that I probably doesn’t have the whole picture. So please, help me with this.

    Best regards, Theis
  2. Moving ER-thinking to OO[ Go to top ]

    At first I must say I also like CMP a lot (I think this is one of the major advantages of J2EE).
    And regarding the issues raised:
    1.) exactly. This is very bad. In fact, it does not reduce portability of applications as long as you see it like the J2EE inventors, because they specify roles, everyone having a specific task. And in fact, you do not have to change code. But the problem is: You cannot easily port data from one appserver to another. This is quite impossible unless you use BMP (but then the problem is the same with databases). Your only chance is to write an "export" utility. However, it may be that Sun addresses this (there is a JSR running for deployment and enhancing portability, but it is not sure what will be covered by it).
    2.) Yes, but who cares? Everything is large in J2EE and if I look at the prices of the servers and at customers who do not care... well. Regarding the maintainability: Let's hope the vendors provide good tools (which is not the case with BEA... sorry, but since I had to work with WL 5.1 after BAS 4.5 I'm a bit angry...). But this should also be addressed by the JSR (in 2-4 years :-)

    And yes, the solution could not only look different, it _does_ look different from vendor to vendor (see above, no data portability).

    Regarding the ER->OO topic and your code. Well, how else to do it? I always work this way (well, you'll need to store a handle to conform to J2EE instead of a remote reference, although at least BAS handles the remote reference quite well (what about BEA? ;-)
    But still, you need to specify the relationships in the xml file. But the reason is another one: Because you will want to look the bean up or, in general, there may be five different "Order" beans deployed in your application (god knows why they just didn't use the package name in general for EJBs) and you'll need to reference to the right one. But the original developer may not know about it, so the deployer needs a way to specify which one it should refer to. This is what the xml file and the "java:comp/env" context is about. As stupid as it sounds, but global names may change, in the local scope the developer knows what he has to cope with and what he can reference to.

    Regarding the global picture: I guess currently no one has ;-) If someone thinks (s)he has, please contact me! It seems even the Sun egineers sometimes do not know what they produced there, J2EE has so many drawbacks which could have been avoided in the first place, but well, compared to the competition it is the best available (unless you believe that .NET will be available before 2005 ;-)