Windows Media Services SDK banner art
PreviousNext

Event Notification and Authorization Interfaces

The Windows Media Services Event Notification and Authorization API consists of three COM-compliant interfaces. These interfaces specify how the server and authorization components operate together. The authorization component must implement two of the interfaces for the server to invoke their methods. These interfaces are INSSEventNotification and INSSEventAuthorization. The server implements the remaining interface, INSSEventAuthorizationCallback interface, and its methods are invoked by the component.

You must also implement the IUnknown interface that supports three base methods, AddRef, Release, and QueryInterface, as stipulated by the COM specification.

The server running Windows Media Services also employs several context objects that implement IPropertyMap, a generic and prepackaged interface for manipulating named parameters. For more information on contexts, see Event Notification and Authorization Contexts in this document.

The following table briefly describes these interfaces.

Interface Description
INSSEventNotification Used to perform initialization of the entire authorization component, to specify events that trigger a call from the server, and to handle Notification Events. The plug-in component implements this interface, and the server invokes its methods.
INSSEventAuthorization Used to specify which events must be authorized before they can be performed, and to handle Authorization Events. The plug-in component implements this interface, and the server invokes its methods.
INSSEventAuthorizationCallback Used to inform the server of the results of the authorization process. The server implements this interface, and the authorization component invokes its methods.

An authorization component must be able to handle events as well as perform authorization. Thus, each component must implement the INSSEventNotification interface. Every component can selectively respond to event notifications issued by the server. You implement the INNSEventNotification::GetHandledEvents method to specify the types of events for which notification must be sent. In addition to handling events, the event notification interface initializes the component when the server starts, monitors the operational state of the server, and terminates itself when the server is offline.

The INSSEventAuthorization interface deals with event authorization only. A component implements this interface only when it requires authorization. There are only two methods in this interface: INSSEventAuthorization::GetAuthorizedEvents, which specifies the type of events requiring authorization, and INSSEventAuthorization::AuthorizeEvent, which performs the actual process of authorization. An event can require authorization, but not notification, and vice versa.

Any number of different components can be registered for event authorization. For example, one component authorizes the Play event based on the Pay-per-View plan, and another on the Pay-per-Minute plan. When more than one component is registered, the server calls the methods of the authorization interface of each component in turn. The server does not grant the request until it receives permission from all the registered components. If any component denies the request, the server denies permission, and notifies all the components of the denial. Thus, a component must grant permission to any event authorization request that is outside the scope of its prescribed responsibility. For example, a Pay-per-View authorization component must not deny requests for Pay-per-Minute titles.

For performance reasons, a single component capable of handling different authorization schemes is preferred to multiple components handling a single authorization scheme. A single-component implementation helps to reduce the number of interactions between the plug-ins and the server.

PreviousNext


© 1996-1999 Microsoft Corporation. All rights reserved.