• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

Have session bean extend some java class

 
Ranch Hand
Posts: 103
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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.
 
author
Posts: 3892
5
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
 
Caroline Iux
Ranch Hand
Posts: 103
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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?
 
Ranch Hand
Posts: 173
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Posts: 103
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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.
 
a wee bit from the empire
a bit of art, as a gift, that will fit in a stocking
https://gardener-gift.com
reply
    Bookmark Topic Watch Topic
  • New Topic