Entity beans with container-managed persistence and bean-managed persistence have each of them their advantages and disadvantages. The big advantage of container-managed persistence is certainly its portability, since the important aspects of persistence are treated declaratively in a developer-independent manner. It is in this direction in particular that version 2.0 offers significant extensions of version 1.1. Additionally, persistent relationships, managed by the EJB container and a great help in the mapping of complex data structures, give container-managed persistence further advantages. Version 2.1 further enhances the standardized EJB-QL available functions. Finally, the programming effort is considerably less. Entity beans with container-managed persistence thus tend to be less subject to errors.
Bean-managed persistence offers greater flexibility. The bean developer has a free hand in data storage. He or she decides how and where data are to be stored and is not limited by the specification. With the use of bean-managed persistence, the potential for the developer in tuning database queries is a lot higher then when using container-managed persistence. That is because in the case of bean-managed persistence the bean developer writes all the data access code himself. When container-managed persistence is used, the data access code is generated by the EJB container tools and is hidden from the bean developer. Genericness has its price. If the entity bean has to deal with data types that the EJB container or persistence manager does not support or supports only minimally, then there is no avoiding bean-managed persistence.
Chapter 6: Message-Driven Beans
Message-driven beans were introduced with version 2.0 of the Enterprise JavaBeans specification and slightly enhanced with version 2.1 (Figure 6-1). With this component type, the Java Message Service (JMS) has become inseparably linked with Enterprise JavaBeans.
Figure 6-1: Overview of message-driven beans.
The significant difference between this and other bean types is that a client cannot directly access a message-driven bean. It can address it only indirectly, by sending a message over a particular channel of the message service. A message-driven bean of a particular type receives messages from a particular channel of the message service. It is also significant that the bean does not know which client or user has sent the message. The exchange of messages over a message service transpires anonymously. The application must itself take care of whatever identification may be required. To this end it could send an identifier with the message that enables the sender to be identified.
The component model of Enterprise JavaBeans is given two new aspects through message-driven beans:
For example, if a client calls a method on the remote interface of an entity bean, then client execution will be blocked until the processing of the entity bean method on the server is complete. Thus we are dealing with a synchronous call. Sending a message via a message service is asynchronous. This means that the client can continue processing as soon as it has sent the message. The processing of the client will not be blocked until the message has been delivered or processed by the receiver. Message-driven beans thus work asynchronously, which distinguishes them in an important way from session and entity beans. Asynchronous processing can greatly reduce server response time. The client does not have to wait for the conclusion of processing-intensive actions, which can run in the background. On the other hand, the client does not automatically know when the processing of the asynchronous process has been completed or whether it was able to be completed successfully at all. The JMS specification takes a number of precautions to make the delivery of a message as secure as possible (with respect to data loss). However, there is no mechanism that provides for informing the client of the successful processing of a message, though such mechanisms can be implemented by means of JMS itself.
To process asynchronous events or to speed up processes in a program, one seeks, as a rule, to parallelize particular processing steps by means of threads. The specification forbids a bean from expressly beginning a new thread or from regulating threads (see also Chapter 3, the section "What an Enterprise Bean May Not Do"). One could attempt to parallelize processes on the client, in order to carry out several calls to Enterprise Beans simultaneously. Except for the case of stateless session beans, this is possible only with certain restrictions. Stateful session beans do not allow a client, for example, to execute several calls to an Enterprise Bean identity simultaneously. With an entity bean identity, simultaneously arriving calls (in different transactions) are serialized by the EJB container, that is, processed sequentially rather than in parallel (depending on the implementation of the EJB container). Such parallelism on the client side would increase the complexity of the client enormously. A reason for the introduction of Enterprise JavaBeans is not least in shifting complexity to the application server and simplifying and slimming down the client program. The application server is the place where one would like to use parallel processing for speeding up the application logic. With the help of the message service, message-driven beans make parallel processing possible.
For the proper implementation of message-driven beans a fundamental understanding of the Java Message Service is essential. The next section will therefore introduce the fundamentals of the Java Message Service. We shall restrict our attention to those aspects that are significant for an understanding of message-driven beans. A complete description of JMS can be found in . It should be noted that as of the 2.1 specification, it is possible to use a non-JMS message service with message-driven beans via a resource adapter. This greatly expands and enhances the integration capabilities of message-driven beans. For the remainder of this chapter we will focus on the use of message-driven beans with the commonly used JMS standard.