:-) Some interesting thoughts and thanks for the input. I like the idea of queue B being messages to be sent - so that B consumers dont have to understand which users to send to or how to compose digests vs individual emails. And queue A consumers are the ones that work out who are the recipients of each event and what they want to receive.
Separation of concerns. I'm not sure about building the digest prior to sending as the template could be updated during the day and then half the digest would be using one template and half the updated template. Yes servicemix looks interesting. I have thought it was something we should probably be using to talk the different protocols. James Strachan wrote:
The complication here is the deciding when to send an email to users and what the contents are & dealing with digests. It might be simpler to use queues in the following way... To send an email to a set of users, send to queue A the message with the contents being the mail to send (you could use headers to indicate a list of users to send to or some metadata for choosing users - such as a mailing list name or something etc). Consumers on A then calculate all the individual user email addresses to send an email to. Once they know each user, if they are not in digest mode, they send a 'sendEmail' message to queue B (possibly using a template engine to personalise the content). If they are in digest mode they update the user's current digest email in some database/file system, appending the contents to the digest. Consumers on B then receive a message with the email content and email address/IM details - they just send it then process the next email/IM. These consumers don't need to understand digests or mailing lists; they just send to who they are told with the content they are given. You then have a scheduler task every night to query all digest users and sends a message to B with the digest message then resetting the database so the next digest message is currently empty. The power of JMS in this case is that you can monitor the queue sizes of A and B to see how the system is performing and you can load balance as many consumers on A and B to suit your needs. You may find you need just a few consumers on A but many consumers on B to deal with the email/IM gateways etc. Note that you could end up with many A and B queues for different groups of your business (e.g. you could have A.Cheese and A.Beer to represent different logical roles of user and so forth if need be). You could also get clever if you need to with priority based stuff; having certain servers who only process 'gold customers' so that their emails go out faster than bronze customers etc. BTW to simplify the cross-protocol messaging (such as JMS <-> email <-> Jabber <-> IM <-> Atom/RSS and so forth you could consider using an ESB which has transports and adapters for doing this kind of thing... http://incubator.apache.org/servicemix/ e.g. it might be possible to use the Aggregator EIP pattern to kinda implement the digest functionality generically http://incubator.apache.org/servicemix/servicemix-eip.html rather than having to hand code it just for your requirements since ServiceMix already has support for aggregation of messages along with scheduling of tasks.
-- Stuart
