The ability to detect when a circumstance or combination of circumstances occurs and deliver notification of the event(s) to the consumer is an essential feature for a practical distributed system. Given a system of even moderate complexity, it would be impossible to track and react to events by polling the available data sources. Both the burden on the consumer and the volume of data implied is too large to be practical. Nonetheless, this is in fact what many management applications require. Vast quantities of data get written to centralized logs, which are then examined for combinations of circumstances that indicate that some action must be taken (for example, billing, preventive maintenance, or backup).
WMI supports a rich eventing infrastructure that allows events to be published, filtered, subscribed to, and logged by the combination required for the application at hand. All the WMI event-handling capabilities are configured using standard WMI idioms that can be monitored and controlled, whereby WMI can manage and configure itself. In WMI, events, publications, and subscriptions are represented using WMI objects allowing them to be delivered to sources and consumers using the same mechanisms that are supported for regular WMI classes and instances.
WMI also allows the user to define permanent event consumers that are invoked whenever an event to which the consumer subscribes occurs. All significant events on the server are visible to WMI (including time), which allows intelligence to be built into the WMI permanent event consumer such as "Back up the system configuration every night at 11:00 P.M. or anytime the database is restarted — don't back up the system configuration more than one time in an 8-hour period." Using WMI permanent event consumers, any combination of actions can be initiated as a result of the occurrence of events in the environment. The ability to place intelligence into the permanent event consumer allows the system to be constructed in such a way that data streams do not have to be pushed up to higher level consumers as decisions and actions; they can be taken locally by the system itself by requiring nothing more than status events to be pushed to higher levels of the architecture.