Stateful - is used if you want to have multiple operations & specific to single client
(One stateful instance for a client)
Stateless - container create a pool of instances & forward it when a client request comes, does not matter who is the client
(One instance can serve multiple clients)
Local interface - used if EJB will be accessed locally (same env)
If clients and EJB reside in the same JVM
Remote interface - if your ejb will be used remotely (in different env)
If clients and EJB does not reside in the same JVM
-You use EJB when and only when you need the container services. That is, transaction, persistence and security.
- If you are using Stateless session beans you are scalable because you are stateless.
- While we are at it lets address another common misconception. Lifecycle management. It is often claimed that EJB gives you some necessary lifecycle management and object pooling. It also is supposed to help you in a multi threaded environment. The trouble with this claim is that if you are stateless there are no threading issues and you only need one instance to handle all of your clients on a server. Servlets and stateless Session beans are essentially equivalent ( keep in mind that HTTPServlets are only one type of Servlet). In the world of Servlets the spec allowed you to either create a new Servlet for every client or to use one and make it thread safe. Every servlet container does it the second way and yet EJB only allows containers to do it the first way.
- Performance comes from a good design not from using the container provided services.
- EJB3 over spring because it is a standard, and because it enforce modularity (to certain degree). It's possible to write an EJB once and have it reused by multiple system, regardless of the architecture of the system.
(One stateful instance for a client)
Stateless - container create a pool of instances & forward it when a client request comes, does not matter who is the client
(One instance can serve multiple clients)
Local interface - used if EJB will be accessed locally (same env)
If clients and EJB reside in the same JVM
Remote interface - if your ejb will be used remotely (in different env)
If clients and EJB does not reside in the same JVM
-You use EJB when and only when you need the container services. That is, transaction, persistence and security.
- If you are using Stateless session beans you are scalable because you are stateless.
- While we are at it lets address another common misconception. Lifecycle management. It is often claimed that EJB gives you some necessary lifecycle management and object pooling. It also is supposed to help you in a multi threaded environment. The trouble with this claim is that if you are stateless there are no threading issues and you only need one instance to handle all of your clients on a server. Servlets and stateless Session beans are essentially equivalent ( keep in mind that HTTPServlets are only one type of Servlet). In the world of Servlets the spec allowed you to either create a new Servlet for every client or to use one and make it thread safe. Every servlet container does it the second way and yet EJB only allows containers to do it the first way.
- Performance comes from a good design not from using the container provided services.
- EJB3 over spring because it is a standard, and because it enforce modularity (to certain degree). It's possible to write an EJB once and have it reused by multiple system, regardless of the architecture of the system.
No comments:
Post a Comment