-
Notifications
You must be signed in to change notification settings - Fork 4
Details of Structure
The system consists of inbound connectors, a notification engine and outbound adaptors.
These connect to the system(s) creating notifications. They either poll known resources or receive messages indicating that a notification needs to be delivered.
Subscriptions to the inbound connections are either polling or event driven. An event driven connection is not rescheduled - it just waits for the message.
The Action class represents something to be done - e.g. a subscription that needs periodic processing, a notification that needs outbound processing etc. There are 2 ActionQueue objects that handle queues of the Actions
- inbound actions - a subscription needs to be polled, there was some inbound message etc
- outbound actions - notifications that have been fetched now need to be sent out to some destination
Runs the threads and schedules the processes and data. It uses a bunch of notelings to handle the activity. There is a pool of these which allows us to limit the activity to a reasonable level - more notelings - more potential activity.
Polled subscriptions are queued up by the system and periodically a noteling will be started to drive the import process.
Incoming notifications all get added to a queue for processing by outbound processes. This queue is all or part of a queue that is maintained in a database.
It is the job of the noteling to drive the inbound connector instance and to store and queue the resulting notification messages.
Notelings are also started to drive the outbound process. Notifications are flagged according to their delivery method (email, sms etc) and one or more outbound instances will be started per delivery method.
A subscription defines what needs to be imported into the system. One is created automatically at startup for the external notifications from bedework (by the BedeworkConnnector class). Additional subscriptiosn would be created for users who want notifications exported.
Non-special subscriptions will be saved in the db and restored at startup.
At startup the inbound and outbound ActionQueue objects are created and started. These are threads that wait for queue entries to appear and create notelings to handle the actions. The system should also retrieve any stored subscriptions and initialise them - either adding them to the inbound queue for initial processing are adding them to the pool awaiting signals.
Subscriptions are event driven or polling. Event driven subscriptions are just saved in a table to wait for an incoming signal that triggers it. Polled subscriptions are queued on the inbound queue periodically to check their sources.
Either way the subscription will check the source for incoming notifications. These will be turned into Action objects which refer to the subscription and notification and have an outboundProcessing type. These action objects are then queued on the outbound queue.
The outbound queue thread takes the Action off the queue and starts a noteling to handle it.
A notification has one or more destinations and these may have one or more types, email, sms etc. A destination factory provides a list of Destination classes to handle the outbound notification.
Each Destination send method should be called to send the notification on to it's final destination.
When all is sent the notification needs to be discarded
The outbound queue could get long and we probably want to add delays - Actions need to be stored so we don't lose them
A small delay may allow us to merge notifications for the same event
Refactor this as a Camel implementation