There are many time-related issues into a cloud application.
It is the task of the scheduler to send messages to relevant systems when an event occurs. The scheduler mustn’t know anything about the events themselves.
Basically it must support (at least) these features:
- Add event – adds an event with relevant parameters such as:
- Event name (id)
- Is it one time / recurring event. When should the event be triggered. Any parameters that should be passed to the subscribers when the event occurs.
- Subscribe / unsubscribe to an event – Allows interested entities to subscribe (listen) to an event, or stop listening
- Publish Event – When an event occurs go over subscriber list and inform them of the event.
A scheduler system is a very well known model. However, since it will run in the web with a potential of hundred thousands of subscribers, it must be fully adaptable to the cloud environment and be able to run from multiple instances even though it will have one “logical” event storage.
When designing the component great care must be taken so that the event dispatcher won’t hinder the monitoring component or the other interfaces into the scheduler. As an example – if an event has 10K subscribers, it should be published from one or more different instances so as not to “hog” the CPU of a single server (or the bandwidth of it).
Tracking Item Sources
Following is a description of some sources for event-tracking. “Sources” mean that these components add events to the scheduler to be tracked and published when the time comes.
The billing system is responsible for the following event types:
- Subscription Renewal Notification – X days before a renewal should take place it published the renewal notification.
- Subscription Renewal Event – When an item’s subscription is to be renewed.
- Item Expiration event – when an item (e.g. a license) is bought, an “unused expiration” event is registered. If a specific period of time passes without the event being deleted (such as if the item is activated on time), then a message will be issued stating that the item expired (the license expiration event is created via the LMS).
The Licenses System is mainly responsible for notifying the scheduler that a license was activated and that it should be tracked for expiration. When a license is activated its “unused expiration event” is deleted and replaced by the “expiration event”.
The scheduler may have other sources of events as it is the system that provides all monitoring needed by any of the components in the cloud system.
A deeper level explanation of the scheduler
The scheduler is basically an external timer service. It doesn’t “understand” the nature of the events it is asked to time keep, nor does it “know” those entrusting him with the tasks.
Basically it only “knows” two things:
- Add event to be triggered at a specific time.
- Inform the subscribers of the event triggered.
Of course it supports other interfaces, such as add new subscriber, remove existing subscriber, publish, etc. but we will address this later on.
The heart of the scheduler
Since the basic function of a scheduler is to keep track of time, a description of the mechanism of time tracking and event publishing will be described as follows.
The scheduler contains a queue of events waiting to be triggered. Each such event has its time of awakening, any data associated with it at time of event registration and the destination of the event.
The information associated with an event is shown below:
- Event name – a name for this type of event.
- Event ID – a unique ID for this event.
The ID could be any string. E.g. for license notifications it will be the unique license ID. This will be recognizes by the various system subscribed to listen to the event.
- Time event should be triggered (published).
- Data received from the event’s source. This data is stored and returned to the subscriber at the time the event triggered. It can contain information that will help the subscriber to identify the specific event that triggered. Example – for a “License Expiration” event, the billing system will provide the scheduler with the GUAI of the account as well as the unique license ID being monitored.
How requests to monitor events are handled
When an event is received for monitoring the following flow takes place:
How do systems subscribe to the notifications generated by the scheduler
Each system subscribes to the scheduler by specifying a list of events to which it wants to listen. Each system has a unique identifier used when creating a message queue onto which event notifications will be placed.
As an example – announcement system will subscribe to “Payment due Notice”, “License Expiration Warning”, “LMS Expiration Warning”, etc. Events of this name will be placed into the queue used by the announcement system.
How events are triggered
When the timer “wakes up” it means that an event should be published in the appropriate message queues. The “Wake” procedure is as follows:
It is possible for an event to be canceled. This is initiated by the subsystem that requested the event monitor in the first place.
An example would be canceling the event that waits 1 year for an unused to become expired. If the license is used before the 1 year is over, then the billing system will notify the Scheduler to cancel the “Unused License” event and instead to register for “wait for license expiration” event (if the license does expire after 1 year).
The behavior of the delete request is as follows:
It is possible for a subscriber to stop listening for events. It is done by simply finding the subscriber’s ID in the “map event names to queue IDs” and removing the queue ID from the event’s map.