| 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. |