I wouldn't know if this causes technical issues by doing this, but from a design standpoint it is always a good idea to keep you EJB & Bussiness Logic decoupled.

If your business logic is tied tightly to EJB (or anything else for that matter) then it is impossible to use in a context where the EJB is not valid. Maybe you want a batch process to perform a validation defined in your business object, but you cannot use it because you need EJB in order to do so.

I can see that since you are deriving your EJB from your bean, your bean appears to not be coupled to the EJB, however, this is not necessarily true. If your interface to your EJB function needs to change independtly of your bean function you need to start jumping through hoops.

Also, you want to be careful that the granularity of your EJB is not to fine. Beans can sometimes be fine grained where you call a bunch of methods on your bean in a certain sequence to perform the validation/transformation you want. If this sequence includes a lot of individual calls to the bean, you don't want to propogate that to your EJB.

If a client is making a log of individual calls to your EJB, each of these calls might be a network hop. Instead you want to pass everything you need to the EJB and the EJB will coordinate the sequence of calls to the bean. The EJB becomes a facade to your bean and will give you the things that you are using EJB for (transaction control, caching).

If your bean does not have a lot of funtions, then its really not a big deal to have the EJB forward each call explicitly.

One other issue I would have with your implemenation is that the function that you are calling is not defined in the EJB you are making a call to. If I'm calling orderEJB.createOrder(order) then I expect to see a createOrder function in the bean. It can be confusing if you go and find the function does not exist there. This is obviously a matter of preference, but I'd prefer that function to exist in the EJB class.

From a Design Patterns standpoint you should have atleast 3 separate classes here. One is a Session Facade which is typically a Stateless session bean that hides all the business logic and is used to get declarative transaction support etc. The second one is a Business Object where all the business logic is encapsulated. All the business validations should be in this class. The third class can be an Entity Bean, if you plan to use one or a Transfer Object (or Value Object) and a Data Access object. The TO contains the entity attributes and getter and setter methods and the DAO contains all your database acess routines.

TechTarget provides technology professionals with the information they need to perform their jobs - from developing strategy, to making cost-effective purchase decisions and managing their organizations technology projects - with its network of technology-specific websites, events and online magazines.