Enterprise JavaBeans

from Wikipedia, the free encyclopedia

Enterprise JavaBeans ( EJB ) are standardized components within a Java EE server (Java Enterprise Edition). They simplify the development of complex, multilayered distributed software systems using Java . With Enterprise JavaBeans, important concepts for corporate applications, e.g. B. transaction, name or security services are implemented that are necessary for the business logic of an application.

Components

Enterprise JavaBeans are available in several different versions for different classes of use cases. They can either be addressed remotely ("remotely", ie across process and computer boundaries) or locally (within a VM ).

Entity Bean

Entity beans model the permanent (persistent) data of the system . Examples are physically available things such as users, information structures such as addresses or archived process information such as invoices. They represent e.g. B. a data record from a database.

The persistence can either be programmed by the bean developer himself ("Bean Managed Persistence", BMP ) or provided by an EJB container ("Container Managed Persistence", CMP ). With CMP , the name of an abstract schema is defined in the deployment descriptor (see below), which usually corresponds to the name of a database table in which the EJBs of a class are stored.

From version 5 to support Java EE an attachment , detachment and reattachment . The Entity Bean is now a POJO , the persistence of which can be controlled using the EntityManager . The well-known Java EE design patterns " Data Transfer Object " (English. DataTransfer object , short DTO ) is therefore technically no longer needed because now business objects through different layers , for example, a client could be transported. Data transfer objects previously served the abstraction of business objects (i.e. the representation of pure data without behavior) and the decoupling of different application layers .

Session bean

Session beans especially map processes that the user carries out with the system. You often use several entity beans to illustrate the effects of the process.

A distinction is stateless ( stateless ), and stateful ( stateful ) session beans.

A stateful session bean has its own memory. It can save information from a method call so that it is available again when another (or the same) method is called later. The statefulness is implemented by assigning a unique ID; the stateful session beans can be differentiated via this ID.

In contrast to this, a stateless session bean must be given all information as parameters for each call that is required to process this call. Since a stateless session bean cannot store any information, it cannot be distinguished from other session beans of the same class, i.e. it has no identity of its own.

Message Driven Bean

Message-driven beans are the components that make EJB systems accessible for asynchronous communication. The Java Message Service (JMS) is used for this. This type of bean is used e.g. B. often used for communication with legacy systems . Message-driven beans are also ideal for executing operations that are traditionally to be carried out asynchronously (e.g. sending a mail), on the success and duration of which the performance of a higher-level application should not depend.

Web services

From version 1.4, the J2EE specification allows stateless session beans to be called as web services and describes a mechanism that maps the interface of a web service to the interface of an EJB.

example

You can clearly explain the different components in an online shop. A stateless session bean could contain the data of a search result for a certain article. Such a search list does not have to be saved persistently, but can be discarded after a one-time inspection. A stateful session bean is the shopping cart into which the articles are placed. This should be saved at least for the period in which the customer is browsing the site and possibly adding further articles. Ultimately, an entity bean saves the customer data with which the customer registered with the shop. These, in turn, have to be saved persistently, otherwise you would have to register every time you visit the site.

Configuration (deployment descriptor)

In addition to the Enterprise Java Beans, the EJB standard also defines a so-called deployment descriptor (freely translated as “deployment description”). This deployment descriptor is an XML file in which the actual EJB definition always took place prior to version 3 of the standard, since the connection between the various Java classes and interfaces that make up an EJB had to be established here.

As of version 3, most of the information for which the deployment descriptor was previously necessary can be implemented directly in the Java code with annotations . This means that the deployment descriptor can be omitted entirely. But it can also be used to overwrite the information in the annotation.

In addition to these standardized properties, EJB containers define additional, container-specific properties.

Transactions

An essential function of EJB containers is the management of transactions . Each method of an EJB has a so-called transaction attribute, which defines which type of transaction the EJB requires and supports.

NotSupported
The method does not support transactions. The EJB container does not give a transaction context to the method and interrupts the transaction until the method call has ended. If the method calls other EJBs, these also run without a transaction.
Required (default)
The method can only be called within a transaction. If the caller is not part of a transaction, the EJB container starts a new transaction, which is ended again after the method is exited. According to the convention over configuration principle, this is the standard behavior, provided the developer does not specify a transaction attribute.
Supports
The method can be called both inside and outside a transaction. In the first case the behavior corresponds to NotSupported , in the second to Required .
RequiresNew
The method requires its own transaction. When the method is called, the EJB container always starts a new transaction, which ends when the call is returned. If the caller is already part of a transaction, this is temporarily suspended.
Mandatory
The caller must be part of a transaction. Otherwise, the EJB container reports an error by an exception ( Exception ) type javax.transaction.TransactionRequiredException throws.
Never
The method must never be called within a transaction. If it does, the EJB container throws an exception.

Version 3.0

The complexity and the lack of object orientation of the EJB technology were always points of criticism. For this reason, a new specification has been developed which is intended to bring about a significant simplification. New features in EJB 3.0 (from Java EE 5) include:

  • Entity beans have become obsolete; instead, persistent entities should be used
  • Introduction of annotations , whereby almost all information in the deployment descriptor is replaced and this can often be omitted.
  • Simplification of the EJB API
    • Home interfaces are no longer required.
    • Interfaces such as SessionBeanor MessageDrivenBeanno longer need to be implemented.
    • All bean classes are exclusively POJOs . That is, the code does not have to be "polluted" by EJB implementation details; the required information is declared as annotations.
    • Only required callback functions ( callback functions are) must be implemented.

Version 3.1

EJB 3.1 (from Java EE 6) also brings the following innovations:

  • There are singletons of which only one instance exists (in an application in a server). Separate support for concurrency is implemented for the singletons (Bean Managed Concurrency or Container Managed Concurrency)
  • Asynchronous calls to business methods are possible.
  • No interfaces are required any more ( no interface view ). Such EJBs can then only be used locally, but in a greatly simplified manner directly from the JSF pages.
  • EJBs have well-defined JNDI domain name in different namespaces: java:global, java:appand java:module.
  • EJBs no longer have to be distributed in a separate ejb-jarfile, but can be .warpackaged directly into the archive.

See also

literature

  • O. Ihns, S. Heldt, R. Wirdemann, H. Zuzmann: Enterprise JavaBeans complete , Oldenbourg, 2003, ISBN 3-486-27379-5
  • Oliver Ihns, Dierk Harbeck, Stefan M. Heldt, Holger Koschek, Jo Ehm, Carsten Sahling, Roman Schlömmer: EJB 3 professional . dpunkt, Heidelberg 2007, ISBN 978-3-89864-431-0
  • Olaf Zwintzscher: An overview of software components . W3L, 2004, ISBN 3-937137-60-2
  • Debu Panda, Reza Rahman, Derek Lane: EJB 3 in action . Manning Publications, 2007, ISBN 1-933988-34-7

Web links

Individual evidence

  1. ↑ After: Tanenbaum, van Steen: Distributed Systems: Principles and Paradigms. 2006