You are hereJDF Glossary
JDF Glossary
JDF Terminology how specified in JDF Specification.
a | b | c | d | e | f | g | h | i | j | k | l | m | n | o | p | q | r | s | t | u | v | w | x | y | z | 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9
- Alces
- Alces is a tool for testing JDF software. Alces plays the role of a Controller/Manager and is used for testing the JDF compliance of a Worker, such as a RIP, a printing press, or a binding machine. Alces is a Java program and comes in two flavors, one for interactive/manual testing, and one for automated testing. (Source: cip4.org)
- CloseQueue
- The queue is closed. No further queue entries are accepted by the queue. The status of entries that are already in the queue remains unchanged and prior entries can be executed. (Source: JDF Spec. 1.4a)
- FlushQueue
- The JMF Command 'FlushQueue' is used to remove QueueEntry Elements from the Queue. Note: A QueueEntry is not automatically deleted when executed or aborted, but rather it remains in the Queue and its Status is changed to 'Completed' or 'Aborted' accordingly. FlushQueueParams allows the specification of which QueueEntry Elements to remove. The QueueFilter in the FlushQueue Message is applied to the Queue returned after the command is executed. The QueueFilter contained within the FlushQueueParams is used to specify which QueueEntry Elements to remove.
- HoldQueue
- The queue is held. No entries will start execution. Note that the status of a held entry prior to HoldQueue is retained so that held Jobs remain held after a ResumeQueue. New entries can still be submitted to a held queue. HoldQueue only has effect on Jobs that have not commenced processing. Queue entries that are already running MUST be suspended individually using the SuspendQueueEntry Command Message. (Source: JDF 1.4a)
- JDF Agents
- Agents in a JDF workflow are responsible for writing JDF. An Agent has the ability to create a Job, to add Nodes to an existing Job, and to modify existing Nodes. Agents can be software Processes, automated tools or even text editors. Anything that can be used in composing JDF can be considered an Agent. Actual implementations of Devices or Controllers will most often be able to modify JDF. These system components have Agent properties in the terms of this specification. (Source: JDF Spec. 1.4a)
- JDF Controller
- Agents create and modify JDF information; Controllers route it to the appropriate Devices. The minimum requirement of a Controller is that it can initiate Processes on at least one Device, or at least one other Slave Controller that will then initiate Processes on a Device. In other words, a Controller is not a Controller if it has nothing to control. In some cases, a pyramid-like hierarchy of Controllers can be built, with Controllers at the top of the pyramid controlling a series of lower-level Controllers at the bottom. The lowest-level Controllers in the pyramid, however, MUST have Device capability. Therefore, Controllers MUST be able to work in collaboration with other Controllers. In order to communicate with one another, and to communicate with Devices, Controllers MUST support the JDF file-exchange protocol and MAY support JMF. Controllers can also determine Process planning and scheduling data, such as Process times and planned production amounts. (Source: JDF Spec. 1.4a)
- JDF Device
- The most basic function of a JDF Device is to execute the information specified by an JDF Agent and routed by a JDF Controller. Devices must be able to execute JDF Nodes and initiate Machines that can perform the physical execution. The communication between Machines and Devices is not defined in this specification. Devices MAY, however, support JMF messaging in order to interact dynamically with Controllers. (Source: JDF Spec. 1.4a)
- JDF Document
- JDF is an interchange data format to be used by a system of administrative and implementation-oriented components, which together produce printed products. It provides the means to describe print Jobs in terms of the products eventually to be created, as well as in terms of the Processes needed to create those products. The format provides a mechanism to explicitly specify the controls needed by each Process, which might be specific to the Devices that will execute the Processes. (Source: JDF Spec. 1.4a)
- JDF Machine
- A Machine is any part of the workflow system designed to execute a Process. Most often, this term refers to a piece of physical equipment, such as a press or a binder, but it can also refer to the software components used to run a particular Machine. Computerized workstations, whether run through automated batch files or controlled by a human worker, are also considered Machines if they have no JDF interface. (Source: JDF Spec. 1.4a)
- JMF Acknowledge
- An JMF Acknowledge is a Message that is an asynchronous answer to a Command Message or Query Message issued by a Controller. Each Acknowledge Message is unidirectional and similar to a JMF Response Message, and the refID Attribute of each refers to the initiating command. Acknowledge Messages are generated if commands with long latency have been executed in order to inform the Command Message sender about the results. Acknowledge Messages are only generated if the initiating Command Message has specified the AcknowledgeURL Attribute or a pair of AcknowledgeFormat and AcknowledgeTemplate Attributes. (Source: JDF Spec. 1.4a)
- JMF Command
- A JMF Command Message is syntactically equivalent to a JMF Query Message, but rather than simply retrieving information, it also causes a state change in the target Device. (Source: JDF Spec. 1.4a)
- JMF Message
- A workflow system is a dynamic set of interacting Processes, Devices and MIS systems. For the workflow to run efficiently, these Processes and Devices need to communicate and interact in a well defined manner. Messaging is a simple but powerful way to establish this kind of dynamic interaction. The JDF-based Job Messaging Format (JMF) provides a wide range of capabilities to facilitate interaction between the various aspects of a workflow, from simple unidirectional notification through the issuing of direct commands. (Source: JDF Spec. 1.4a)
- JMF Query
- A JMF Query is used as a Message that retrieves information from a JDF Controller or JDF Device without changing the state of it. (Source: JDF Spec. 1.4a)
- JMF Registration
- A JMF Registration Message is a request to the recipient of the JMF to send Command Messages to a Command recipient who is specified in Subscription. See 'Persistent Channels for Commands' for details on persistent channels for Commands. (Source: JDF Spec. 1.4a)
- JMF Response
- A JMF Response Message is used to reply to a Query or a Command and is always a direct answer of a Query or a Command. A Response Message is returned from a Controller to the Controller that submitted the Query or Command; however, Response Message(s) are not acknowledged themselves. A Response Message indicates that a Query or Command. has been received and interpreted. The Response of a Query or Command with short latency also includes the information about the execution. A Query or Command with long latency may additionally generate a separate JMF Acknowledge Message to broadcast the execution of the Query or Command. A Response should contain a Notification Element that describes the return status in text if ReturnCode is greater than 0. A Response contains an Attribute called refID, which identifies the initiating Query or Command. (Source: JDF Spec. 1.4a)
- JMF Signal
- A JMF Signal is used as a Message, which is equivalent to a combination of a JMF Query Message and a JMF Response Message. It is a unidirectional Message sent on any event to other Controllers. This kind of Message can be used to automatically broadcast status changes. JDF Controllers can get Signal Messages in one of three ways. The first way is to subscribe for them with an initiating Query Message transmitted via a Message channel that includes a Subscription Element. The second way is to subscribe for them with an initiating Query Message defined in the NodeInfo Element of a JDF Node that also includes a Subscription Element. The first Query Message is transmitted separately via a mechanism such as HTTP, whereas the second is read together with the corresponding JDF Node. Once the subscription has been established, signals are sent to the subscribing Controllers via persistent channels. In both cases, however, the Signal Message contains a refID Attribute that refers to the persistentchannel. The value of the refID Attribute identifies the persistent channel that initiated the Signal. The third way in which a Controller can receive a signal is to have the signal channels hardwired, for example, by a tool such as a list of Controller-URLs read from an initialization file. For example, signals MAY be generated independently when a service is started, or when sub-Controllers that are newly connected to a network want to inform other Controllers about their capabilities. Hardwired signals, however, MUST NOT have a refID Attribute. If no refID is specified, the corresponding query parameters MUST be specified instead. (Source: JDF Spec. 1.4a)
- KnownDevices
- The JMF Query Message 'KnownDevices' requests information about the Devices that are controlled by a Controller. If a high level Controller controls lower level Controllers, it SHOULD also list the Devices that are controlled by these. The response is a DeviceList which is list of DeviceInfo Elements controlled by the Controller that receives the query. (Source: JDF Spec. 1.4a)
- KnownMessages
- The KnownMessages Query Message returns a list of all Message types that are supported by the Controller or Device. (Source: JDF Spec. 1.4a)
- MIS
- The overseer of the relationships between all of the units in a workflow is known as Management Information Systems or MIS. MIS is, in effect, a macrocosmic Controller. It is responsible for dictating and monitoring the execution of all of the diverse aspects of the workflow. To do this, it must remain in contact with the actual production facilities. This can be accomplished either in real time using JMF messaging or post facto using the audit records within JDF. (Source: JDF Spec. 1.4a)
- OpenQueue
- The queue is opened and new queue entries can be accepted by the queue. A held queue remains held. The OpenQueue Command Message is the opposite of a CloseQueue Command Message.
- Persistent Channel
- JMF Query and JMF Command Messages are subscribed for using Subscription Elements. There are two types of Persistent Channels: One for JMF Signals (Persistent Channel for Signals) and one for JMF Commands (Persistent Channel for Commands). (Source: JDF Spec. 1.4a)
- Persistent Channel for Commands
- JMF Commands can also be subscribed for by using a Subscription Element in an initial JMF Registration. A Subscription in a JMF Registration defines a request for the initial Registration Message receiver to subsequently send Command Messages to the recipient defined in Subscription/@URL or Subscription/@Format + Subscription/@Template. For instance, an MIS might send a Registration to a prepress workflow system that directs the prepress workflow system to send Command Messages to a press Controller whenever a plate or preview has been produced. (Source: JDF Spec. 1.4a)
- Persistent Channel for Signals
- JMF Queries are made persistent by including a Subscription Element that defines the persistent channel-receiving end. The responding Controller SHOULD initially send a Response Message to the subscribing Controller. Then the responding Controller SHOULD send Signal Messages whenever the condition specified by one of the Attributes in the following table is true. This is referred to as a persistent channel. The refID Attribute of the Signal is defined by the ID Attribute of the Query. In other words, the refID of the JMF signal identifies the Persistent Channel. Any JMF Query can be set up as a Persistent Channel, although in some cases this might not make sense. (Source: JDF Spec. 1.4a)
- ResumeQueue
- The queue is activated and queue entries can be executed. The ResumeQueue JMF Command Message is the opposite of a HoldQueue Command Message. (Source: JDF Spec. 1.4a)
- ResumeQueueEntry
- The hold status of the queue entry specified by QueueEntryDef is removed. A QueueEntry with Status = 'Held' gets a Status of 'Waiting'. A QueueEntry with Status = 'Suspended' gets a Status of 'Running'. (Source: JDF Spec 1.4a)
- ReturnQueueEntry
- The ReturnQueueEntry Message returns a Job that had been submitted with a SubmitQueueEntry to the queue that represents the Controller that originally submitted the Job. The ReturnQueueEntryParams Element provides the parameters. Note that this command is emitted from the Device that is represented by the queue to a Controller or dispatcher and not to the queue, as is the case with most other queue handling commands. (Source: JDF Spec 1.4a)
- StopPersistentChannel
- The StopPersistentChannel JMF Command Message unregisters a listening Controller from a persistent channel. No more Messages are sent to the Controller once the command has been issued. A certain subset of signals can be addressed for unsubscription by specifying a StopPersChParams Element. (Source: JDF Spec 1.4a)
- SubmitQueueEntry
- The JMF Command 'SubmitQueueEntry' submits a Job to a queue of a Device or Controller. QueueSubmissionParams provides the parameters of the submission. (Source: JDF Spec. 1.4a)
- SuspendQueueEntry
- The entry specified by QueueEntryDef is suspended if its Status is 'Running'. Its Status is set to 'Suspended'. Whether other queue entries can be run while the queue entry remains suspended depends on implementation. The SuspendQueueEntry Command Message has no effect on Jobs with a Status other than 'Running'. (Source: JDF Spec. 1.4a)
