BT

Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ

Topics

Choose your language

InfoQ Homepage Articles EJB 3 Glossary

EJB 3 Glossary

This item in japanese

Bookmarks
Version 1.1.2, Last Update 17.07.2006.  This is an essential glossary of new terms and concepts introduced in EJB 3. The glossary demystifies buzzwords like (IoC), Configuration by Exception, POJO, POJI, Dependency Injection, Embeddable Object, Interceptors, and more. This glossary is a work in progress and will be constantly updated.

Glossary LinksA - B - C - D - E - F- H - I - J- L - M - P - R- S

A

Attached Object - EJB 3.0 - Denotes an instance of an entity bean with its data from the database currently managed by the Entity Manager.



B

Bean Class - EJB 1.x, EJB 2.x, EJB 3.0 - The Bean Class is the artifact of an EJB component that holds the implementation of the business logic. In the object oriented notation one would consider this class as implementation class (e.g. CustomerImpl). With EJBs the term Bean Class is used (e.g. CustomerBean).

Bean-managed Persistence - EJB 2.x, EJB 3.0 - One of the two persistence mechanisms for Entity Beans. With Entity Beans using Bean-managed Persistence (BMP) the developer is responsible for implementing the persistence logic. This means mainly that you have to match the persistent attributes of the Entity Beans with the persistence layer appropriately. In order to do that you have to implement the access logic for the persistence layer (e.g. database using JDBC or legacy system using JCA) in the Bean Class.

  • The EJB container decides when things happen.
  • The developer decides what happens.

Note: In EJB 3.0 Bean-managed Persistence doesn't exist anymore.

BMP - EJB 2.x, EJB 3.0 - Acronym for Bean-managed Persistence

Business Interface - EJB 3.0 - A business interface contains the declaration of the business methods of an EJB Component. Furthermore it is the term to describe POJI-type interfaces in EJB 3.0. Contrary to the EJB 2.x component interfaces these business interfaces must not extend javax.ejb.EJB[Local]Object. The same business interface is not allowed to be both a local and a remote business interface of an EJB component.

Session Beans requires a business interface. Message-driven Beans requires a (business) interface according to the messaging type used (e.g., javax.jms). With EJB 3 this interface for Message-driven Beans will also be called business interface, although this is more technical than a functional interface. EJB 3 entities do not have to exhibit a business interface.



C

Callback Methods - EJB 2.x, EJB 3.0 - With EJB 2.x the Bean Class has to implement the Callback Interface according to the Bean type (javax.ejb.SessionBean, javax.ejb.MessageDrivenBean or javax.ejb.EntityBean). First, these interfaces show which type of EJB you have. Second, these interfaces declare Callback Methods, that are called by the EJB container to manage the lifecycle of an EJB component. The developer has to implement the Callback Methods, that declared in the interface, in the Bean Class.

With EJB 3.0 the mentioned callback interfaces don't have to be implemented by the bean class anymore. Because the developer isn't forced to implement the callback methods, development time and effort is reduced. There is a set of defined annotations to still be able to jump into the lifecycle management of an EJB component. Arbitrary methods can be marked, so that they will be executed at a defined point of time according to the used annotation. You can use these annotations with all types of EJBs. The annotations @PostConstruct, @PreDestroy, @PostActivate and @PrePassivate are applicable to Session Beans and Message-driven Beans. For EJB 3 Entitys the following annotations are applicable: @PrePersist, @PostPersist, @PreRemove, @PostRemove, @PreUpdate, @PostUpate, @PostLoad.

CMP - EJB 2.x, EJB 3.0 - Acronym for Container-managed Persistence

Component Interface - EJB 1.x, EJB 2.x, EJB 3.0 - The Component Interface is the business interface of an EJB component. It comes two ways: as local interface (access is only possible within the same process --> see Local Interface) and/or as remote interface (access is possible across machine and process boundaries --> see Remote Interface).An Component Interface must extend javax.ejb.EJB[Local]Object.

Configuration by Exception - EJB 3.0 - The Configuration by Exception approach was introduced with EJB 3.0. A goal of this approach is the reduction of development times and efforts for the configuration and/or development of EJB components.

The developer should provide only in exceptional cases (thus: Configuration by Exception) configuring or runtime steering information for an EJB component. That is to say only in cases, when the desired behaviour deviates from the defined and given standard behaviour of EJB components of a type. The goal is to reduce the necessity for the explicit indication of configuration parameters for generally expected behavior of EJB components and requirements to the EJB container.

This means concretely that with EJB 3.0 a number of functionalities and/or behaviors are preset for EJB components by default. This default behavior should cover the majority of the typical use cases of the EJB components (and/or the respective EJB types). If the standard behavior does not meet the requirement profile, then the developer can override these default values and/or the standard behavior easily.

Container-Managed Persistence - EJB 2.x, EJB 3.0 - One of the two persistence mechanisms for Entity Beans. If you are using Container-Managed Persistence (CMP) you don't have to write the code for synchronization between Entity Beans and persistence layer. It is generated by tools of the application server. The task of the developer is limited to the declaration of persistent attributes and the relationship between different Entity Beans. The synchronization at runtime is performed by a special part of the EJB container - the so called "persistence manager".



D

DD - EJB 1.x, EJB 2.x, EJB 3.0 - Acronym for Deployment Descriptor

Detached Entity- EJB 3.0 - See Detached Object

Detached Object - EJB 3.0 - Denotes an instance of an EJB 3 entity, which is no longer associated with its persistence context in which it was persisted or retrieved. Thus a synchronization of their data with the database is no longer possible. Such an object is not managed by an Entity Manager. The application could still use a detached object. It can access the available state and make changes but they won't be tracked.

Detached Objects can emerge from different circumstances. For example in the case of serializing an EJB 3 entity. Through serialization the EJB 3 entity becomes a Detached Object.

Dependency Injection - EJB 3.0 - The term Dependency Injection (DI) is a specialized form of the Inversion of control pattern. Martin Fowler invented this term (see http://martinfowler.com/articles/injection.html), because the way inversion of control is used in current lightweight containers/frameworks is more likely to be characterized as the injection of references to objects/classes.

The motivation for the introduction of DI to EJB 3 is to simplify the lookup for resources for EJB components. No JNDI API code is needed in the EJB components anymore. Even though you are free to use it.

DI for EJB technology means, that the developer is freed from implementing code for the lookup of resources via JNDI API. Instead he requests references on resources from the container by simply annotating either instance variables or setter methods in an EJB component or by declaring such dependency specification in corresponding XML. The container then injects at run-time the necessary/requested references on resources into the EJB components before executing one of the methods of the EJB component. I.e. EJB components do not request any longer actively their surrounding containers for references on resources, but get them injected by the containers.

The use of annotations is considerably more convenient than the use of XML. It will be the variant preferred for EJB 3. Here DI is just a simplifying mechanism for accessing the JNDI context and retrieving references.

Deployment Descriptor - EJB 1.x,EJB 2.x, EJB 3.0 - The Deployment Descriptor is an XML file that contains compile- and runtime information for generation and execution of EJB components. This is known as declarative programming, because the developer implements certain functionalities respectively behaviors by simply declaring certain keywords in the Deployment Descriptor without writing a single line of code. For example the transactional behavior of EJB components is controlled this way.



E

Eager Load - EJB 3.0 - Eager Load is one of the both fetching strategies defined in the Java Persistence API. Simply said eager load means that the persistent data of an EJB 3.0 entity is read immediately completely from the database and written into the appropriate attributes of the instance of the EJB 3.0 entity. All referenced persistent entities (EJB 3.0 entities or embeddable objects) within the EJB 3.0 entity will be loaded likewise. In fact the real features of the eager load implementation are depending on the respective implementation of the vendor.

The advantage of eager load is that the data is fetched only once at one go. If the application accesses the attributes the data is already there. The drawback of using eager load with larger persistent object nets or object trees is that this can lead to long loading times and high memory consumption.

EJB - EJB 1.x, EJB 2.x, EJB 3.0 - Acronym for Enterprise JavaBeans, the name of the server side component model of the Java EE platform.

EJB 3.0 entity - EJB 3.0 - An EJB 3.0 entity is a lightweight persistent domain object. The Java Persistence API names this a persistent entity. The latter is owed the fact that the Java Persistence API should be usable no longer only for Java EE, but also for Java SE.

EJB component - EJB 1.x, EJB 2.x, EJB 3.0 - EJB component is a general term for all EJB types (--> see EJB types).

EJB types - EJB 1.x, EJB 2.x, EJB 3.0 - The EJB spec defines with EJB 2.x three EJB types:

  • Session Bean (with the two characteristics stateful and stateless)
  • Message-driven Bean
  • Entity Bean

With EJB 3 the following EJB types are defined:

  • Session Bean (with the two characteristics stateful and stateless)
  • Message-driven Bean
  • EJB 3 entity

Note: With EJB 3 Session Bean and Message-driven Bean will generally named as Enterprise Beans. Lightweight persistent domain objects will be explicitly named as EJB 3 entities or persistent entities.

EJB QL - EJB 1.x, EJB 2.x - Acronym for EJB Query Language.

EJB Query Language - EJB 1.x, EJB 2.x - EJB QL is the query language of the Enterprise JavaBeans component architecture. In analogy to SQL, but focused on objects. Enhanced with EJB 3. 0, but is called Java Persistence Query Language (Java Persistence QL) with EJB 3.0.

Embeddable Object - EJB 3.0 - POJOs that are not EJB 3 entities and hence have no persistent identity can be embedded into EJB 3 entities as attributes. These objects are called Embeddable Objects. The attributes of such Embeddable Objects are filled with data from database tables which are associated with the surrounding EJB 3 Entity.
For example you could map one database table with an EJB 3 Entity and other POJOs embedded by this entity to project a denormalized database table onto an object net.

@Entity
@Table(name="CUSTOMER")
public class Customer implements java.io.Serializable {
    private int id;
    private Address address;
    private String lastName; 
    private String firstName;
public Customer(String lastName, String firstName,String street, String city) { this.address = new Address(street, city); this.lastName= lastName; this.firstName = firstName; } ... @Embedded @AttributeOverrides( @AttributeOverride(name="street", column=@Column(name="STREET")), @AttributeOverride(name="city",column=@Column(name="CITY")) }) public Address getAddress() return address; } public void setAddress(Address address) { this.address = address; } @Column(name="LASTNAME") public String getLastName() { return lastName; } public void setLastName(String lastName) { this.lastName = lastName; } ... Embeddable Object
@Embeddable public class Address implements java.io.Serializable { private String street; private String city; ... }

Enterprise Bean - EJB 3 - On a more generic level Session Beans and Message-driven Beans are denoted as Enterprise Beans. Note that EJB 3 entities are not denoted as Enterprise Beans. This generic term wouldn’t be correct for EJB 3 entities because they can be used in a Java SE environments too.

Entity Bean - EJB 2.x - With EJB 2.x the EJB type for persistent entities is called Entity Bean.

Entity Manager - EJB 3.0 - New element in Java EE respectively Java SE, which was introduced with EJB 3.0. It is (as with JDO and Hibernate) a central persistence manager. The Entity Manager is responsible for the persistence mapping of entities (POJOs). The Entity Manager creates persistent entities in the database, loads, saves, deletes and searches them. It also cares about consistency for concurrent access to entities (concurrency handling).



F

Fetching-Strategy - EJB 3.0- In the Java Persistence API which was specified within EJB 3.0 – two fetching strategies are defined: Lazy Load and Eager Load. In comparison to Hibernate and other persistence providers like TopLink these two strategies and their characteristics are just very few options. More detailing and enhancement of the fetching strategies is presumably planned for the future versions of the specification.

In a majority of cases the Eager Load strategy is preset as default in the Java Persistence API. Lazy Load is used only when it is explicitly stated by the developer. Persistence Provider Runtimes (e.g. Hibernate) are forced to implement and provide the Eager Load mechanism. In the case of Lazy Load it is to be seen just as hint to the Persistence Provider Runtime implementors. There are no more details in the EJB 3 spec on how the Lazy Load mechanism is to be implemented. At the moment it seems as if the exact implementation of the Lazy Load mechanism is up to the implementors of the Persistence Provider Runtimes. This carries a lot of risks like lack of interoperability due to divergent architectural and technical implementation of different vendors.



H

Home Interface - EJB 1.x, EJB 2.x - The Home Interface of an EJB component contains methods to create, delete or load instances of EJB components. As clients are not directly able to create, delete or load instances of EJB components across machine and process boundaries, they are forced to use the Home Interface of the respective EJB component. The Home Interface provides the respective functionalities. Through the use of Home Interfaces, decoupling of EJB components and clients is achieved. The Home Interface represents the design pattern “Factory Method”. There are two flavors of Home Interfaces:

With EJB 3.0 Home Interfaces for Session Beans are not mandatory anymore. This means that they don’t have to be implemented. The specification however doesn’t state that Home Interfaces cease to exist. EJB 3 entities don’t have a Home Interface anymore.



I

Interceptor - EJB 3.0 - With EJB 3.0 it is possible - in analogy to CORBA based systems, where interceptors are widely used for a long time - to intercept calls to business mehtods. You are able to analyze and manipulate parameters as needed and allow or disallow the execution of the business method. With the interceptor mechanism the aspect oriented programming enters EJB based development - at least in the beginning. Interceptors allow to interlace technical functionalities (e.g. logging, tracing, security) transparently into business methods. The developer of an interceptor may implement arbitrary code that is executed when the activated interceptor intercepts a method call to an EJB.

Inversion of Control - EJB 3.0 - Inversion of Control (IoC) is a general characteristic of frameworks and will generally be paraphrased as Hollywood principle ("don't call us, we'll call you"). This shall express that the responsibilities during the program execution are with the framework and not with the components. I.e. the framework where the components are built upon requires of the components that certain callback methods are implemented by them. The framework than uses these callback methods at run-time to inject informations and to trigger determined behaviour.

In the context of EJB 3.0 the terms IoC and Dependency Injection are often used synonymously, even though there are semantic differences in the details (--> see Dependency Injection). What is used with EJB 3.0 is a specialised form of Inversion of Control and is designated as Dependency Injection.



J

Java Persistence API - EJB 3.0 - Within EJB 3.0 (JSR220 in the Java Community Process) the Java Persistence API was developed. The Java Persistence API will become the standard persistence model for Java EE and Java SE. An important characteristic of the Java Persistence API is that it can be used for arbitrary POJOs and is not limited to EJB components only. Thus the Java Persistence API is also available to developers which don’t need/use EJB components in their applications. The leading persistence experts of Hibernate, TopLink, JDO and EJB persistence solutions were involved in the development of the Java Persistence API.

Java Persistence QL - EJB 3.0 - Acronym for Java Persistence Query Language.

Java Persistence Query Language - EJB 3.0 - The Java Persistence Query Language is the query language of the Enterprise JavaBeans component architecture. In analogy to SQL, but focused on objects. Compared to EJB QL the Java Persistence Query Language is extensively enhanced. Many missing features from EJB QL are implemented in the Java Persistence Query Language. The Java Persistence Query Language has a much more richer feature set than EJB QL and looks a little bit like Hibernate HQL.



L

Lazy Load - EJB 3.0 - Lazy load designates – as in other persistence solutions – too, the strategy to only then read the persistent data of a persistent entity (EJB 3.0 entity) from the database if an actual access to the persistent entity resp. their attributes takes place. All with lazy load marked attributes or relations to other persistent entities will be loaded from the database just in time if a dedicated access to such an attribute or relations takes place.

The real features of the lazy load implementation are depending on the respective implementation of the vendor.

The advantage of lazy load is that the data is fetched only if an access to an attribute or relation takes place. This reduces the memory consumption. The disadvantage could be that this just in time fetching of persistent data may be slow down the application.

Local Home Interface - EJB 2.x - The local kind of a Home Interface is called Local Home Interface. It is the so called high-speed kind of Home Interface, because it is only used when the client of an EJB component is located in the same container respectively process. The Local Home Interface - as the Remote Home Interface - is used to create, delete and load EJB components. The Local Home Interface is leaner than the Remote Home Interface, because it can't be called over RMI and has no functionalities for marshalling, unmarshalling and transmitting over the network. The communication between client and EJB component is in-process, hence faster than with Remote Home Interfaces. The Local Home Interface is not able to receive remote method calls.

With EJB 3.0 Home Interfaces for Session Beans are not mandatory anymore. This means that they don’t have to be implemented. The specification however doesn’t state that Home Interfaces cease to exist. EJB 3 entities don’t have a Home Interface anymore.

Local Interface - EJB 2.x, EJB 3 - The technical variant of the business interface (EJB 3) or component interface (EJB 2.x) of an EJB component, which allows only local communication, is called Local Interface. It allows only for in-process communication between client and component. If an EJB component contains only a Local Interface and no Remote Interface, the component is not remotely accessible.

M

Managed Entity/ Managed Object - EJB 3.0 - A managed entity is an instance of an EJB 3.0 entity with a persistent identity that is currently associated with a persistence context and that is therefore managed by an EntityManager.

Message-driven Bean -EJB 2.x, EJB 3.0 - Message-driven Beans (MDB) are used to realize asynchronous workflows in J2EE and Java EE applications. They are message consumers of message brokers. MDBs are able to receive asynchronous messages from these and process them. In the context of Messaging systems Message-driven Beans act thus as message endpoints.

Message-driven Beans hold neither a Home Interface nor a Component Interface (EJB 1.x, 2.x) or a Business Interface (EJB 3). Note: The EJB 3 spec states, that a Message-driven Bean also requires a Business Interface. Concrete is this Business Interface an interface according to the specific messaging type used (e.g. javax.jms). With EJB 3 this interface for Message-driven Beans will also be called business interface, although this is more technical than a functional interface. Due to the fact that MDBs don’t have a real business interface, Message-driven Beans do not have a client visibility. This means that MDBs couldn’t be addressed directly.

Meta-Annotations - EJB 3.0 - Meta-Annotations are dynamic language extensions to the Java programming language. They were introduced with JSR 175 to the JDK 5.0 (a.k.a Java 1.5). Annotations allows to accommodate in the Java code meta information which can be evaluated both at the compile time and at run time. These meta informations can be used to generate code or to steer the run time behavior of an object or EJB component.

Multi-table Mapping - EJB 3.0 - Multi-table Mapping denotes the ability of EJB 3.0 entities to be mapped to more than one physical database table. EJB 2.x doesn't have this ability, except you explicitly program it using Bean-managed Persistence. With EJB 3.0 an EJB 3.0 entity is no simple 1:1 representation of a database table anymore. Instead it is the technical wrapper for a logical business object, whose data can be distributed over several tables. Within the EJB 3.0 entity annotations simply specify which tables/fields are the sources for the relevant data. It’s also possible to do specify the o/r mapping in XML. The EntityManager is responsible for resolving the relational model at runtime and putting the data into the EJB 3.0 entity (see illustration).

EJB 3.0 Entity mapped to three database tables

 @Entity
 @Table(name="CUSTOMER")
 @SecondaryTables({
   @SecondaryTable(name="ADDRESS")
   @SecondaryTable(name="TYPE") })
 public class Customer implements java.io.Serializable {
    private int id;
    private String firstName; // from table "CUSTOMER"
    private String lastName;  // from table "CUSTOMER"
    private String street;    // from secondary table "ADDRESS"
    ...
    // Attribute from main table „CUSTOMER“ 
    @Column(name="LASTNAME")  
    public String getLastName() {
      return lastName;
    }
    ...
    // Attribute from secondary table "ADDRESS"
    @Column(name="STREET", table="ADDRESS")
    public String getStreet() {
      return street;
    }
    ...
    // if no @Column annotation is specified,
    // it is assumed that column name equals attribute name
    public String getFirstName() {
      return firstName ;
    }
 }



P

Persistence Provider Runtime - EJB 3.0 - The term “Persistence Provider Runtime” refers to the runtime environment of the persistence implementation of the Java Persistence API. In Java EE this might be an Java EE container with it’s integrated persistence implementation or a third-party persistence provider implementation integrated with it. In Java SE this is a separate third-party persistence provider implementation (like Hibernate…).

Plain Old Java Interface - EJB 3.0 - This term popped up in journals and eZines in 2004. The term Plain Old Java Interface (POJI) denotes a simple Java interface that is not "soiled" with code related to infrastructure or other technical aspects. The term Plain Old Java Interface (POJI) was introduced in the context of EJB 3.0 as well. The core idea of EJB 3.0 is that EJB components (here: the business interface) become less complex in terms of using them and their micro architecture so that their business interfaces are not “soiled” with code related to infrastructure or technical aspects, but only contains functional method declarations.

Plain Old Java Object - EJB 3.0 - This term popped up in journals and eZines in 2004. The term Plain Old Java Object (POJO) denotes a simple Java class (maybe it should be called POJC;-)), that is not "soiled" with code to infrastructure or other technical aspects, as it typically happens with more complex components. The term was introduced in the context of EJB 3.0 as well. The core idea of EJB 3.0 is that EJB components become less complex in terms of using them and their micro architecture. The goal is to make them so simple that they can be characterized as POJOs

POJI - EJB 3.0 - Acronym for Plain Old Java Interface.

POJO - EJB 3.0 - Acronym for Plain Old Java Object.



R

Remote Home Interface - EJB 1.x, EJB 2.x - The Remote Home Interface enables remote clients to create, load or delete instances of EJBs over the network. Clients do remote method calls using RMI/IIOP protocol to communicate with Remote Home Interfaces. This kind of communication is slower than in-process communication. Remote Home Interfaces have to be used when EJBs shall be offered in distributed systems to clients that are located on any desired machine in the network.

With EJB 3.0 Home Interfaces for Session Beans are not mandatory anymore. This means that they don’t have to be implemented. The specification however doesn’t state that Home Interfaces cease to exist. EJB 3 entities don’t have a Home Interface anymore.

Remote Interface - EJB 1.x, EJB 2.x - The technical variant of the business interface (EJB 3) or component interface (EJB 1.x, 2.x) of an EJB component, which allows remote communication, is called Remote Interface. If an EJB component contains a Remote Interface, clients in other process are able to call the component across process and machine boundaries. This communication uses RMI/IIOP. Even when client and EJB component are located in the same process (for example when the client itself is an EJB component) and the client uses the Remote Interface, the communication uses RMI/IIOP. In this case this would be a needless slow down of communication, which could be remedied by using the Local Interface of the component, which would result in increased performance.



S

SFSB - EJB 1.x, EJB 2.x, EJB 3.x - Acronymn for Stateful Session Bean

SLSB - EJB 1.x, EJB 2.x, EJB 3.x - Acronym for Stateless Session Bean



 

Copyright © 2005-2006 by [objects-at-work] Oliver Ihns and Stefan M. Heldt. All illustrations of the glossary are taken from our own articles resp. book "Enterprise JavaBeans komplett" and are NOT obtained from a third party!

Rate this Article

Adoption
Style

BT