Enterprise JavaBeans

Enterprise JavaBeans ( EJB) components are standardized within a Java EE server ( Java Enterprise Edition). They simplify the development of complex multi-layered distributed software systems with Java. With Enterprise JavaBeans, important concepts for enterprise applications, such as transaction, name or security services are implemented, which are necessary for the business logic of an application.

• 4.1 Version 3.1

Components

Enterprise Java Beans are available in several different forms for different classes of applications. You can either remotely ( "removed", ie on process and computer boundaries ) or are addressed locally (within a VM).

Entity Bean

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

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

From version 5 of Java EE support an attachment, detachment and reattachment. The Entity Bean is now a POJO, the persistence can be controlled with the help of the EntityManager. The well-known Java EE design patterns " data transfer object " (English Data Transfer Object, in short: DTO ) is thus technically no longer necessary because now business objects could be transported over different layers, for example to a client. Data transfer objects was previously used for abstraction of business objects (ie the representation of pure data without behavior), and the decoupling of different application layers.

Session Bean

Particular session beans form from operations performed by the user with the system. They often involve the use of multiple entity beans to represent the impact of the process.

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

A stateful session bean has its own memory. You can store information from a method call, so that they method available again at a later call to another (or the same ). The Zustandsbehaftung is implemented by assigning a unique ID, this ID can the stateful ( stateful ) session beans can be distinguished.

In contrast, a stateless session bean must on every call, all information will be passed as parameters that are required for the execution of this call. Because a stateless session bean can store any information, it is indistinguishable from other session beans of the same class, so she has no identity.

Message Driven Bean

Message Driven Beans are the components that make accessible the EJB systems for asynchronous communication. For this purpose, the Java Message Service (JMS) is used. This variety of bean is often used, for example, for communication with legacy systems. Also for the execution of classically asynchronous operations to be performed (eg, to send a mail ) of their success and duration of the performance of a parent application should not depend on where Message Driven Beans offer.

Web Services

As of version 1.4, the J2EE specification allows the call to stateless session beans as web services, and describes a mechanism that maps the interface of a Web service on the interface of an EJB.

Example

Clearly one can explain the different components of an online store. A stateless session bean might contain data about a search result for a specific item. Such a search list must not persistently stored, but can be discarded after a single viewing. A stateful session bean is the basket into which one puts into the article. This should be stored at least for the period in which the customer is browsing on the side and possibly puts into other products. An entity bean stores ultimately the customer data with which the customer has registered with the shop. This in turn must be stored persistently, otherwise you would have to re-register each time you visit the page.

Configuration ( deployment descriptor )

The EJB standard defines both the Enterprise JavaBeans also called a deployment descriptor ( loosely translated " use - description"). This deployment descriptor is an XML file in which prior to version 3 of the standards always held the actual EJB definition, since the relationship between the various Java classes and interfaces from which an EJB is, had to be made ​​here.

As of version 3, the most information for the deployment descriptor was necessary before, be implemented with annotations directly in the Java code. This allows the deployment descriptor omitted entirely. It can also be used to override the information in the annotation.

In addition to these standard features EJB container define additional container -specific properties.

Transactions

An essential function of the EJB container is managing transactions. Each method of an EJB has a so-called transaction attribute that determines which type of transaction requires the EJB and support.

Version 3.0

The complexity and the lack of object oriented EJB technology were always criticisms. For this reason, a new specification was developed, which should lead to a significant simplification. What's New in EJB 3.0 (from Java EE 5 ) are, among others:

• To Entity Beans have become obsolete, instead Persistent entities are used
• Introduction of annotations, which almost all the information in the deployment descriptor to be replaced and this can often be omitted.
• Simplification of the EJB API There are no home interfaces longer needed.
• Interfaces such as session bean or message- no longer need to be implemented.
• All bean classes are exclusively POJOs. That is, the code must not be " polluted" by the EJB implementation details; the information required to be declared as annotations.
• Only required callback functions (callback functions) must be implemented.

Version 3.1

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

• There are singletons, of which ( in an application in a server) there is only one instance. For the Singletons a native support for concurrency is implemented ( Bean Managed Concurrency or Container Managed Concurrency )
• Asynchronous calls to business methods are possible.
• There are no more interfaces needed ( no- interface view ). Such EJBs can only be used locally then, but it greatly simplifies directly from the JSF pages.
• EJBs have well-defined JNDI names in different namespaces: java: global, java: app, and java: module.
• EJBs do not have to be in a separate ejb -jar file deployed, but can directly into the. Archive was to be mitpaketiert.