Session Beans vs. Java Classes
Need as many opinions as possible for the following design decision:
I need to implement some business logic "A". Now I can 1) create a plain Java-Class that is able to perform all actions necessary or 2) I could implement an EJB-Session Bean which does the same thing.
In both cases there is a session-facade pattern used which accesses this business-logic and another layer "XY" that encapsulates direct access to entity-beans (this additional layer is introduced in order to facilitate other database-to-object conversion mechanisms than J2EE Entity-Beans and providing additional caching mechanisms).
Obviously in the 1st approach the component "A" can be used in other environments than an application-server (this is also the main reason for thinking about using plain java-classes). Since the session-facade pattern enables transactions in this approach the gap between starting the call from the session facade and the access to the Entity-Beans need not necessarily be filled with other EJB-Components.
short-version for both approaches:
1) session-facade->Java Class "A"->XY->Entity-Beans
2) session-facade->Session Class "A"->XY->Entity-Beans
Thanks in advance!
[1239 byte] By [
knora] at [2007-9-29 5:04:07]
Hi,
> Obviously in the 1st approach the component "A" can be
> used in other environments than an application-server
> (this is also the main reason for thinking about using
> plain java-classes).
I think this should not be a reason. SessionBeans exist for
the implementation of business logic. This is a proven way.
You have to find out, if you are able to use stateless or
stateful beans. In the case of stateless Session beans, the
EJB Container manages a lot of work (e.g. pooling) for you.
> Since the session-facade pattern
> enables transactions in this approach the gap between
> starting the call from the session facade and the
> access to the Entity-Beans need not necessarily be
> filled with other EJB-Components.
I read about the session facade pattern. But the session bean
itself may represent the facade, you don`t need an extra class.
I would try to implement a "use case facade". One SessionBean
for one use case. Helper classes for these Beans can also be
deployed on the to the server. But I see no reason for building
a non EJB Layer between requestor and persistence logic.
Also important: If stateful beans are required, pay attention on
the number of users accessing the application server. stateful
beans don`t provide pooling, so if you have 1000 users on your
server, you have also 1000 SessionBeans instances running !
>
> short-version for both approaches:
>
> 1) session-facade->Java Class "A"->XY->Entity-Beans
>
> 2) session-facade->Session Class
> "A"->XY->Entity-Beans
>
> Thanks in advance!
- The most important design decision is whether to use EJB in the first place. However you seem to have already made that decision, since you have Entity beans (bad call, use JDO instead, but that's another subject..).
- As to wether to use session beans, you should consider whether your application needs it (Is the application distributed, heavily transactional, with multithreading issues etc..) rather than any potential future use w/out app servers.
Anyway, the biggest performance issues reside with the use of Entity beans and stateful session beans (as outlined in a previous post), rather than stateless session beans that live in a pool and can service a rather big number of clients.
- By using a Business Delegate, i.e an intermediary class between the Web components and the biz ones, you can hide the fact that you're using EJBs or plain java classes to implement your biz logic.
The biz delegate will throw EJB-independent exceptions (catch the EJB exceptions and throw meaningful ones for the client) and take as args / return application-specific objs (more precisely DTOs - Data Transfer Objs).
In the future, if you'll need to switch from plain java classes to EJBs (or vice-versa), you 'll be able to do it w/out changing the front-end components, since the calls to the biz tier will be the same).
