Does the EJB architecture actually adhere to a good OO model?


EJB design: Does the EJB architecture actually adhere to a good OO model?

  1. I'm only new to EJB, but I have been developing OO for 4+ years now. I have to say that I don't like the way that some of the session type classes don't actually model an object, rather they represent a process, YUCH!

    In the end you have a bunch of classes which encapsulate business logic, this logic should, IMHO, be encapsulated in the object which they are related to.

    Am I way of base in my EJB understanding?
  2. Unfortunately, no, you're not. Almost all of the patterns recommended by EJB experts (and on this site) to improve performance simply reduce your code to a procedural morass, destroying any benefits you might gain from OOP.

    For example, take value objects. They <em>blatantly</em> violate encapsulation, but are necessary to get decent performance. The very thing that could make your EJB code OO, entity beans, perform very poorly.

    The fact is that real websites need to perform. I'm not convinced you can build a website today that adheres to good object oriented principles and still has adequate performance. I don't think this is a fault of EJB per se, but of all our current options.

  3. you can read my response here

  4. Tinou,

    I agree with much of what you said in your response; it is indeed POSSIBLE to program EJBs in a very OO manner. You say:

    "EJB does not prevent you from designing and implementing an OO based application."

    I agree, but my point is that it is very difficult to develop a well designed OO application with EJB that scales. In order to get that scalability you have to sacrifice much of what makes OO good. Well designed OO applications are usually very "chatty," being a collection of objects that send messages to one another through well defined interfaces. Unfortunately, remote calls are expensive and chattiness kills your performance. The solution? Wrapping entity beans with session beans to reduce the number of network calls (or not using entity beans at all). In a traditional OO app, your entities would have most of the logic; now, your data and behavior are once again separated, and you have degenerated to an RPC system with some nice transaction and persistence (if you use CMP) support.

    The simple fact is that programming an EJB app (or any networked app) usually forces you to break encapsulation in order to get decent performance. Perhaps this will change with local interfaces on entities...only time (and performance tests) will tell.

  5. Thanks Steve, its nice to see that I'm not doing something wrong!

    Tinou - the link to you site brought up an internal server error from the site, buit thanks anyway
  6. Gareth, you're absolutely right. There is a significant "impedance mismatch" between classical OO and distributed programming. Classical "pure" OO was developed with the inherent assumption of "one-processor local computing". With the fundamentally qualitatively different feature of distribution thrown into the mix, this changes the programming model significantly. Note that there is nothing inherent to EJB about this - the problem is the distributed context, e.g. EJB, CORBA, and COM etc all share these issues.

    Jim Waldo and others succinctly summarized these points in a timeless and seminal work:
    "A Note on Distributed Computing"

    Another excellent article that highlights these issues is Gemstone's:
    "How to Build a Really Big Distributed J2EE System Using Tools You Have Around the Office"

    Finally, Wiki has some pertinent discussions on this topic:

    -- Sam