new user and usercase scenario

[Stuart Barlow <sb...@peopledoc.com>]

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?
Stuart

Re: new user and usercase scenario

[James Strachan <ja...@gmail.com>]

On 7/4/06, Stuart Barlow <sb...@peopledoc.com> wrote:
> :-) 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.

Yeah - you might want to implement the digest mechanism differently;
e.g. storing the individual messages some place until the digest is
made so that the latest/greatest template is used etc.
-- 

James
-------
http://radio.weblogs.com/0112098/

Re: new user and usercase scenario

[Stuart Barlow <sb...@peopledoc.com>]

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

Re: new user and usercase scenario

[James Strachan <ja...@gmail.com>]

On 7/4/06, Stuart Barlow <sb...@peopledoc.com> 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
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.
-- 

James
-------
http://radio.weblogs.com/0112098/