3.1.1.1 Abstract Data Model

This section describes a conceptual model of the possible data organization that an implementation SHOULD maintain to participate in this protocol. The organization that is described in this section is provided to facilitate the explanation of how the protocol behaves. This specification does not mandate that implementations adhere to this model as long as their external behavior is consistent with the behavior described in this specification.

This section describes the Print System Asynchronous Notification Protocol in terms of an abstract data model that represents physical devices as objects and provides interfaces for communication and configuration management.

Current Authenticated User: A print server data structure scoped to the context of processing a particular message. This data structure holds an implementation-specific identifier for the authenticated user identity.

Client Registration: A print server data structure that holds all the information provided by a print client via input parameters in its call to IRPCAsyncNotify_RegisterClient (section 3.1.1.4.1), as well as the Current Authenticated User when the server processed the message for the clients call. The Client Registration maps directly to a registered PRPCREMOTEOBJECT (section 2.2.4). The server MUST use this information to filter Bidirectional Notification Channels and unidirectional notifications that are sent to the client from notification sources. Other Local Events (section 3.1.1.6) specifies this filtering mechanism, which is based upon information associated with requests that originate from notification sources.

Unidirectional Notification Queue: Associated with each Client Registration in unidirectional communication mode, a queue of unidirectional notifications that have been initiated by server-resident notification sources, but which have not yet been returned to the client of the Client Registration by IRPCAsyncNotify_GetNotification (section 3.1.1.4.5).

Bidirectional Notification Channel Queue: Associated with each Client Registration in bidirectional communication mode, a queue of bidirectional notification channels that have been opened by server-resident notification sources, but which have not yet been acquired by a client, as specified in IRPCAsyncNotify_GetNotificationSendResponse (section 3.1.1.4.4).

Bidirectional Notification Channel: A notification channel that is created for use by a single notification source in bidirectional communication mode. Associated with each Bidirectional Notification Channel are PrintAsyncNotificationType and PrintAsyncNotifyUserFilter values (sections 2.2.1 and 2.2.2), and an authenticated user identity, which are provided by the notification source when the channel is opened, as specified by the local event Bidirectional Notification Channel Opened (section 3.1.1.6.2).

The Bidirectional Notification Channel is exposed to zero, one, or more clients as a PNOTIFYOBJECT (section 2.2.5) that is returned by IRPCAsyncNotify_GetNewChannel (section 3.1.1.4.3). Each client is distinguished by a specific PNOTIFYOBJECT, and one client, at most, can be marked as having acquired the Bidirectional Notification Channel. After a particular client has acquired the channel, none of the responses from other clients will be successfully accepted by the server. This continues even after the channel is closed; once acquired, the channel can never be acquired again.

Zero or one unsent notifications can be associated with the Bidirectional Notification Channel. Held notifications are discussed in Bidirectional Notification Generated (section 3.1.1.6.3). A held unsent notification is used for the initial notification mediating behavior specified in IRPCAsyncNotify_GetNotificationSendResponse (Opnum 4) (section 3.1.1.4.4).

Note The preceding conceptual data can be implemented using a variety of techniques.