Login | Register   
LinkedIn
Google+
Twitter
RSS Feed
Download our iPhone app
TODAY'S HEADLINES  |   ARTICLE ARCHIVE  |   FORUMS  |   TIP BANK
Browse DevX
Sign up for e-mail newsletters from DevX


advertisement
 

An Introduction to Java Object Persistence with EJB : Page 2

The 'impedance mismatch' between relational databases' tabular orientation and object-oriented Java's hierarchical one is a perennial problem for which the Java world has several good solution offerings. This article, the first in a three-part series, will look specifically at the EJB specification and its unique way of solving the object-relational mapping problem.


advertisement
EJB Runtime Environment
An Enterprise JavaBean is a Java object exposing a number of interfaces and which lives and executes inside of a runtime environment known as an EJB container. An Enterprise JavaBean cannot live outside of an EJB container. In fact, the relationship between an EJB container and an EJB is sometimes called 'inversion of control'—or the "Hollywood Principle" (don't call us; we'll call you). An EJB container is a runtime environment for managing enterprise beans. The container hosts and manages an enterprise bean in much the same manner that a Java servlet engine hosts a Java servlet. The EJB container instantiates and controls the enterprise beans and provides them with system-level services.

A client application wishing to interact with an enterprise bean does not have direct access to an enterprise bean. Rather, the bean is isolated from the client application by the container. Services Provided by an EJB Container
A developer creating the classes and interfaces from which an enterprise bean object will be created can assume the following system-level services will be available from the EJB container:

  • Transaction management for the bean
  • Security for the bean
  • Persistence of the bean
  • Remote access to the bean
  • Lifecycle management of the bean
  • Database-connection pooling
  • Instance pooling for the bean
Because the EJB container handles the bulk of infrastructure-level services for an enterprise bean, a programmer can concentrate on programming the business logic for the enterprise bean.

Types of Enterprise Beans
The EJB architecture defines three distinct types of enterprise beans:

  • Message-driven beans
  • Session beans
  • Entity beans
Session beans and entity beans are invoked synchronously by an enterprise bean client. Message-driven beans (MDBs) are invoked by a message container, such as a publish/subscribe topic. Message Driven Beans
A message-driven bean (MDB) is an enterprise bean that handles incoming messages asynchronously. An instance of an MDB typically acts as a message listener for messages passed from a JMS publish/subscribe topic. An MDB can receive any JMS-compatible message.


An EJB container manages the lifecycle of an MDB, however, unlike session and entity beans; client programs do not target the MDB with method calls. Instead, the MDB receives messages from a message source through a callback method, onMessage. Session Beans
A session bean represents a single client and is not shared across clients. A client invokes the session bean's methods, which are directed through the EJB container to the enterprise bean. The session bean performs the business logic for the client and the container returns control to the client. A session bean is not persisted across multiple sessions. There are two types of session beans: stateful and stateless.

Stateful Session Beans
A stateful session bean maintains a conversational state with one client for the duration of a single session. This implies that the stateful session bean can maintain instance variables across multiple invocations from one client during a single session. Once the client finishes interacting with the enterprise bean and the EJB container removes the enterprise bean, the session for the bean ends and all state data for the bean are discarded.

Stateless Session Beans
A stateless session bean does not maintain a conversational state for each individual client. Each invocation of a stateless session bean should be considered as a request to a brand new object instance, as any instance-variable state will be lost between invocations. Stateless session beans are not persisted to secondary storage by the EJB container; therefore a programmer must recognize that all data is transient between invocations for each client. The transient nature of stateless session beans allows an EJB container to reuse bean instances and therefore, usually optimize the performance of the beans.



Comment and Contribute

 

 

 

 

 


(Maximum characters: 1200). You have 1200 characters left.

 

 

Sitemap