EJB Design Question

bonkey

OK...

I have this app which for one reason or another uses a lot of Stateless Session Beans on the server side.

I have a set of new functionality which I would like to use from *every* one of these Beans. I'm trying to decide what is the best way to design this.

The obvious choices are :

1) Implement the common methods in some JCBean class which implements the SessionBean interface, and then modify all the other beans to extend JCBean.

2) Implement the common functionality in a seperate Bean, and simply call bean-to-bean when I need it.

Option 2 requires slightly less work, but I would prefer a solution like 1 if theres no good reasons why I shouldnt do it.

Anyone any thoughts to offer pro or con the various options? Any have other options?

jc

lynchie

I personally would go with the second option. Put all the common business logic into a separate bean is the best way of doing it. You shouldnt really be subclassing to achieve this.

If you are using the new 2.0 spec you should be able to use local interfaces to improve performance between calls to the common logic bean.

This is just how I would do it and there is no reason why option 1 wouldn't work. I can't think of any obvious cons to doing it using the first option except that changing the code in the JCBean would require you rebuilding all beans that extend it whereas using option 2 you could just redeploy the common bean without affecting all the other beans that use it.

bonkey

Originally posted by lynchie
If you are using the new 2.0 spec you should be able to use local interfaces to improve performance between calls to the common logic bean.

Im using J2EE 1.2.1, with no option to change that.

This is just how I would do it and there is no reason why option 1 wouldn't work. I can't think of any obvious cons to doing it using the first option except that changing the code in the JCBean would require you rebuilding all beans that extend it whereas using option 2 you could just redeploy the common bean without affecting all the other beans that use it.

In theory, option 1 would be faster. As for rebuilding...the way the app is managed, we do a complete rebuild for each release anyway, so thats not an issue.

My leaning towards option 1 (subclassing in some way) is that it should yield better performance, or am I wrong in that.

jc

lynchie

It should yield better performance than option 2 as it doesnt need to make a remote call to another bean to access the data, instead it is just making a local method call. You should be fine with proceeding with option 1.