From the diagram, you can see that Stateless and Singleton beans looks very similar when it comes to Client-bean instances, except that in singleton all the clients access single object while in Stateless some objects are uses by clients and returned back to pool.
Developing a Session Bean
Steps to create a session bean:
Define business logic interface
Annotate the business interface
Create the session bean, implementing the interface
After an EJB is instantiated inside the Java EE container, but before it is handed out to a client, the container may initialize property data on the instance according to rules defined for that enterprise bean. This feature is called dependency injection, an external provider initializes the properties of an object instance instead of by the class itself.
■Note Injection uses a “push” model to push data out to the bean, and it occurs regardless of whether the bean actually uses the data. If there is a chance that the data will not be used, the bean may elect to avoid incurring the cost of the resource derivation by performing a Java Naming and Directory Interface (JNDI) lookup in Java code to “pull” the
data, only if it is actually (or likely to be) used.
Common examples of dependency injection use in EJB are as follows:
• Injecting an EntityManager into a session bean for interacting with entities in a persistence unit
• Injecting a UserTransaction into a session bean that manages its transaction demarcation
Even though, the video below is for Spring framework, which is actually EJB’s alternative, it covers the Dependency Injection(DI) pretty well.
A simple rule we follow is this: if we need to decouple our entity and bean classes from their EJB metadata, as when we want to use the same entity classes with two different entity inheritance strategies, we put our metadata in XML.
Otherwise, we stick with annotations. Don’t forget—you can always mix and match, relying on the firm policy that whenever metadata is specified for an element using both XML and annotations, the XML always wins. This allows any role (see the “EJB Roles” section later in the chapter) downstream of the bean developer to override metadata settings without having to update the Java source, since overrides can be applied exclusively to the XML descriptors.
uses ejb-jar.xml or server specific file.
more annotations is better
A more advanced strategy, which is also recommended, is to use annotations only when defining behavior of an enterprise bean or an entity that is truly integral to its definition, such as the relationship type of an entity relationship field, or the transactional requirements of a method on a session bean. Anything that could reasonably be overridden, such as the name of the table to which an entity maps, or the details of a value generator used for populating the primary key on an entity, would go in the XML descriptor, where it can be specified at deploy time by an application assembler, perhaps in consultation with a database administrator. While there is no harm in specifying default values using annotations in the Java source file, this approach recognizes the difference between firm metadata, which ought not to be modified, and loose metadata that may be freely modified without changing the behavior of the enterprise bean or entity.