Java Reference
In-Depth Information
jection, lifecycle management, and container-managed transactions. You've formulated the
code samples so that you can use them as templates for solving business problems.
4.4. MDB best practices
Like all technologies, MDBs and asynchronous methods have some pitfalls to watch out
for and some best practices that you should keep in mind. This is particularly true in de-
manding environments where messaging is typically deployed.
Choose your messaging models carefully . Before you wade knee deep in code, consider
your choice of messaging model carefully. You might find that PTP will solve your prob-
lem 9 times out of 10. In some cases, though, the pub-sub approach is better, especially
if you find yourself broadcasting the same message to more than one receiver (such as the
system outage notification example). Luckily, most messaging code is domain-independ-
ent, and you should strive to keep it that way. For the most part, switching domains should
be just a matter of configuration.
Don't overuse MDBs. Many tasks are better suited for session bean asynchronous methods
or CDI events. If you simply need to spawn another task to perform an operation, queuing
up a JMS message is probably overkill. An asynchronous method is much simpler. The
container will manage the threads for you, and you'll be able to pass values back without
developing a complex message-passing sequence with error handling. Similarly, use CDI
events if all that you're looking for is looser coupling.
Remember modularization. Because MDBs are so similar to session beans, it's natural to
start putting business logic right into the message listener methods. Business logic should
be decoupled and modularized away from messaging-specific concerns. An excellent prac-
tice (but one that would have made this chapter unnecessarily complicated) is to put busi-
ness logic in session beans and invoke them from the onMessage method.
Make good use of message filters . There are some valid reasons for using a single mes-
saging destination for multiple purposes. Message selectors come in handy in these circum-
stances. For example, if you're using the same queue for both shipping requests and order
cancellation notices, you can have the client set a message property identifying the type of
request. You can then use message selectors on two separate MDBs to isolate and handle
each kind of request.
Search WWH ::




Custom Search