The EJB specification intends to provide a standard way to implement the back-end 'business' code typically found in enterprise applications (as opposed to 'front-end' user-interface code). Such code was frequently found to reproduce the same types of problems, and it was found that solutions to these problems are often repeatedly re-implemented by programmers. Enterprise Java Beans were intended to handle such common concerns as persistence, transactional integrity, and security in a standard way, leaving programmers free to concentrate on the particular problem at hand.
EJB types
Stateful Session Beans are distributed objects having state: that is, they keep track of which calling program they are dealing with throughout a session. For example, checking out in a web store might be handled by a stateful session bean, which would use its state to keep track of where the customer is in the checkout process. On the other hand, sending an e-mail to customer support might be handled by a stateless bean, since this is a one-off operation and not part of a multi-step process. Stateful session beans' state may be persisted, but access to the bean instance is limited to only one client. Stateless Session Beans are distributed objects that do not have state associated with them thus allowing concurrent access to the bean. The contents of instance variables are not guaranteed to be preserved across method calls. The lack of overhead to maintain a conversation with the calling program makes them less resource-intensive than stateful beans.
Message Driven Beans were introduced in the EJB 2.0 specification. which is supported by Java 2 Platform, Enterprise Edition 1.3 or higher. The message bean represents the integration of JMS (Java Message Service) with EJB to create an entirely new type of bean designed to handle asynchronous JMS messages. Message Driven Beans are distributed objects that behave asynchronously. That is, they handle operations that do not require an immediate response. For example, a user of a website clicking on a "keep me informed of future updates" box may trigger a call to a Message Driven Bean to add the user to a list in the company's database. (This call is asynchronous because the user does not need to wait to be informed of its success or failure.) These beans subscribe to JMS (Java Message Service) message queues or message topics. They were added in the EJB 2.0 specification to allow event-driven processing inside EJB Container. Unlike other types of beans, MDB does not have a client view (Remote/Home interfaces), i.e. clients can not look-up an MDB instance. It just listens for any incoming message on a JMS queue (or topic) and processes them automatically.
Previous versions of EJB also used a type of bean known as an Entity Bean. These were distributed objects having persistent state. Beans in which their container managed the persistent state were said to be using Container-Managed Persistence (CMP), whereas beans that managed their own state were said to be using Bean-Managed Persistence (BMP). Entity Beans were replaced by the Java Persistence API in EJB 3.0, though as of 2007, CMP 2.x style Entity beans are still available for backward compatibility.
Other types of Enterprise Beans have been proposed. For instance, Enterprise Media Beans (JSR 86) address the integration of multimedia objects in Java EE applications.
0 comments:
Post a Comment