activemq-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "James Strachan" <>
Subject Re: new user and usercase scenario
Date Tue, 04 Jul 2006 10:46:10 GMT
On 7/4/06, Stuart Barlow <> wrote:
> Hello, I am a new-ish user with a scenario that I feel JMS may fit but
> Im not sure in which way JMS should be used.
> I already have events sitting in a JMS topic. One of the durable subscribers
> is a notification subscriber that takes each event and sends a notification
> (either email or SMS or IM message) to each relevant user on the system.
> e.g. Two create document events in a system with 10 users leads to 20
> notifications getting sent.
> We now have a new requirement to queue up the notifications and send at
> the end of the day as a message digest to each user (but only if that user
> has opted to receive notifications as a digest).
> Can I continue to use JMS to help here?
> Should I create a new notification queue and place messages for all users in
> the queue. So that at the end of the day I will have a notification queue full
> of lots of individual notifications and I can use a QueueBrowser to select a set
> for each user?
> Or is another JMS architecture more suitable?
> Apologies for the rather broad thoughts?

So JMS is an ideal technology for doing things like reliable high
performance communication, load balancing and so forth. So sending
some message to a pool of 'emailer' processes who deal with possibly
blocking things like JavaMail or IM and the like is a good pattern.

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

e.g. it might be possible to use the Aggregator EIP pattern to kinda
implement the digest functionality generically

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.


View raw message