It's not odd design. One reason could be that ServiceImpl code already exists
I am assuming your services/business methods are exposed thru BusinessDelegate to outside world.
Originally posted by Rahul Devgan:
Reflecting further, what he has also suggested is a separation of concerns to a finer level. The bean does not care about how the biz logic will be implemented and is only taking care of life cycle implementation, if any.
I have different take on this. Am just trying to reason why your architect might have suggested the approach of using the super class. I am not sure how complex your system is or how many methods this Session Bean has but I think the rationale behind his decision is performance and memory consumption. If we have a set of wrapper methods, then the EJb does not own the actual method and the JVM would create a object of the class implementing the methods. However, if the EJB is a sub-class then the implementation is within the EJB and the number of objects at runtime would be lesser.