Re: Looking for Design Input
- From: "Chris Uppal" <chris.uppal@xxxxxxxxxxxxxxxxxxxxxxxxxxx>
- Date: Wed, 7 Mar 2007 13:55:10 -0000
Malbs wrote:
I have a probelm I'm trying to solve. I was trying to thing of the same
problem in a different domain to discover if maybe there is some sort of
pattern I can apply... I was struggling to come up with the same design
problem in a different domain when it hit me. The common mailing list.
One downside of transferring your problem statement into a different domain is
that it makes it impossible for us to guess what aspects of the problem
statement are artefacts of the new domain, and which are parts of your actual
problem domain.
For instance the design problems around mailing list aggregation are different
from those around (say) publish-and-subscribe filtering.
So some of this will probably be irrelevant...
It seems to me that there are several different categories of "customisation"
that a subscriber might want to apply, and that the immediately obvious
architecture to support that differs from category to category.
Some examples.
Delivery transport options -- such as how what email address(es) to sent to,
many times to retry failed deliveries before giving up, what fall-back email
addresses to use (if any), how long an interval to leave between retries,
whether the customer is paying for accelerated delivery... All of these (it
seems to me) would be naturally handled by having different instances of
DeliveryOptions attached to each Subscriber (or perhaps for even one per
Subscription -- though that might be overkill). When an outgoing Message was
sent to the DeliveryQueue, the system would attach a (copy of the)
DeliveryOptions to the Message, so that the DeliveryQueue knew what options to
implement. You might want more than one DeliveryQueue in the system, but if so
then I'd make that invisible to the main server process(es), and use a single
DeliveryQueue as a front-end which would dispatch outgoing Messages to whatever
other DeliveryQueues you happened to need.
Delivery transport mechanism -- what transport to use. E.g. email, SMS, or
VIOP notification. I'd punt on this one unless it is actually relevant to your
real problem. It affects everything else, so it has to be fundamental to the
architecture.
Temporal options -- things which affect how often messages are generated. For
instance aggregation/digesting. In this case the fundamental "rhythm" of the
server is different for different options (and the logic differs a bit too).
So it seems natural to me to use a separate Process (possibly even a separate
OS process) which shares a lot of code with the ordinary server, and which uses
the same underlying database of messages, but which uses different logic to
collect a week's worth of messages into one giant message. Presumably the
delivery logic would be identical to the normal case, so they could share the
same DeliveryQueue. Note that the aggregating server could be implemented as
normal customers of the non-aggregating server -- whether that'd be an
advantage depends on factors I can't guess at from here.
Rendering options -- things which affect how the outgoing messages are
formatted. For instance plain-text vs. HTML. In this case I'd probably choose
to have a differently configured Renderer object attached to each Subscription
(with maybe a default attached to each Subscriber, and a further global one to
supply the ultimate defaults), and make the server ask the Renderer to convert
the underlying data into a sendable Message (or maybe just into the text to put
into that Message).
Filtering options -- what messages are of interest to what subscribers. I'd
probably start with a Filter object attached to each Subscription, but if the
O(N*M) ness of applying N filters to M messages became a performance problem
then I'd also build (derive) some kind of more advanced datastructure to make
the mapping from one message to the set of interested Subscriptions faster.
Rebuild that structure from scratch whenever any subscription's filters change.
In case it's not clear, I'm assuming one server per mailing list (unless
aggregating servers are also required). But it makes no real difference that I
can see if one server handles one mailing list, and you have several servers,
or if one server handles several mailing lists. I'm calling a customer a
Subscriber, and each <customer, mailing list> pair a Subscription.
MailingLists and Customers would both have lists of Subscriptions -- at least
logically (whether that would be implemented as actual physical references from
within each MailingList or Subscriber object is a different matter, of course).
Each Subscription would have references to both the MailingList and Subscriber
(probably, but not necessarily, physical). I'm also assuming that you want to
separate the mechanisms for actual delivery from those for assembly of outgoing
messages -- that's often a good idea, but it might not be right/relevant for
your application.
The above are only thoughts, and may not work at all for your real application.
The important point I wanted to make is that the support architecture depends
on the /kind/ of options you want to vary.
So what I'm interested in?
Has anyone else had to implement a similar design summarised with:
Yes.
And how did you do it?
Roughly as above. (Though I had no need for aggregation, so that wasn't part
of the system).
Am I on the right track, wrong track?
Who knows ? ;-)
-- chris
.
- Follow-Ups:
- Re: Looking for Design Input
- From: Malbs
- Re: Looking for Design Input
- References:
- Looking for Design Input
- From: Malbs
- Looking for Design Input
- Prev by Date: Re: Looking for Design Input
- Next by Date: Re: ActiveX question
- Previous by thread: Re: Looking for Design Input
- Next by thread: Re: Looking for Design Input
- Index(es):
Relevant Pages
|
