3.4 Example 4: Push Event Subscriptions

The communication flow of subscription and event delivery is based on asynchronous operations, as specified in [MS-WMI] section 3.2.4.2.9. A detailed description of each message follows.

Prerequisites

  • The WM application knows the type of events to which it will subscribe.

Initial system state

None.

Final system state

The WM application has subscribed to a particular event successfully and received the event notifications.

Sequence of events

The following diagram shows the communication flow of subscription and event delivery with push subscriptions in the context of the system components, as described in section 2.1.4, using the WMI protocol, as described in section 2.5.2.5.

Communication flow of subscription and event delivery with push subscriptions

Figure 12: Communication flow of subscription and event delivery with push subscriptions

The following steps describe this sequence of events:

  1. Subscribe: To initiate the subscription, the WM client application sends a request through the component that implements the client role of the WMI protocol. The exact data and format of this request are implementation-specific.

  2. Subscribe: The WMI client role of the WMI protocol sends the supplied information to the WMI server role of the WMI protocol. The request contains the necessary routing information to direct the message to the correct endpoint, along with the necessary information to define the specific set of events that will be delivered, such as a particular CIM class and a filter that selects only critical error events.

    For details about the exact message content and format, see [MS-WMI] section 3.1.4.3.21.

  3. Subscribe: The WMI server role of the member protocol sends the supplied information to the CIMOM to register the subscription. This message contains the same information as the message in step 2.

  4. Response: The CIMOM registers the subscription, and then sends a response to the server role's subscribe request that indicates the success or failure of the subscribe request and any additional necessary data, such as information that is required to identify the specific subscription to be canceled when sending an unsubscribe request.

  5. Response: The WMI server role sends a response to the client role's subscribe request that indicates the success or failure of the subscribe request. This message contains the same information as the message in step 4.

    For details about the exact message content and format, see [MS-WMI] section 3.1.4.3.21.

  6. Response: The WMI client role sends a message to the application that indicates the success or failure of the subscription.

  7. Event: When an event is generated, the managed objects send the event to the CIMOM. The content and format of this message are implementation-dependent.

  8. Event: The CIMOM determines whether the event in step 7 has to be delivered, based on the registered subscriptions. If so, the event is handed off to the server role of the member protocol. The CIMOM implementation dictates the exact format of this message. It is not specified by any of the individual member protocols.

  9. Event: The WMI server role of the WMI protocol sends the event to the client role. This message contains the call to the IWbemObjectSink::Indicate() method, as defined in [MS-WMI] section 3.1.4.2.1, along with the actual event being delivered.

  10. Response: The WMI client role of the WMI protocol sends a message back to the server role of the WMI protocol to send the response to IWbemObjectSink::Indicate(), as defined in [MS-WMI] section 3.1.4.2.1.

  11. Event: The client role of the member protocol delivers the actual events to the application. The format of this message is implementation-dependent.

  12. Unsubscribe: When the WM application is finished receiving events, it issues a request to the client role of the member protocol to unsubscribe. The request contains the necessary routing information to direct the message to the WMI server role, along with whatever information is necessary to identify the specific subscription that is to be canceled.

    For details about the exact message content and format, see [MS-WMI] section 3.1.4.3.2.

  13. Unsubscribe: The WMI client role of the member protocol sends the supplied information to the WMI server role of the member protocol. This message contains the same information as the message in step 12.

  14. Unsubscribe: The WMI server role of the member protocol sends the supplied information to the CIMOM. This message contains the same information as the message in step 18.

  15. Response: The CIMOM clears any stored subscription information and deletes the subscription. It then sends a response back to the WMI server role that indicates the success or failure of the subscription cancellation.

  16. Response: The WMI server role of the member role sends a response back to the WMI client role that indicates the success or failure of the subscription cancellation.

    For details about the exact message content and format, see [MS-WMI] section 3.1.4.3.2.

  17. Response: The WMI client role reports the success or failure of the subscription cancellation to the application. The format of this message is implementation-dependent.

  18. Request: After the subscription is canceled, a call is made from the server role to the client, as specified in [MS-WMI] section 3.1.4.2.2.

  19. Response: The WMI client role sends back the response to the call that was made in step 18.