The problem with EJB inheritence is really in the EJBHome objects. You generally have to create distinct EJBHomes for every Bean, and as far as I can see, its not a good idea for one EJBHome to inherit from another. The problem is in the create() methods. In your case, SessionManagerHome's create() method returns a SessionManager. However, if you create a PatientSessionManagerHome that extends SessionManagerHome, you can't have the create() method return something different without a different set of args (this problem with method overriding for factory methods is generally avoided in conventional Java by the use of constructors, which are NEVER inherited). If you make a different set of args, then you're still left with a create() method that returns an obect which is NOT the EJBObject for PatientSessionManagerHome, and most containers will not know how to implement it. So basically, the inheritence method I suggested above is really a kluge. There is no good solution for create methods, but one possiblity for EntityBean finder methods is to really take advantage of the ambiguity of Collection and Enumeration return values in finder methods. Have all of your finders return Collection of Enumeration, and you get around the problem of different return values in the subclass's method. However, this won't work for findByPrimaryKey(), which MUST return a distint instance of the EJBObject interface. Also, its a generally ugly solution for many OO reasons (type security, and you're essentially narrowing the scope of allowable return values).
Anyway, this is all just my opinion. I'd love to hear it if anyone has figured something out that has escaped me.
-Dan
Adam Winter wrote:
Thanks for your reply. In answer to your question...> > Second, does inheritance of Session Beans, work the same as other
> > inheritance in Java? The answer is probably yes, but I've
> > never seen this
> > covered. Every EJB I've seen has extended EjbObject. Can I still have
> > abstract super classes?
>
>Certainly you can derive from your own abstract base classes, as long as
>they derive from EJBObject. Out of curiosity, why do you want to do
>this?In our web-based application all users see a common log-on screen, and
after their authentication, based on their user role, we redirect them to
the appropriate user interface. To represent that I envisioned having a
"SessionManager" Statefull Session bean, which would govern what was
possible based on that user's role. It would encapsulate other entity
beans, representing the other people and application objects that the
logged in user is allowed to participate with. In accordance with what I
think is good OO designed, I pictured having "SessionManager" as abstract,
and deriving sub-classes based on user roles. In the case of my domain,
health care, there might be a PatientSessionManager, a
PhycisianSessionManager, and ClericalSessionManager. By doing this I can
store the commonality (of which there are a few) in the super class. I
think the case for inheritance amongst business logic is pretty strong.-adamw
-- Daniel G. Koulomzin Digital Media On Demand 244 Brighton Ave. 3rd Floor Allston MA 02134
