JMS vs. JavaMail for EJB Messaging
In general, the choice between JMS and JavaMail is determined by the recipient's technological infrastructure and the business case. If the recipients can receive e-mail (via SMTP, POP3, IMAP, etc.), then they can receive a message sent via the JavaMail API. If the only protocol available is HTTP, then you will need to use JMS. If both are available, examine the business case to make your determination.
Both JMS and JavaMail can create a loosely coupled, asynchronous messaging system. Both provide guaranteed delivery, and both support messaging models such as point-to-point and publish/subscribe. If the messaging exchange needs to be machine-driven (an application responds to the message) rather than human-driven, JMS provides a much cleaner and more powerful solution than JavaMail. Also, if the application requires messages to be exchanged with a transactional awareness or a complex routing scheme, or if it requires messages to be pulled sequentially off of a queue, JMS is clearly the way to go.
Flexibility and Reliability in Your Enterprise Architecture
Enterprise messaging is a powerful tool that lends tremendous flexibility and reliability to any enterprise architecture. In our world of increasingly disparate components and backend systems, messaging provides a clean abstraction layer that affords the right balance between system coupling and effective system communication. In this 10-Minute Solution, I explored two messaging options available to EJB developers, JMS and JavaMail, as extra-container resources. In the next, I will explore message-driven beans.