Wednesday, December 21, 2005

Stateless Session beans kill Object Orientation??

Stateless Session beans kill Object Orientation??

Recently I had a chance to have close look at OO principles as I had to prepare to deliver a lecture for a ‘advanced OO development’ course. This allowed me to have a back look on OO after working in several commercial J2EE projects. I started thinking… in those projects, have we used proper OO with real encapsulation, inheritance and polymorphism principles??? Answer was “NOP”…


In most of the J2EE projects people tend to use more service oriented approach rather than going for a object oriented approach due to the J2EE technology limitations. For an example most of the business objects are just plain DTOs where Stateless session beans acts as service providers for those DTO business objects (as an EJB best practice, DTOs are used to transfer entity bean data across tiers :D ). Most of the so called “DTO business objects” are just having a bunch of getters setters encapsulating the attributes. Is this real encapsulation??? No… we need to have the object operations to encapsulate the attributes of our objects. But with DTO business objects we are separating out the object data from its operations causing less encapsulated objects. Making the things worse, stateful session beans did not proved itself in the industry, making OO much away from the J2EE projects.


At least do we get inheritance properly? Session beans do not support direct inheritance making polymorphism also to be impossible. Having no polymorphism in our business objects directly affects the design quality. We end up with lot of if-else clauses handling different variations of our business object types. It is true that there are tips and tricks to get around with EJB inheritance problems, but that is not we need as poor OO programmers. We need tools (J2EE) to help us; we don’t have much time here to help the tools…


So where are we heading??? EJB 3 seems a good improvement but still it doesn’t provide all we need. Some times it seems to be bias at J2EE server vendors but not at the java developers (may be as the spec committee is mostly driven by application server vendors). Anyway I wish to talk more on EJB 3 and OO principles in another post.


Considering all, for me it seems going for Spring Framework is still a better approach, especially when you do not need your system to be distributed across several VMs. In my opinion, stateless session beans still are a superior technology for a locally distributed system (When it is not local there are much better solutions like XML over HTTP). When we think of such locally distributed systems we should think those distributed components as services, not as objects. Internally within components we have to follow clean OO principles. In summery we can develop our logic on plain well object oriented object model and expose the operations (if needed) as services over stateless session bean. I believe that approach gives us a better, and maintainable system.

3 comments:

88Pro said...

I guess EJBs were never meant to be for stuff that runs on a single VM (small projects), its for the eBays and Amazons :-)

I guess to kill a fly if we use a sward, its going to be the problem with the tool selection and not the tool itself I guess :-)

88Pro said...

How J2EE Killed Object-oriented Programming

Hasith Yaggahavita said...

Cool... thanks for the link. That post look at the problem in a more broader view.