Michael Nygard tilts a little too much toward the enterprisey in his recent post on outbound email.
Some of his complaints seem to be about the JavaMail API specifically. e.g. "one connection per message" is not a limitation of SMTP. I suppose his concern is that the JavaMail API has a lot of setup and teardown cost for each message.
But regarding his concern about holding up request-handling threads and recovering mail messages when connecting to the mail transfer agent fails... he goes on to recommend using a message bus/queue like JMS or an ESB, for goodness sake, in *addition* to the SMTP server. An intermediary for the intermediary??
Rather than doing running some other kind of server, why not make sure you're running a fairly stable SMTP server? He writes...
...keep in mind that SMTP servers aren't always 100% reliable...
But I thought the point of his book is that *no* system is always 100% reliable. (btw is there such a thing as "sometimes 100% reliable"? :^)
And so even with a bus/queue or an ESB in between your system and the SMTP server there are still opportunities to fail. In fact, there seem to be *more* opportunities to fail.
Another quote from Michael...
Yes, you can log an exception when your connection to the MTA fails. But that only lets the administrator know that some amount of mail failed. It doesn't say what the mail was!
But if you can log the exception, certainly you can log the message that would have been sent, and then either automatically or "manually" resend it.
How would you handle this situation?
This seems like a general problem, and not specific to SMTP. For example, let's say instead of SMTP you'd like to publish a message to a collection on an Atompub HTTP service. Would you recommend a bus/queue or an ESB as a stepping stone between your system and the HTTP server?
How is this similar or dissimilar to the SMPT scenario?