[This is preliminary documentation and subject to change.]
The IWbemEventConsumerProvider interface includes one unique method: FindConsumer. The first time an event must be delivered to a particular consumer, CIMOM calls this method to retrieve a pointer to the sink for that logical consumer. All subsequent occurrences of the event are sent to the sink provided in the initial call through its IWbemUnboundObjectSink::IndicateToConsumer method. CIMOM will release the sink after a configurable period of no deliveries. If an event is targeted for a consumer that has been released, FindConsumer will be called again to acquire a new sink.
There are three approaches to implementing the FindConsumer method:
Regardless of approach, a sink should not be implemented in such a way that it is dependent on the event consumer provider. CIMOM releases an event consumer provider after a designated interval has lapsed between calls. Because the event consumer provider is needed only to supply pointers to sinks for new logical consumers, CIMOM can release it after all of the logical consumers have been serviced. The sinks, however, must remain to receive all of the events that occur.
Deciding which of the three approaches to take is important because the decision can affect performance and efficiency. The first approach, implementing a single sink, is the most efficient in terms of space because only one COM object is stored in memory. The second approach is the opposite of the first and is intended to optimize performance. Having a dedicated sink ready to receive an event as it occurs saves time. The third approach is a hybrid, a compromise between the first two approaches.
To illustrate the trade-offs between implementation strategies, consider an event consumer provider that supplies sinks for logical consumers that log messages to files. With the first strategy, the event consumer provider supplies the same sink for all events that arrive for all logical consumers. The single sink bears the responsibility for examining the data included with the logical consumer and determines how to proceed. Most likely, each event involves opening a file, logging the message, and closing the file. While efficient in terms of space, this strategy would involve a significant amount of processing time.
The second strategy is faster, but less efficient because of its cost in terms of memory. The event consumer provider supplies a different sink for each logical consumer. Because each sink maintains its own file, the file is always open and ready to log messages as events occur. The sink could then close the file when it is released by CIMOM after a timeout, providing efficient performance both in high-speed and in low-speed delivery scenarios.
The hybrid approach can involve having a few different files, possibly tied to the particular message to be logged. As a compromise between the first two strategies, multiple COM objects handle multiple open files. An event consumer provider taking this approach reads the file name during the FindConsumer call, opens the file, and returns the sink that will log all messages into this file, closing it on the last Release. With this approach, the efficiency of knowing exactly which file to log to without searching or opening it anew is preserved. Also, the consumer can save memory by combining the sinks that log different messages to the same file, an area where no performance gains are to be had.