3.1.1.2 Publishers

Events are raised to the system by a publisher (though this is not through the EventLog Remoting Protocol Version 6.0). For more information on how to provide events, see [MSDN-ProvEvts].

The publisher is registered within the system and has an identifier and a publisher name. The identifier of a publisher is a UUID, which is 16 bytes. For example, {10ccdb74-baf6-4164-b765-c292096626df} can be served as the identifier for a publisher. The publisher resource file contains all the metadata information for the publisher (as specified in section 3.1.1.14). The message file of a publisher contains all the description strings of a publisher (as specified in section 3.1.1.14). The publisher parameter file is another message file that is used for parameter substitution (as specified in section 3.1.1.14). The publisher name is an arbitrary Unicode string. The publisher provides the events into channels (as specified in section 3.1.1.4), it declares the channels that can be used during the registration. The server saves all the channels a publisher declares and associates them with the publisher.

The following is an example of two registered publishers and their associated channels:

Publisher1: Publisher1 Name, Publisher1 Identifier, Publisher1 Resource File, Publisher1 Message File, Publisher1 Parameter File

  • Channel A: Channel A reference ID, Channel A reference flag, Channel A start index

  • Channel B: Channel B reference ID, Channel B reference flag, Channel B start index

Publisher2: Publisher2 Name, Publisher2 Identifier

  • Channel C: Channel C reference ID, Channel C reference flag, Channel C start index

  • Channel B: Channel B reference ID, Channel B reference flag, Channel B start index

In this example, Publisher1 indicates that it will provide events to two channels, Channel A and Channel B. Publisher2 indicates that it will provide events to Channel C and Channel B. So in this case, Channel B is shared between two publishers and it can contain the events from both publishers.

The channel reference ID is the relative index number of a channel, while the channel start index is an absolute start offset for the channel in the channel table. For example, publisher 1 declares two channels: Channel A and Channel B. Thus the channel A reference ID is 0 because it is the first channel of publisher 1 and the channel B reference ID is 1 since it is the second one relative to the publisher. But at the same time, the declared channels have to be registered in the channel table (as specified in section 3.1.1.5). The same channel will get a different index number when the channels are registered to the channel table. For example, when the channel table contains 10 channels already, and when channel A is registered, it will get an index of 11, and channel B will get an index 12. As such, the start index of channel A is 11 and the start index of channel B is 12.

The channel reference flag is a numeric value used for the purpose of extension. There is no recommendation on how the server SHOULD use it. By default, all the channel reference flags are 0. The server can use it for any special purpose.

The publisher is only registered on the local machine. It cannot be registered to a remote server.

Publisher identifiers can be obtained through the protocol and from events that conform to the event XSD, as specified in section 2.2.13. Publisher identifiers MUST be unique.

Also, publishers can have additional metadata registered in the system, consisting of a set of attribute/value pairs, as specified in sections 3.1.4.25 and 3.1.4.26. This can be obtained through the protocol by using the publisher identifier. This metadata typically includes message tables that are used for displaying localized messages. The metadata information is registered to the server when the publisher is installed on the server. Installing a publisher is not in the scope of this protocol.

Note A subset of the set of publishers is logically shared with the abstract data model of the obsolete EventLog Remoting Protocol, if it is also supported. That is, all event sources registered with the original EventLog Remoting Protocol can be enumerated via this protocol (the EventLog Remoting Protocol Version 6.0), but not vice versa.