XML and Annotations in EJB

XML vs Annotations

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.

Features of EJB:

This are the features of EJB:

Declarative Metadata:

Ability for developers to specify the behavior of both enterprise
beans and entities declaratively (as opposed to programmatically) using their choice of Java annotations and/or XML descriptors. Much customization can be added to a bean without having to encumber the Java source with service implementation code. To accommodate developer preference and application flexibility, EJB offers developers their choice of both annotations and XML, with the ability to use both methods simultaneously within the same EJB or entity, for specifying behavior in metadata. In cases where the same piece of metadata is defined both in an annotation and in XML, the XML declaration takes precedence in resolving the conflict.

Configuration by Exception

In the most common cases, where the default behavior is leveraged(used to the maximum), this approach leads to very sparse, clean code.
This development model is known as configuration by exception, because only in exceptional (non-default) cases it’s necessary to configure the behavior of the component explicitly.


EJB is scalable, enough said.

Location Transparency

EJBs may be configured for remote access, allowing them to be accessed across a network connection. A client, which may be another EJB, simply requests an instance of a remote EJB, and the local and remote EJB containers transparently manage the communication details.


The Java Transaction API (JTA) defines a standard API for distributed transactions, and the EJB container acts as a JTA transaction manager to EJBs. Since its inception, the EJB spec has defined a standard model for declaratively specifying container-managed transactional behavior on enterprise beans.

Multiuser Security

Method-level access control may be specified declaratively on EJBs, enforcing user– and role-level privileges defined by application server administrators.


EJBs are loosely coupled components. An EJB may be reused and packaged into multiple applications, though it must
be bundled with, or have access to, the business interfaces of dependent EJBs.


Although no longer covered in the EJB spec, JPA entities are an essential complement to EJB. Entities are persistent domain objects with unique identities. An entity class maps to a database table, and each entity instance is represented by a single row in that table.

What is Enterprise Java Beans(EJB) and what are it’s components

Enterprise Java Beans(EJB) in my my understanding is required for invocation of some methods on objects on remote machines. In other words, client will have it’s own copy of object perform the desired operation on it’s local machine and this object later will be serialized and sent to remote machine. Ex.: when you use your browser to update your personal information such as phone number, your local machine will create user object, get the updated value of phone number(user object has phone number attribute) then this object sent to the bank’s app server where the app will update the database. That’s it.

There are 3 components of EJB:

  1. Session beans. Below are the types of session beans, they all perform business service operations
    1. Stateless
    2. Stateful
    3. Singleton
  2. Message driven beans are invoked asynchronously in response to external events through association with messaging queue.
  3. Entities are objects that have unique identities and represent persistent business data. Persistent data in human language means write or read data to database.

1 and 2 considered as enterprise beans and 3 is not. (starting from ejb 3.0 entities are not beans)

Very good introduction video about EJB 3.0