3.2.1 Abstract Data Model

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

A server implementing the FSRM protocol maintains the persistent configuration of the following objects:

• Directory quotas (section 3.2.1.2.1)

• Auto apply quotas (section 3.2.1.2.2)

• File screens (section 3.2.1.3.1)

• File screen exceptions (section 3.2.1.3.2)

• Directory quota templates (section 3.2.1.2.3)

• File screen templates (section 3.2.1.3.3)

• File groups (section 3.2.1.3.4)

• Report jobs (section 3.2.1.5.1)

• Reports (section 3.2.1.5.2)

• Property definitions (section 3.2.1.6.1)

• Module definitions (section 3.2.1.6.2)

• Rules (section 3.2.1.6.3)

• File management jobs (section 3.2.1.7.1)

A server implementation also maintains some volatile status data and tracks all relevant file system I/O necessary to maintain accurate quota accounting and file screen prohibitions. In addition to maintaining configuration and state for the objects mentioned earlier, a server implementation also provides a set of interfaces for enumerating collections of objects and an abstraction for manipulating action objects, which are used in quotas, file screens, and file management jobs.

With four exceptions, the abstract data model can be manipulated only through the protocol. These exceptions are:

1. Folder deletion, where the folder has a quota, file screen, or file screen exception configured;

2. Folder creation, where the folder's parent folder has auto apply quota configured;

3. Folder rename, where the folder has a quota, file screen, or file screen exception configured;

4. Volume discovery, where the volume contains folders that have quotas, file screens, or file screen exceptions configured.

These exceptions are discussed in more detail in section 3.2.7.

The abstract model that the server maintains is not made available directly through the protocol. The protocol is an OLE Automation style DCOM protocol, as specified in [MS-OAUT]. With this type of protocol, the server maintains an implementation of the abstract data model and provides access to the model strictly through GET and SET operations on standard Automation data types (BSTR, long, SAFEARRAY, IDispatch, and so on) and RPC methods where the method parameter types are restricted to the same set of standard Automation data types. The result of the OLE Automation style interface is that the wire protocol is restricted to standard RPC method calls using only standard data types; no custom-marshaled data structures are possible on the wire with OLE Automation DCOM protocols. See [MS-OAUT] for details on OLE Automation and the standard OLE data types used by the FSRM protocol.

This section lists objects used by multiple functional areas of the FSRM protocol feature set. Following subsections are organized by the specific functional areas of the feature set:

• Quotas (section 3.2.1.2)

• File screens (section 3.2.1.3)

• Storage reports (section 3.2.1.5)

• Classification (section 3.2.1.6)

• File management jobs (section 3.2.1.7)

Supporting abstractions such as file groups, templates, actions, rules, properties, modules, and notifications are discussed as part of the functional areas that make use of them. Finally, abstractions to support a set of common global settings are described.

The server maintains the following object used by multiple models:

Volume List: A volatile list of all the volumes on the server.