There are 2 types of enterprise Beans:
- Session beans (can be: statefull; stateless and singleton): this beans are called in a synchronous way and perform tasks for clients;
- Message-Driven: this beans are called asynchronously and act as a listener for msgs;
Session beans allow you to send JMS messages and to receive them synchronously but not asynchronously. To avoid tying up server resources, do not to use blocking synchronous receives in a server-side component; in general, JMS messages should not be sent or received synchronously. To receive messages asynchronously, use a message-driven bean.
Session Beans:
- can be called localy, remotely or trough a webservice; Session beans provide a simple but powerful way to encapsulate business logic within an application. They can be accessed from remote Java clients, web service clients, and components running in the same server. The primary purpose of a session bean is to run business tasks for the client. The client invokes business methods on the object reference it gets from dependency injection or JNDI lookup. From the client’s perspective, the business methods appear to run locally, although they run remotely in the session bean.
- not persistent (are not saved into db);
There are 3 types of Session Beans:
- Stateful Session Beans:
the bean stores information for only one specific client (ex. useful for a "shopping cart"); - Stateless Session Beans:
this beans are shared among clients (can be in a pool for example) because they dont store state for a specific client; - Singleton Session Bean:
there is only one instance of this bean and it shares its state between all clients;
the diference between this and stateless beans: there is only one instance of the singleton (stateless can have multiple instances running at the same time);
this bean can store application state (ex. database access connections) but not client specific state;
Stateful beans cannot implement webservices while the other 2 can;
Note: While it isnt mandatory for local beans, all enterprise beans that permit remote access must have a remote business interface [1].
Note: While it isnt mandatory for local beans, all enterprise beans that permit remote access must have a remote business interface [1].
Naming Conventions
Because enterprise beans are composed of multiple parts, it’s useful to follow a naming convention for your applications (Naming Conventions for Enterprise Beans):
Item
|
Syntax
|
Example
|
|---|---|---|
Enterprise bean name
|
nameBean
|
AccountBean
|
Enterprise bean class
|
nameBean
|
AccountBean
|
Business interface
|
name
|
Account
|
Enterprise beans lifecycle
Info from: The Lifecycles of Enterprise Beans
Tags used for lifecyle management:
- @PrePassivate: This only applies to stateful beans since the others don't get passivated. The EJB container invokes the method annotated @PrePassivate, if any, immediately before passivating it (While in the ready stage, the EJB container may decide to deactivate, or passivate, the bean by moving it from memory to secondary storage. Typically, the EJB container uses a least-recently-used algorithm to select a bean for passivation.)
- @PostActivate: If a client invokes a business method on the bean while it is in the passive stage, the EJB container activates the bean, calls the method annotated @PostActivate, if any, and then moves it to the ready stage.
- @Remove: At the end of the lifecycle, the client invokes a method annotated @Remove, and the EJB container calls the method annotated @PreDestroy, if any. The bean’s instance is then ready for garbage collection. Business methods annotated with javax.ejb.Remove in the stateful session bean class can be invoked by enterprise bean clients to remove the bean instance. The container will remove the enterprise bean after a @Remove method completes, either normally or abnormally.
- @Startup: The EJB container initiates the singleton session bean lifecycle by creating the singleton instance. This occurs upon application deployment if the singleton is annotated with the @Startup annotation.
Singleton beans annotations:
- @Singleton [2]: the javax.ejb.Singleton annotation is used to specify that the enterprise bean implementation class is a singleton session bean.
- @Startup [2]: the EJB container is responsible for determining when to initialize a singleton session bean instance unless the singleton session bean implementation class is annotated with the javax.ejb.Startup annotation. In this case, sometimes called eager initialization, the EJB container must initialize the singleton session bean upon application startup. The singleton session bean is initialized before the EJB container delivers client requests to any enterprise beans in the application. This allows the singleton session bean to perform, for example, application startup tasks.
- @DependsOn [2]: Sometimes multiple singleton session beans are used to initialize data for an application and therefore must be initialized in a specific order. In these cases, use the javax.ejb.DependsOn annotation to declare the startup dependencies of the singleton session bean. The @DependsOn annotation’s value attribute is one or more strings that specify the name of the target singleton session bean. If more than one dependent singleton bean is specified in @DependsOn, the order in which they are listed is not necessarily the order in which the EJB container will initialize the target singleton session beans. ex. @DependsOn("PrimaryBean") guarantees that the EJB container will initialize PrimaryBean first.
- @ConcurrencyManagement [2]: Singleton session beans are designed for concurrent access, (situations in which many clients need to access a single instance of a session bean at the same time). When creating a singleton session bean, concurrent access to the singleton’s business methods can be controlled in two ways by annotation the bean class with either:
and bean-managed concurrency.- @ConcurrencyManagement(ConcurrencyManagementType.CONTAINER): container-managed concurrency, in this mode you an use the built in annotations @Lock and @Timeout;
- @ConcurrencyManagement(ConcurrencyManagementType.BEAN): Singletons that use bean-managed concurrency allow full concurrent access to all the business and timeout methods in the singleton. The developer of the singleton is responsible for ensuring that the state of the singleton is synchronized across all clients. Developers who create singletons with bean-managed concurrency are allowed to use the Java programming language synchronization primitives, such as synchronization and volatile, to prevent errors during concurrent access.
- @Lock [2]: can be used to annotate entire classes or methods individually.
This annotation is for "Container-Managed Concurrency" only (because if you are using "Bean-Managed Concurrency" you have to provide your own control through concurrency primitives like synchronize or volatile).
You can annotate classes/methods with two different types of locks (LockType enumerated types):- @Lock(LockType.READ): For read-only operations. Allows simultaneous access to methods designated as READ, as long as no WRITE lock is held. So if there is no WRITE lock on the bean every READ method can be accessed simultaneously.
- @Lock(LockType.WRITE):For exclusive access to the bean instance. A WRITE lock can only be acquired when no other method with either a READ or WRITE lock is currently held. If there is a client accessing one WRITE method then neither other READ or WRITE methods can be run on the bean until the WRITE lock is concluded.
Resources
[1] - The cart Example
[2] - A Singleton Session Bean Example: counter
Sem comentários:
Enviar um comentário