Home
Über uns
Kontakt

Meldungen
Links

Bücher
Artikel
Rezensionen
Poster
Vorträge

Architekturen &
  Muster
Performanz &
  Skalierbarkeit
EJB
CORBA
SOA

EJB 1.x
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."

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 anymore. Because the developer isn't forced to implement the Callback Methodes, 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 Entity Beans the following annotations are applicable: @PrePersist, @PostPersist, @PreRemove, @PostRemove, @PreUpdate, @PostUpate, @PostLoad.

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).

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."

EJB 1.x
EJB 2.x
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.

DI for EJB technology means, that the developer isn't responsible for implementing the access to external resources. Hence the EJB component is no longer actively requesting resources from the surrounding EJB container. Instead the developer uses annotations to mark certain places in the component and the container injects the necessary references.

The Java EE 5.0 specification provides the annotation @Resource for that purpose. Remark: As the EJB 3.0 specification is not final yet, there have been different annotations (e.g. @Inject) within this specification. In the course of harmonization of the Java EE platform these annotations have been eliminated. Now the remaining annotation is @Resource, which is used to inject resources to different components like EJBs, Web Services, Servlets etc.

POJOs that are not marked as Entity Beans can be embedded in EJB 3.0 Entity Beans. These Objects are called Embeddable Objects. The attributes of Embeddable Objects are filled with data from the database table associated with the surrounding Entity Bean.

For example a database table is mapped with an Entity Bean and its embedded objects to project a denormalized table on an object net.

Entity Bean with link to an Embeddable Object

@Entity
@Table(name = "CUSTOMER")
public class Customer implements java.io.Serializable {
    private int id;
    private Address address;
    private String lastName;
    private String firstName;

    public Kunde(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 = "LAST_NAME")
    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;
    ...
}

The Home Interface of an EJB component contains all methods for lifecycle management of an EJB. Because clients are not able to bypass the EJB container and create or destroy EJBs directly, they have to call the Home Interface of an EJB, which provides such methods. With Home Interfaces the client is decoupled from the EJB component. It implements the design pattern Factory Method.

There are two kinds of Home Interfaces:

• Remote Home Interface for access across machine and process boundaries
• Local Home Interface in-process access

With EJB 3.0 it is possible - in analogy to CORBA base 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 (IoC) is a general characteristic of frameworks. It is often paraphrased with the sentence ""don't call us, we call you"" which means that it is the responsibility of the framework to execute a program, rather than that of the components based on the framework.

This means that the framework obliges the components to implement certain callback methods, that the framework respectively the container uses to inject information or cause certain behaviors (through method calls) at runtime.

In the context of EJB 3.0 IoC and Dependency Injection are often used synonymous, although there are differences when you look at the details (see Dependency Injection). EJB 3.0 employs a specialized form of IoC which is called Dependency Injection.

The local kind of 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.

<insert Grafik Local Home Interface>

Multi-table Mapping denotes the ability of EJB 3.0 Entity Beans to be mapped to more than one physical (normalized) database tables. EJB 2.x doesn't have this ability, except you explicitly program it. With EJB 3.0 an Entity Bean 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 Entity Bean annotations simply specify which tables/fields are the source for the relevant data. The Entity Manager is responsible for resolving the relational model at runtime and putting the data into the Entity Bean (see illustration).

@Entity
@Table(name = "CUSTOMER")
@SecondaryTables({
@SecondaryTable(name = "ADDRESS")
@SecondaryTable(name = "TYPE") })
public class Customer implements java.io.Serializable {
   private int id;
   private String lastName; // from table "CUSTOMER"
   private String firstName ; // from table "CUSTOMER"
   private String street; // from secondary table "ADDRESS"
   ...

   // Attribute from main table "CUSTOMER"
   @Column(lastName = "LAST_NAME")  
   public String getLastName() {
     return lastName;
   }
   ...

   // Attribute from secondary table "ADDRESS"
   @Column(name = "STREET", secondaryTable = "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 ;
   }
}

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 was introduced in the context of EJB 3.0 as well. The core idea of EJB 3.0 is that EJB components in the view of developers become less complex in terms of using them and their micro architecture... <Wie geht es auf Deutsch weiter?>

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 in the view of developers 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.

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.

<insert Grafik Remote Home Interface>

The technical variant of the business interface (Component Interface) of an EJB component, which allows remote communication is called Remote Interface.

When 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.

  
EJB 3.0-Kolumne im Javamagazin!

Im Javamagazin gibt es seit Ausgabe 2/2005 die EJB 3.0-Kolumne von Oliver Ihns, in der er jeden Monat - bis zur finalen Version in 2006 - einen dedizierten Aspekt von EJB 3.0 beleuchtet. [mehr]

Das aktuelle Buch zu EJB 2.1.

Erschienen im Oldenbourg Wissenschafts-verlag. Vielfach eingesetzt in Praxis und Studium.

[mehr]

Siehe [Poster]