Java Reference
In-Depth Information
One further word. This is by no means an established doctrine, but it
seems to be common practice to keep entity beans hidden behind session beans.
In other words, it seems to be commonplace to not allow clients (Web applica-
tions, Java applications) to communicate directly with entity beans, but rather
to have session beans perform all entity bean operations. This is probably be-
cause the idea of session beans is to decouple business process from implemen-
tation details, and entity beans, no matter how much they hide the underlying
database, are still rather tightly coupled to the implementation of the data
storage.
Why you would use them.
Essentially, they allow you to write your data
access layer exactly once, and then reuse it any number times without worrying
about capacity and management. Also, by trying to keep the most often used
data in fast memory, they can, when running on a powerful container or cluster
of containers, keep many client operations running much faster than a strict
write-read update back end.
21.2.2.3
Message Beans
What they are.
We're going to gloss over message beans in our book, but
you should know what they are. A message bean represents an interface to a
message queue. An entity bean represents a transaction where completion of
the call tells you the operation has fully completed. A message queue, on the
other hand, is an interface where you are given the firm promise that system
will get to this when it can. The client doesn't know where or when the message
will be handled. It doesn't know if it was successful or not. But it does know
that it is the problem of the queue reader.
There are many such operations in large enterprises. And there are many
products that implement such functionality. Microsoft offers Message Queue
Server (MSMQ). IBM has MQSeries. Message queues are common with oper-
ations that take time, or need to be batched, or require human intervention.
Why you would use them.
Let's go back to our shopping cart idea. Man-
agement might want a daily sales report. You could send each and every item
purchased to a message bean. Then a process to read that queue might be
kicked off once a day and the report produced without hitting the database that
supports all the current Web users. That's a good example of how a message
queue (and thus a message bean) might be used. Again, we're not going to work
with message beans here.
