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.


Good naming in programming

It should tell you why it exists, what it does, and how it is used. If a name requires a comment, then the name does not reveal its intent.

steps for good naming

  1. write the method
  2. rename the attributes to meaningful names
  3. be careful with names that are different only a little bit ex.: XYZabcdStorageHandling and XYZabcdLocationHandling
  4. no l or 0 letters in variable names since they look like digit 1 and 0
  5. Noise words are redundant. The word variable should never appear in a variable
    name. The word table should never appear in a table name. How is NameString better than Name? Would a Name ever be a floating point number? If so, it breaks an earlier rule about disinformation. Imagine finding one class named Customer and another named CustomerObject. What should you understand as the distinction? Which one will represent the best path to a customer’s payment history?
  6. WRONG!
    1. getActiveAccount();
    2. getActiveAccounts();
    3. getActiveAccountInfo();
    1. Class Names
      Classes and objects should have noun or noun phrase names like Customer, WikiPage, Account, and AddressParser. Avoid words like Manager, Processor, Data, or Info in the name of a class. A class name should not be a verb.
    2. Method Names
      Methods should have verb or verb phrase names like postPayment, deletePage, or save. Accessors, mutators, and predicates should be named for their value and prefixed with get,set, and is according to the javabean standard.
      string name = employee.getName();
      if (paycheck.isPosted())
  7. However one might decide to use the word add for “consistency” when he or she is not in fact adding in the same sense. Let’s say we have many classes where add will create a new value by adding or concatenating two existing values. Now let’s say we are writing a new class that has a method that puts its single parameter into a collection. Should we call this method add? It might seem consistent because we have so many other add methods, but in this case, the semantics are different, so we should use a name like insert or append instead. To call the new method add would be a pun. Using the same term for two different ideas is essentially a pun.

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