aspose file tools*
The moose likes EJB and other Java EE Technologies and the fly likes Have session bean extend some java class Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of Soft Skills this week in the Jobs Discussion forum!
JavaRanch » Java Forums » Java » EJB and other Java EE Technologies
Bookmark "Have session bean extend some java class" Watch "Have session bean extend some java class" New topic
Author

Have session bean extend some java class

Caroline Iux
Ranch Hand

Joined: May 14, 2001
Posts: 103
Hi, everyone,
I've seen some people extend their session beans from a java class and put all the business methods in the java class. The argument is by doing this, they gain the flexibility of opting out EJBs if they need too. For example, at the application startup, read a property file which specifies whether or not to use EJB.
I'd like to hear your opinions on this.
Kyle Brown
author
Ranch Hand

Joined: Aug 10, 2001
Posts: 3892
    
    5
Personally, I think it's cleaner to simply put your business methods in a completely separate class and use composition rather than inheritance. This is the idea behind the Session Facade pattern.
Kyle


Kyle Brown, Author of Persistence in the Enterprise and Enterprise Java Programming with IBM Websphere, 2nd Edition
See my homepage at http://www.kyle-brown.com/ for other WebSphere information.
Caroline Iux
Ranch Hand

Joined: May 14, 2001
Posts: 103
Thanks for you reploy, Kyle.
I understand Session Facade is to encapsulate the business flow and interactions between business objects. I don't think it particularly uses composition though. Could you elaborate on what you mean by "composition"?
Also if you don't have use inheritance, then in the session bean, every remote method will delegate to the seperate java class for processing?
Craig Demyanovich
Ranch Hand

Joined: Sep 25, 2000
Posts: 173
Caroline,
I'm a bit confused by the design that you mention in your original post. A technique that I use may be helpful to you, so here it is.
I create an interface that defines my business methods, say PersonBusiness. PersonRemote, the remote interface, extends PersonBusiness, but does not provide any further behavior. PersonBean, the bean class, implements PersonBusiness. The main reason for this is compile-time type-checking, i.e., to ensure that PersonRemote and PersonBean agree on the behavior of the bean.
Now, PersonBusiness must declare that it throws RemoteException: PersonRemote must declare that it throws RemoteException as a remote interface, and an interface or class must not declare that it throws more exceptions than what it implements or extends. However, it may declare that it throws less exceptions or none at all. Consequently, you could write a non-EJB implementation of PersonBusiness and use it when EJBs are not required. Finally, I wonder how and why you intend to do this in a dynamic way.
Craig
Caroline Iux
Ranch Hand

Joined: May 14, 2001
Posts: 103
Craig,
Thanks for you reploy. I am not particularlly in favor of this design. All I am saying is that I've seen people implement it this way and want to bring up a little discussion about it.
To elaborate a little bit on the design:
You have the bean class PersonBean, a remote interface Person. We all know that the bean class should have the implementation of all the remote methods that you want to expose. Some people do this by creating a separate java class called PersonBusiness. (Let's assume this is EJB 1.1) Note contrary to what you mentioned, the PersonBusiness is not an interface, but a class with the implementation of remote methods.

public class PersonBusiness {
public void remoteMethod2()
{
....
}
public void remoteMethod2()
{
....
}
}
Since in EJB 1.1, remote methods in Bean class not longer throw RemoteException but EJBException, we don't need to have throws clause in the method declaration since EJBException is a runtime exception.
And PersonBean will look like this
public class PersonBean extends PersonBusiness implements SessionBean {
...
}
Again I am not saying this is a good or bad design. Some people argue by doing this if they want opt out EJBs, they have PersonBusiness, which is all they need.
Look forward to hearing your opinion.
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: Have session bean extend some java class