Enterprise JavaBeans (English)

Přejít na: navigace, hledání
Tato stránka je dostupná také v češtině: Enterprise JavaBeans


Enterprise JavaBeans is a standard server-side component model for distributed business applications[1]. In other words, EJB defines a model for composing a full system together by integrating modules (beans). EJB is also an aggregate technology which wires up other facets of the Java Enterprise Edition, such as messaging, transactions, resource management, persistence and web services.[1]

Current up-to-date version is Enterprise JavaBeans 3.1 which is specified by JSR 318: Enterprise JavaBeans 3.1[2]. This technology then is a Java Enterprise Edition standard. As an alternative to this technology Spring Framework can be used.

Since version 3.0, EJB supports so called POJO development. It means that an application developer is under no obligation to extend, implement, or have any references tying the application to EJB. Because a POJO class is in no way different from other classes it only becomes an Enterprise JavaBean when it is: assembled/packaged, deployed and accessed via the container[1].

Enterprise JavaBeans 3.1 technology uses two types of beans for constructing the application: Session Beans (Stateless, Stateful and Singleton Beans) and Message-Driven Beans. In versions prior to 3.0 another bean type was used in addition to the two ones mentioned - Entity Beans. These were deprecated when EJB version 3.0 came into effect and since then JPA has been used instead.

Session Beans

A session bean encapsulates business logic that can be invoked programmatically by a client over local, remote, or web service client views. To access an application that is deployed on the server, the client invokes the session bean’s methods. The session bean performs work for its client, shielding it from complexity by executing business tasks inside the server[3].

There are three types of Session Beans available: Stateless Session Beans, Stateful Session Beans and Singleton Session Beans.

Stateless Session Beans are useful for functions in which state does not need to be carried from invocation to invocation[1]. If a client requests an EJB container for some service implemented by Stateless Session Bean container may target any bean from its instance pool and there is no rule for linking an invocation specified. Note, that a stateless session bean can implement a web service, but a stateful session bean cannot[3].

Stateful Session Beans in contrast to Stateless Session Beans maintain a conversational state. This means the container ensures that every invocation during specific conversation will target the same bean instance while the conversation is in effect. Each Stateful Session Bean proxy object has an isolated session context, so calls to one session will not affect another[1]. A typical example of the Stateful Session Bean is a shopping cart. The cart has to maintain its state while customer views an e-shop and holds the information about chosen products.

Singleton Session Bean is a module used to represent singleton in EJB architecture model. Singleton Session Bean is instantiated exactly once per the application lifecycle. It is often used to provide functionality shared among other modules which needs to be controlled in one centralized place. A good example for such a bean can be a number sequence generator.

Message-driven Beans

Asynchronous messaging is a paradigm in which two or more applications communicate via a message describing a business event. EJB 3.1 interacts with messaging systems via the Java Connector Architecture (JCA) 1.6 (http://jcp.org/en/jsr/detail?id=322), which acts as an abstraction layer that enables any system to be adapted as a valid sender. The message-driven bean, in turn, is a listener that consumes messages and may either handle them directly or delegate further processing to other EJB components.[1]

Message-driven beans like stateless session beans do not maintain conversational state.

When to use EJB

  • When the application needs to scale well
  • When concurrent access is needed
  • When there will be more different client types

When to not use EJB

  • When it would be absolutely unnecessary
  • When no services provided by this technology are necessary
  • When it is important to logically separate presentation layer from service layer

Disadvantages of EJB

  • Components are container and its API dependent(there is an effort to create components so they will be technology-independent - AOP or Dependency Injection
  • Very steep learning curve at the begining(even though since version 3.0 it got much better)
  • Container is demanding and has its running costs(price for creating the profound abstraction)


[1] A.L. Rubinger and B. Burke. Enterprise JavaBeans 3.1. Java Series. O’Reilly Media, 2010.

[2] Oracle. Jsr 318: Enterprise javabeanstm 3.1. http://jcp.org/en/jsr/detail?id=318, 2013.

[3] Oracle. The java ee 6 tutorial. http://docs.oracle.com/javaee/6/tutorial/doc/gipjg.html, 2013.