MFD> Teleconference addition

From: Zehler, Peter (
Date: Thu Jan 15 2009 - 11:22:29 EST

  • Next message: "MFD> Jan 29 Telecon minutes and updated Resource Service spec"



    Bill has provided some Last Call comments on the Scan Service
    specification. I have included his comments on section 10 below. I
    would like to add a discussion on this to today's teleconference. Most
    of the rest of his comments are straight forward and we can cover them
    if time permits.




    10 Scan Service Theory of Operation

    The Scan Service operates autonomously through three phases:
    initialization, online, and offline.


    At power-up the Scan Service enters its initialization phase that
    initializes all its service attributes, connected subunits, may [W1]
    perform a self-testing and may also test its Scan Device(s). After the
    initialization is successful, the Scan Service enters the "Down" state
    (an offline state) and performs a start-up operation that brings the
    service online, authenticates and registers its service with a service
    directory or announces its service to the network domain in which it
    resides. The Scan Service then enters the "Idle" state and becomes ready
    for service discovery and accepting service requests from Scan Clients.


    The Scan Service accepts new requests as long as it's not disabled and
    is in one of the four states: Idle, Processing,[W2] Stopped, or
    Testing. [W3] Performing an administrative Disable[W4] () operation
    while in any state will stop the Scan Service from accepting new jobs.
    Performing an Enable() operation in any state while the Scan Service is
    disabled will enable new jobs to be accepted again.


    A user submits a Scan Job through a local (via MFD UI) or remote (via
    local network or Internet) Scan Client to a selected target Scan Service
    that has the desired scan capabilities. While the service is enabled, a
    Scan Client can request any Scan Service operations specified in
    Sections 11.1 and A Scan Client uses the CreateScanJob
    operation to submit a Scan Job on behalf of a user. A Scan Client needs
    to use the CloseJob() [W5] operation to signal the last set of Hardcopy
    Scan Document input when the scanner's input capacity is limited and
    continuous sets of hardcopies need to be fed into the platen or ADF for
    a large Scan Job. The Scan Service places all submitted jobs in the
    ActiveJobs queue and schedules jobs for processing immediately or when a
    StartJob event is signaled based on job priority. A user may specify a
    JobHoldUntilTime [W6] for a remotely submitted job to allow ample time
    for user to walk up to the scanner for placing his/her Hardcopy
    originals on the scanner. An administrator can also put a job in the
    ActiveJobs queue on hold via a HoldScanJob() operation preventing it
    being scheduled and a ReleaseJob() operation will release the job for
    scheduling again.


    When a Scan Job is released for scheduling and reached the top of
    ActiveJobs queue, the Scan Service immediately enters its Processing
    state[W7] . During job processing, the Scan Service can be interrupted
    by a "PauseScanService()" operation to enter the "Stopped" state. This
    allows a user to submit and process an urgent Scan Job or a job for
    another service, and a Resume() operation resumes previous Scan Job
    processing afterwards.


    When there are critical conditions impacting Scan Serviceability during
    "Idle" or "Processing" state, either a C.Critical event is generated or
    an Administrative PauseScanService() is performed to bring the service
    to the Stopped state. From there the condition can be fixed by user's
    intervention. Then either the Scan Service generates a ~C.Critical event
    or an administrator performs a Resume() operation to bring the Scan
    Service back to "Idle" or "Processing" state. Otherwise, if the Scan
    Service needs a ShutdownScanService() operation followed by a restart or
    ShutdownScanService() for testing, both will require a
    StartupScanService() operation to bring the service back to "Idle" state
    and then restart job processing again.


    At any time all jobs in the ActiveJobs queue, whether being held,
    pending for scheduling, in processing, or being temporarily stopped from
    processing, can be canceled via a CancelScanJob() operation by an
    authorized user. A canceled job, completed job, or an aborted job due to
    processing errors can be placed back into ActiveJobs queue and restarted
    via the administrative RestartJob[W8] () operation and be processed
    along with its Scan Documents again.



    Peter Zehler

    Xerox Research Center Webster
    Voice: (585) 265-8755
    FAX: (585) 265-7441
    US Mail: Peter Zehler
    Xerox Corp.
    800 Phillips Rd.
    M/S 128-25E
    Webster NY, 14580-9701




    b. Do we power-up (a device concept) a service?

    c. Scan Devices (also used elsewhere sould probably be Scanner(s) or
    Scanner Subunits(s)

     [W2]Processing as a service state must be distinguished from processing
    as a job state.

     [W3]Testing is defined as an Off_Line state in

     [W4]Observation: Disable does not change service state, as state is

     [W5]CloseJob is not a defined operation.

     [W6]This appears to be in an administrator operarion, not for a user.
    Further, that does nto appear to be the purpose of JobHoldUntilTime.

     [W7]Job in Processing state vs Service in processing state.
    Presumably, if there were a previous job being processed, the Servuce
    would already be in a processing state?

     [W8]RestartJob appears elsewhere but is not a defined operation.

    This archive was generated by hypermail 2.1.4 : Thu Jan 15 2009 - 11:23:31 EST