Browse Prior Art Database

MANAGEMENT OF PRINT JOB INFORMATION USING PRE-FETCH OF JOB MIB INDEX

IP.com Disclosure Number: IPCOM000013302D
Original Publication Date: 2000-Apr-01
Included in the Prior Art Database: 2003-Jun-18
Document File: 2 page(s) / 31K

Publishing Venue

IBM

Abstract

Described is a system with two forms of communications available, one being more lightweight, low overhead and tailored for short messages or event notifications (the “Management Protocol”), and the other being more suitable for large payloads or continuous streams (the “Delivery Protocol”). Due to its overhead and resource consumption, the delivery protocol is used only to supply bulk data involved in the transaction or “job” to be accomplished (ex. a print job). The lighter weight management protocol is used to determine status and progress of the job, either by polling or event notification. Some form of correlation is necessary to synchronize references via the management protocol and the delivery protocol for a particular job. There is an advantage in allowing the device to assign a correlation ID (Job ID) since jobs may originate from a multiplicity of locales (various clients) which may be running in geographically and computationally diverse, heterogeneous environments (and therefore unable to synchronize their job ids relative to a specific device) but the job or transaction is presumably handled or rendered all within the context and awareness of the device itself. The problem of correlating job ID between originator and device or end node when the job is "submitted” via the delivery protocol, but monitored or managed via the management protocol, is resolved by “pre-fetching” the job ID via the management protocol. The pre-fetch is accomplished when the job originating application first employs the management protocol to request a job ID pre-fetch from the device or end-node. The job ID is issued in the response payload of the management protocol and a record of the job is opened at the device. A correlation has now been established between the originator and the end node regarding the job. Status may be queried immediately (if the job has not arrived this will be reflected in the status response). The originator must attach the job ID to the job during submission to the end node via the delivery protocol. Upon arrival, the device or end node must parse the job ID from the payload, using this to properly identify the job. Subsequent queries using the management protocol must reference the job ID.

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 51% of the total text.

Page 1 of 2

  MANAGEMENT OF PRINT JOB INFORMATION USING PRE-FETCH OF JOB MIB INDEX

   Described is a system with two forms of communications available, one being
more lightweight, low overhead and tailored for short messages or event
notifications (the "Management Protocol"), and the other being more suitable for
large payloads or continuous streams (the "Delivery Protocol"). Due to its
overhead and resource consumption, the delivery protocol is used only to supply
bulk data involved in the transaction or "job" to be accomplished (ex. a print
job). The lighter weight management protocol is used to determine status and
progress of the job, either by polling or event notification.

Some form of correlation is necessary to synchronize references via the
management protocol and the delivery protocol for a particular job. There is an
advantage in allowing the device to assign a correlation ID (Job ID) since jobs
may originate from a multiplicity of locales (various clients) which may be
running in geographically and computationally diverse, heterogeneous environments
(and therefore unable to synchronize their job ids relative to a specific device)
but the job or transaction is presumably handled or rendered all within the
context and awareness of the device itself.

The problem of correlating job ID between originator and device or end node when
the job is "submitted" via the delivery protocol, but monitored or managed via
the management protocol, is resolved by "pre-fetching" the job ID via the
management protocol.

The pre-fetch is accomplished when the job originating application first employs
the management protocol to request a job ID pre-fetch from the device or
end-node. The job ID is issued in the response payload of the management protocol
and a record of the job is opened at the device. A correlation has now been
established between the originator and the end node regarding the job. Status may
be queried immediately (if the job has not arrived this will be reflected in the
status response). The originator must attach the job ID to the job during
submission to the end node via the delivery protocol. Upon arrival, the device or
end node must parse the job ID from the paylo...