Mailing-List: contact activemq-users-help@geronimo.apache.org; run by ezmlm
Precedence: bulk
Reply-To: activemq-users@geronimo.apache.org
Received-SPF: pass (asf.osuosl.org: local policy)
Message-ID: <44AA6287.5060004@peopledoc.com>
Date: Tue, 04 Jul 2006 13:43:51 +0100
From: Stuart Barlow <sbarlow@peopledoc.com>
User-Agent: Thunderbird 1.5.0.4 (Windows/20060516)
MIME-Version: 1.0
To: activemq-users@geronimo.apache.org
Subject: Re: new user and usercase scenario
References: <44AA3E97.2080005@peopledoc.com>
 <ec6e67fd0607040346x67959090j668566f362cbde5c@mail.gmail.com>
In-Reply-To: <ec6e67fd0607040346x67959090j668566f362cbde5c@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

:-) 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