• Name: Alert
• Alternate Name: Notify
  

This Service Genre has been developed from a wide range of projects and work across the partners. Systems are often required to provide alerts or notifcations to users for a variety of reasons. This Service Genre has been developed to show the functionality and behaviours required of Services that seek to fulfill this requirement.

• v1.22

This Service Genre details the notion of notifying a user or system as to the occurrence of an event. The event itself could be extra-ordinary (such as a fire alarm), or it could be something more mundane (such as informing students of a cancelled lecture). The important notion in alerting is that the alert data itself is actively propagated to receivers rather than passively propagated. Alerts MUST be pushed.

The model for Alert assumes that requesters (which may be users or machines) issue an alert message to an Alert Service. The Alert Service then propagates the Alert Message to a range of different receivers. Those receivers could be other Services or users. At the Genre level, there are no limits on the transport mechanisms that Alert Services can use to send the Alert Message. Receivers are assumed to be pre-registered with the Alert Service (for humans, this might be via an email address or telephone number that the Alert Service has access to).

Alert Messages MAY be sent to only a subset of all registered Receivers, as decided by the originator of the Alert Message (the requester). Alert Messages MAY be withdrawn. Alert Messages SHOULD NOT be sent to unregistered Receivers. As defined this Service Genre does not specify how Receivers are managed. Individual Service Expressions MAY specify how Receivers are to be managed by a particular service end point.

Figure 1 shows the relationships between Originators, Alert Services, and Receivers.

 
Figure 1: Relationships between parties in Alerting

Providers expose an “Alert” interface, defined in the Service Expressions that specialise this service genre. Clients may send requests to this interface to create alerts to be consumed by Receivers.

As defined, the Alert service genre is not access controlled; i.e. any client may attempt to contact an alert service end point. There are no authentication controls. The service end point is responsible for determining which Receivers are alerted and from which clients it will accept requests.

At least one request SHOULD specify the Create Alert functionality.

At least one request MAY specify the Cancel Alert functionality.

Create Alert SHALL meet the following conditions:

• The Request SHOULD specify the Alert Message:
  • The Alert Message SHOULD contain a timestamp.
  • The Alert Message SHOULD contain a description of the alert itself.
  • The Alert Message SHOULD contain a source from where the Alert Message originated.
  • The Alert Message MAY contain a severity.
  • The Alert Message MAY contain a duration.
• The Request MAY specify the intended Receivers of the Alert Message.
• Responses SHALL include error messages or other needed control information.

Cancel Alert SHALL meet the following conditions:

• The Request SHOULD specify the Alert Message which is being cancelled.
• Responses SHALL include error messages or other needed control information.

Alert SHOULD NOT be used when the originator wishes to make the Alert Message available in a Passive manner.

Alert SHOULD be used for issues of criticality (including health and safety).

A system MAY wish to include an Alert Service if the processes of the system are elapsed over a long duration (in human terms) For example, a researcher may start a highly intensive computational task on the Grid lasting for several months. An alert would be useful to inform the researcher upon completion or failure.

At least one request SHOULD specify the Create Alert functionality.

At least one request MAY specify the Cancel Alert functionality.

Create Alert SHALL meet the following conditions:

• The Request SHOULD specify the Alert Message:
  • The Alert Message SHOULD contain a timestamp.
  • The Alert Message SHOULD contain a description of the alert itself.
  • The Alert Message SHOULD contain a source from where the Alert Message originated.
  • The Alert Message MAY contain a severity.
  • The Alert Message MAY contain a duration.
• The Request MAY specify the intended Receivers of the Alert Message.
• Responses SHALL include error messages or other needed control information.

Cancel Alert SHALL meet the following conditions:

• The Request SHOULD specify the Alert Message which is being cancelled.
• Responses SHALL include error messages or other needed control information.

The Create Alert Request MUST occur for a specific Alert Message before the Cancel Alert Request is made to cancel that same Alert Message. If the Cancel Alert Request is made to cancel a non existent Alert Message, an error SHOULD be raised.

Individual Service Expressions SHOULD provide models showing how clients interact with service interfaces.

None

Individual Alert expressions SHALL specify the transport mechanisms and precise message formats that are used for communicating Alert Messages to Receivers.

Individual Alert expressions MAY check that an alert has been correctly received.

Individual Alert expressions MAY include functionality which covers the registration of Receivers.

• UK HE Admissions Structured Personal Statement v1.2