Business logic in EJB

[PN Kumar]

EJB are meant to implement business logic of the systems concerned. However, we try to lighten the EJB in most cases by moving the core business logic further inside into the helper classes - a typical case would the petstore architecture using the eventHandlers and StateMachine - in which case the business logic moves out of the EJB.Doesnt this contradict the very purpose of EJB's?Or am i missing out on something here?

[Paul Sturrock]

In a session facade pattern (for example) you would include no business logic in your ejb. All they would do is call domain objects which do the actual work. In that case you are using the container features avaliable to an ejb as the entry point to your app (and the one feature usually highlighted for a session facade pattern is scalablility), but the work is done else where.

[Kyle Brown]

Paul's right. The Session bean gives you transactions, method-level security, and distribution. You STILL have those if you use the session facade pattern. You lose nothing and gain a better-factored system.

You might improve your understanding of the pattern (and why you want to apply it) by reading this article.

Kyle

[PN Kumar]

Understand the benefits of using facade pattern in petstore. While i quoted petstore as a sample case in my question - i <b>do not</b> restrict myself to petstore architecture. To rephrase my earlier question, is there any significant drawback if using stateless session bean, we do bulk of the business logic processing in the bean itself where the application consist of a single stateless session bean only ?

[Kyle Brown]

Yes, it will be impossible to test the business logic outside of an EJB container in this case, and if you ever need a different transaction attribute or security setting other than the one set in your EJB you'll need to copy the code out of your EJB.

Kyle

[Bruno Collet]

I think there is a confusion about doing the business logic in an EJB and doing it in the EJB container.
An EJB is likely to instanciate ordinary Java classes to handle business logic. Nonetheless, these ordinary Java objects are still executed in the EJB container and in the context of the EJB that instanciated them. Therefore they benefit from all services of the EJB container according to the configuration of the EJB (transactions, security...).
The reasons are:
- to avoid having super-sized EJBs
- to ensure decoupling and cohesion of different business logics, that might be initiated from a same EJB (such as a Facade as mentioned before).

[PN Kumar]

Thanks Bruno for your reply. Thats what i was looking for - "these ordinary Java objects are still executed in the EJB container and in the context of the EJB that instanciated them..."