The NDPS managed object database (MOD) supports the various relationships among classes of objects such as "object x is contained by object y" or "object x is supported by object y."
See the following topics for further discussions about the relationship between objects and their information:
The following figure illustrates the containment relationship. All objects that are connected to the printer are contained by a printer object, which represents the printer agent.
Figure 9Each document object is contained by a job object. Only the objects with connecting lines are contained by another object. All objects except the manager object are referenced by the printer object. Most objects are also referenced by one or more of the objects that are contained by the printer object.
For example, a medium object is referenced by the ndps-att-input-current-medium attribute of an input object. The same object is also referenced by the ndps-att-media-supported and ndps-att-media-ready attributes of the printer object.
The ndps-att-media-ready attribute contains a summary of the values found in the input objects contained by the printer object. The same medium object can also be referenced by other attributes, including the ndps-att-default-medium attribute and the ndps-att-page-media-select attribute of a document object.
While the marker-supplies and marker-colorant classes are contained by the printer class, they are also referenced by an instance of the marker class. This is an example of a support relationship: the marker uses supplies and colorant.
The NDPS architecture must reconcile the following issues to support both the Document Printing Application (DPA) and the Printer MIB standards:
DPA uses id-att-input-trays-ready and id-att-input-trays-supported attributes to identify which input trays are either ready for use or are supported and could be ready. The syntax for these attributes is NWDP_AVT_OBJECT_IDENTIFIER and they can take on OID values indicating things like top, middle, and manual feed. This approach identifies an input tray by location but does not describe any other characteristics of an input tray.
DPA also uses an id-att-input-trays-medium attribute to identify which medium is loaded in each tray.
The Printer MIB includes an input class that describes an input tray more completely, including attributes for physical dimensions, capacity, and current status. The Printer MIB definition includes an optional input media group that describes the medium in the tray.
The NDPS input class is based on the Printer MIB input object. NDPS also implements the DPA medium class to describe the media supported by the printer. Since the medium class describes the media supported by the printer, the optional input media group is not used.
Besides the attributes in the Printer MIB, the input class has an ndps-att-input-location attribute and an ndps-att-input-current-medium attribute. The location attribute can contain any of the values that the two DPA tray attributes could hold. The current medium attribute references an instance of the medium class to identify the medium in the input tray.
NDPS does not support the concept of input-trays-ready or input-trays-supported as DPA does, but it accomplishes the same thing with printer-contained input objects. Those that are contained and have a status of active are ready and those that are contained but have some other status are supported.
The DPA output-method class is not used. The NDPS output class is used instead, based on the output group in the Printer MIB. The well-known attribute values for output methods are used. The capability for an output object to support these methods is indicated in the features attributes of the output class.
Instances of the DPA delivery-method and transfer-method classes are identified with well-known OIDs. DPA also specifies attributes to describe the characteristics of the delivery methods and transfer methods that are identified by these objects. NDPS does not implement instances of these object classes, although they are supported.
The well- known identifier attribute values for the methods are used. The well-known transfer-method identifier values are used to populate the ndps-att-printer-transfer-methods-supported attribute, as described in the DPA standard, but this attribute in not implemented. NDPS implements the transfer method value ndps-val-transfer-method-ndps-data to transfer document data to the printer agent.
NDPS does not implement or support the DPA initial-value-job or initial-value-document object classes. Instead, NDPS implements job-defaults and doc-defaults classes, as well as job-limits and doc-limits classes. The defaults classes enable a printer agent to apply a default set of attributes on each print job and document that it creates. The limits classes enable a printer agent to impose limits on the attributes of print jobs and documents when they are created or modified. Defaults and limits can be defined for a printer agent or for each NDS printer object that is associated with a printer agent.
The syntax of the identifier for these classes is NWDP_AVT_PRT_CONFIG_OBJ_ID and is defined as the NWDPPrtConfigObjectId structure.
When a print request is accepted by the printer agent, it applies job defaults and limits as follows:
Document default and document limits objects are applied to each document object as it is created, following the same sequence as the print job object.
If one or more attributes of either the job or document fails validation, a list of failed attributes is returned to the client, as part of an error report, and the job or document is not created.
The NWDP_ModifyJob operation and NWDP_Set operation on a job or document object are also validated with the respective limits object, as described for creation of a job or document.
The Printer MIB identifies each page description language (PDL) or printer control language (PCL) supported by a printer, using an enumeration for the attribute value syntax. DPA represents these same values by appending the Printer MIB enumeration to the object identifier id-vc-document-format. The DPA attribute id-att-document-format attribute uses this syntax, together with optional fields to identify the version and variants of a PDL.
NDPS uses the enumeration from the Printer MIB specification. NDPS does not implement the DPA id-att-document-format attribute.
The printer agent uses the ndps-att-printer-state object attribute of its printer object to track the operational state of the printer agent. The ndps-att-printer-state attribute also provides information about the state of the interfaces that the printer agent shares with the physical device subsystem (PDS) and port handler (PH), or the gateway.
The ndps-att-printer-state attribute has NWDP_AVT_OBJECT_IDENTIFIER syntax and is single-valued. The following OIDs represent the supported states for a printer agent:
The ndps-val-printer-state-active OID is used only in the NDS object (NDPS printer) to represent both the printing state and the idle state. This value is used in the NDS object because the printer can change too rapidly between the two states to continually update the state attribute in the NDS object.
The information in the ndps-att-printer-state attribute is complemented by two additional attributes: ndps-att-printer-enabled and ndps-att-printer-state-reasons.
The ndps-att-printer-enabled attribute has NWDP_AVT_BOOLEAN syntax and is single-valued. The default value for this attribute is TRUE. When the attribute value of ndps-att-printer-enabled is FALSE, the printer agent will not accept requests for new print jobs. Jobs that have already been accepted are allowed to complete submission and processing. Other service provider routines, such as NWDP_ModifyJob, NWDP_Set, and NWDP_ListObjectAttributes, are also unaffected.
The ndps-att-printer-state-reasons attribute has a multi-valued NWDP_AVT_PRINTER_STATE_REASON syntax and is defined as the NWDPPrinterStateReason structure.
The highest level of severity present in the ndps-att-printer-state-reasons attribute values at any given time determines the resulting effect on the printer agent state. For example, if one value has a STATE_SEVERITY_WARNING level and another value has a STATE_SEVERITY_CRITICAL level, the effect on the printer agent state is critical, and the state goes to stopped. Many of these OIDs are derived from Printer MIB alerts (for example, inputMediaTrayMissing and markerInkEmpty).
The following table shows the state transitions that can occur from each printer agent state and the combined effect of the ndps-att-printer-enabled attribute and the ndps-att-printer-state attribute. Entries that include the disabled condition reflect the combination of the two attributes (for example, there is no printer state OID for id-val-printer-state-disabled-paused).
The NDPS job ndps-att-current-job-state-object attribute is used to represent the state of a print job. Additional information about the state of the job is provided by the related attributes ndps-att-previous-job-state and ndps-att-job-state-reasons.
The ndps-att-current-job-state and ndps-att-previous-job-state attributes have NWDP_AVT_OBJECT_IDENTIFIER syntax and are single-valued. Job state value OIDs represent the supported states for a job. The following job state value OIDs are supported:
The ndps-att-job-state-reasons attribute has NWDP_AVT_OBJECT_IDENTIFIER syntax and is multi-valued. This attribute is not used to determine the current job state. It is updated when the current job state changes. The same is true for the ndps-att-previous-job-state attribute.
The following table lists the state transitions that can occur from each job state:
The NWDP_ListObjectAttributes operation is based on the DPA standard list object attributes (LOA) operation. There are three ways to specify the object instances to query:
When a specified object class is contained by the printer class and the client is bound to the PSM, all object instances of that class are listed. If the client is bound to a printer agent, only the object instances contained by that printer agent are listed. When the job class is specified, retained jobs are listed after current jobs. Retained jobs are listed as members of the job class, with a retained job state. To list only retained jobs, the retained-job class can be specified, or the job class can be specified with a filter for the retained job state, although filtering is much less efficient.
NDPS uses the abstract-event class to report events that occur on print jobs and the printer. Each printer agent contains six abstract event objects that enable a client to list the available abstract events and to register interest in those events. The types of events supported by these objects are the following:
The syntax of the identifier for this class is NWDP_AVT_EVENT_OBJECT_ID and is defined as the NWDPEventObjectId structure.
An NDPS client can indicate interest in specific events by registering a notification profile with the printer agent. The notification profile specifies the object identifier for the event type and lists the attributes for the desired events. The notification profile can also register interest in all events of the specified type without listing the individual attributes of that type.
The identifier for each attribute of an abstract event object is the object identifier for an event. For example, the identifier for the event to report that the printer is off-line is ndps-att-alert-printer-off-line.
The syntax of abstract event object attribute values is NWDP_AVT_OBJECT_IDENTIFIER. The attribute value for each event normally contains the object identifier for the job class for print job events or the printer class for printer events.
Event attributes within an abstract event object can be grouped for filtering by adding an attribute whose identifier is the OID defined for the desired filter group. The filter identifier is also placed in the attribute value of each attribute for the events to be included in the filter group.
For example, a filter attribute can be created for paper jam events. Then, events for paper jams in different components of the printer can be grouped together by placing the identifier of the filter attribute in the attribute value for each of the paper jam events. Interest in the filter group is registered by specifying the identifier for the filter attribute in a notification profile.
A notification profile can also register for notification of a change in the value of any object attribute in the MOD. This is accomplished by specifying the class and identifier of the desired object instead of one of the abstract event objects.
The notification profile can list the object attributes to flag for events, or it can specify interest in value change events for all attributes of the object.
A notification profile can be registered directly with the printer agent or it can be an attribute of a print job. A notification profile that is an attribute of a print job is registered when the print job is scheduled for printing or is being processed by the printer agent. The notification profile is de-registered when the print job is in a held state or is scheduled to print after a specified time in the future. The notification profile is registered when the hold is removed or the print-after time expires.
The scope of print job events that are specified in a notification profile (an attribute of a print job) can be controlled by the identification used. The notification profile includes a containingObjectId field. If this field contains the identifier of the printer agent, the print job events that it specifies will be reported for all print jobs processed by the printer agent, while the notification profile is registered. If the field contains the identifier of the print job, print job events will be reported only for that print job. The administrative utilities specify the syntax for the print job identifier in the containingObjectID field so that the client received job events only for the job containing the notification profile.
The Printer Pool class enables a group of printer agents to share print jobs. A printer pool has its own job pool and binds to a scheduler in the same way as a standalone printer does. When a printer agent is added to a printer pool, the printer agent is unbound from its assigned scheduler.
Because a printer agent user belongs to a printer pool, they can install the printer in the same manner as a standalone printer agent.
Print jobs are managed by the scheduler that is associated with the printer pool. Each printer agent in the printer pool requests print jobs from the printer pool scheduler.
When a printer agent is bound to a physical print device through a gateway, it is the responsibility of the gateway to create and populate the objects that describe the features and capabilities of the print device These objects are created and their object attributes are populated by submitting requests to the printer agent.
Some print devices support a comprehensive information model, such as a printer MIB. Others only report essential status information, such as online/offline and a generic error state. The information that is maintained about a print device can obviously be more complete for a print device that supports a more comprehensive information model. However, there are a few objects and attributes that should be supported whenever possible. These are useful in enabling users to select a desired printer and operators to manage the printer.
Some of the object attributes that describe the print device are used by the printer agent to provide information about the capabilities of the printer. Certain attributes of objects that are contained by a printer object are summarized into related attributes of the printer object. Some printer object attribute values are replicated in the corresponding attributes of the NDPS printer objects that are associated with the printer agent and are as follows:
The NDPS objects in NDS store the following types of information:
Each object instance must have a unique identifier so it can be unambiguously referenced and stored in the MOD. Each class has a supported identifier attribute with a defined syntax. The identifier is not implemented for some classes, since the object descriptor that contains the attribute set for each object contains an identifier for the object.
The following table lists the NDPS object class identifier attributes and their syntaxes.
Some NDPS operations reference different object classes at different times. For example, the NWDP_ListObjectAttributes operation can list attributes for any object in the MOD. The flexibility to reference the identifiers for different object classes is supported by the NWDPObjectIdentification structure.
The information stored in the NDPS printer object enables NDPS clients to search specific capabilities by using NDS. The results of these searches enable an NDPS user to select an appropriate printer. Some of these attributes are replicated information from the MOD for the associated printer agent. The table below shows which attributes from the MOD are replicated in NDS. (See Attribute Types and the printer class specification for a definition of the MOD attributes.) The role attributes control access to services provided by the associated printer agent.
The state of the printer agent is summarized in the associated NDPS printer objects by mapping possible values of the ndps-att-printer-state attribute of the printer object in the MOD to the printer status attribute of the NDPS printer object in NDS.
NOTE: When the ndps-att-printer-enabled attribute of the printer object is set to FALSE, the printer agent rejects a request to create a new print job. This attribute is separate from the ndps-att-printer-state attribute and is not reflected in the NDPS printer object in NDS.
This is the information stored in the NDPS manager object in NDS. No attributes of the manager object in the Managed Object Database are replicated in NDS.
This information is stored in the NDPS broker object in NDS. Since there is no broker in the MOD, there is no relationship between the NDPS broker object and the MOD (as there is with the NDPS printer object).
NDPS adds an attribute, NDPS default printer, to the organization object and the organizational unit object in NDS. When this attribute contains the name of an NDPS printer object, that printer is made the default printer when it is installed on a client that supports a default printer.
NDPS Container Object Attribute | NDS Attribute Syntax | Description |
---|---|---|
NDPS Optionals |
||
NDPS Default Printer |
SYN_DIST_NAME |
NDPS printer object name for the default printer. |