JDF-Printing White Paper

Linköping Studies in Science and Technology
Thesis No. 1285
Integrating Systems in the

Print Production Workflow
Aspects of Implementing JDF
Claes Buckwalter
Management
ManagementInformation
InformationSystem
System(MIS)
(MIS)
M M M
W W W
Prepress
Prepress W
Press
Press Binding
Binding
Workflow
Workflow Controller
Controller System
System
System
System M
LIU-TEK-LIC-2006:66
Digital Media Division
Department of Science and Technology
Linköping University, SE-581 83 Linköping, Sweden
Norrköping 2006
Linköping Studies in Science and Technology
Thesis No. 1285
Integrating Systems in the

Print Production Workflow
Claes Buckwalter
Management
InformationSystem
System(MIS)
(MIS)
M M M
W W W
Prepress
Prepress W
Press
Press Binding
Binding
Workflow
Workflow Controller
Controller System
System
System
System M
LIU-TEK-LIC-2006:66
Digital Media Division
Linköping University, SE-581 83 Linköping, Sweden
Norrköping 2006
Integrating Systems in the Print Production Workflow
© Claes Buckwalter 2006

Campus Norrköping, Linköping University
SE-601 74 Norrköping, Sweden
ISBN 91-85643-26-2 ISSN 0280-7971
Printed by LiU-Tryck, Linköping, Sweden, 2006

Abstract
The print production workflow consists of various disparate systems—from production
equipment to management information systems. During the production of a printed
product, information regarding the product must be communicated between the
systems in the workflow. Job Definition Format (JDF) is an industry standard that
specifies this information interchange. It specifies a digital job ticket format for
exchanging administrative and technical information related to a print job, and a
messaging protocol for communicating information between the systems in the
workflow. This licentiate thesis explores different aspects of integrating systems in a
JDF-enabled print production workflow.
Paper III and Paper IV analyze the properties of JDF’s messaging protocol—Job
Messaging Format (JMF)—and discuss design solutions for a JMF integration layer.
Paper I presents a software tool for simulating systems in the print production
workflow. The tool is based on an open source software library, called the Elk
Framework, which has been developed within the framework of these licentiate studies.
The Elk Framework provides the base services required by a piece of JDF-enabled
production equipment, called a Device/Worker in JDF parlance.
Paper II presents a software tool that was developed for testing the simulation tool
presented in Paper I. The test tool, named Alces, can be used for testing if JDF-
enabled systems conform to the JDF Specification.
i
ii
Contents
LIST OF ENCLOSED PAPERS .................................................................................................................. V
RELATED WORK.....................................................................................................................................VII
LIST OF FIGURES ..................................................................................................................................... IX
PREFACE .................................................................................................................................................... XI
1 INTRODUCTION AND OVERVIEW ................................................................................................1
1.1 INTRODUCTION ................................................................................................................................................1
1.2 OVERVIEW .......................................................................................................................................................1
2 BACKGROUND .....................................................................................................................................3
2.1 PRINT PRODUCTION .......................................................................................................................................3
2.2 JOB TICKETS ......................................................................................................................................................4
2.3 JOB TRACKING .................................................................................................................................................5
3 JOB DEFINITION FORMAT (JDF) ...................................................................................................7
3.1 H ISTORY AND PRIOR INTEGRATION STANDARDS ...................................................................................7
3.2 THE CIP4 ORGANIZATION ...........................................................................................................................8
3.3 THE JDF SPECIFICATION AND ITS ANCILLARY S PECIFICATIONS ...........................................................9
4 THE JDF JOB TICKET FORMAT .....................................................................................................11
4.1 PRODUCT MODEL .........................................................................................................................................11
4.2 PROCESS MODEL ...........................................................................................................................................12
4.3 RESOURCE MODEL ........................................................................................................................................15
4.4 COMPARISON WITH OTHER WORKFLOW MODELS ................................................................................16
5 JDF-ENABLED WORKFLOWS AND THEIR SYSTEMS..............................................................19
5.1 WORKFLOW COMPONENT ROLES ..............................................................................................................19
5.2 SYSTEM INTEROPERABILITY ........................................................................................................................21
5.3 MIS M ANAGED PRODUCTION ...................................................................................................................23
6 JDF TOOLS...........................................................................................................................................25
6.1 JDFLIB .............................................................................................................................................................25
6.2 THE ELK FRAMEWORK .................................................................................................................................25
6.3 ALCES ...............................................................................................................................................................27
7 SUMMARY OF INCLUDED PAPERS..............................................................................................29
7.1 P APER I ...........................................................................................................................................................29
7.2 P APER II..........................................................................................................................................................29
7.3 P APER III.........................................................................................................................................................29
7.4 P APER IV ........................................................................................................................................................29
8 DISCUSSION........................................................................................................................................31
REFERENCES..............................................................................................................................................33
iii
iv
List of Enclosed Papers
i. A JDF-enabled Workflow Simulation Tool
TAGA 57th Annual Technical Conference 2005
Toronto, Ontario, Canada; April 17-20, 2005; p. 271-281
ii. A Tool for Testing Compliance with
CIP4’s Interoperability Conformance Specifications
2005 International Conference on
Digital Production Printing and Industrial Applications
Amsterdam, The Netherlands; May 9, 2005; p. 83-84; ISBN/ISSN 0-89208-256-9
iii. Integration Patterns Applied to Print Production
TAGA 58th Annual Technical Conference 2006
Vancouver, British Columbia, Canada; March 19-21, 2006; p. 54-68
iv. A Messaging-Based Integration Architecture for
Print Production Workflow Systems
Printing Technology SPb’06
Saint Petersburg, Russia; June 26-30, 2006; p. 13-17
v
vi
Related Work
i. The Elk Framework
An open source library written in Java that provides the generic infrastructure and
services needed by a JDF Device.
Documentation and source code: http://elk.itn.liu.se
ii. Alces
Alces is a tool for testing JDF software. Alces plays the role of a Manager and is
used for testing the JDF compliance of a Worker, such as a RIP, a printing press, or
a binding device.
Documentation and source code: http://elk.itn.liu.se/alces
vii
viii
List of Figures
Figure 2-1 Overview of the production flow in a printing plant ........................................3
Figure 2-2 A job ticket for specifying a job for a wide format printer...............................4
Figure 4-1 JDF job ticket tree structure..................................................................................12
Figure 4-2 Process network.......................................................................................................12
Figure 4-3 The ImageSetting process......................................................................................13
Figure 4-4 Gray Box for plate making....................................................................................14
Figure 4-5 Generic process/activity model ............................................................................17
Figure 5-1 Hierarchy of workflow components....................................................................20
Figure 5-2 ICS Stack...................................................................................................................21
Figure 5-3 Example of systems and ICSs...............................................................................22
Figure 5-4 Example of system roles ........................................................................................23
Figure 6-1 The Elk Framework.................................................................................................26
Figure 6-2 Interactive Alces testing the Elk ConventionalPrinting Device...................27
ix
x
Preface
When starting out, the focus of my licentiate studies was loosely specified as “studies
within the area of prepress, color management, and the graphic arts production process
in particular”. I had an idea that it would be interesting to specialize in technologies
for automating the print production process and integrating the various systems
involved in print production. I also knew that I found it stimulating to, and had bit of
a knack for, building software systems. Hopefully there would be a way for me to
combine these areas.
Before I started my licentiate studies, an emerging industry standard, named Job
Definition Format (JDF), that promised to integrate the systems in the print
production workflow, had caught my attention. Shortly after I had commenced my
licentiate studies, T2F1 gave me the opportunity to visit Drupa 2004, THE tradeshow
for everything related to print, held in Düsseldorf, Germany, every four years. I knew
that CIP42, the industry consortium that developed and maintained JDF, would be at
Drupa so I decided to contact them and discuss the possibility of collaborating.
Thanks largely to the marketing departments of the industry’s giants, Drupa 2004
become known as “the JDF Drupa”. Almost all vendors had “JDF” on their product
feature lists. In reality though, many products only had very rudimentary JDF support.
CIP4 was aware of this and welcomed contributions that could help speed up the
adaptation of JDF and increase the number of products with mature JDF
implementations. My proposal to create a reference implementation of a JDF-enabled
system was warmly welcomed.
From Drupa on, my licentiate studies have more or less centered around different
design approaches to an integration layer for JDF enabling systems, developing test
tools for testing JDF-enabled systems, and analyzing JDF from the perspective of
generic design patterns for system integration. If I were to attempt to put a label on
my work I would call it computer science applied to the graphic arts industry. My
licentiate studies have been an opportunity for me to be creative and use software as a
medium of expression to help solve interesting problems for an industry in
transformation.
My work on JDF and collaboration with CIP4 has been very rewarding. I have had the
honor of doing an internship under the supervision of CIP4’s chief technical officer
Dr. Rainer Prosi, in Kiel, Germany; I have had the opportunity to attend CIP4’s
technical interoperability conferences in Heidelberg, Pittsburgh, Strasbourg, Tokyo,
and Quebec; I have served as chairman of CIP4’s Tools & Infrastructure working
group; and I have had the pleasure of meeting a lot of intelligent and inspiring people
from all around the world.
1
Print Technology Research/TryckTeknisk Forskning, http://www.t2f.nu
2
The International Cooperation for the Integration of Processes in Prepress, Press and Postpress
Organization (CIP4), http://www.cip4.org
xi
I am grateful to all people who have supported me during my licentiate studies. In
particular, I would like to thank my supervisor professor Björn Kruse for his guidance
and pep-talks; my CIP4 colleagues for their valuable input and sharing; the
contributors to my open source projects, in particular Marco, Markus and Ola; my
colleagues at ITN for the “fika” breaks—hopefully the horrible coffee hasn’t done too
much permanent damage to our bodies; my family and friends for their support; and
my girlfriend Susanne for being there.
Finally, the financial support from T2F, CIP4, and ITN is gratefully acknowledged.
xii
1 Introduction and Overview
1.1 Introduction
A technical white paper or article on JDF typically starts with motivating the existence
of JDF by mentioning something about the printing industry suffering from shorter
run lengths and the need to optimize the print production workflow. This thesis will
not. Instead, it is assumed that the reader is already convinced of the need for JDF; or
if the reader is not convinced, simply that he has had to come to accept the fact that
JDF is an industry standard that has come to stay.
The reader who will probably find this thesis the most interesting is a software
developer, not necessarily with a background in developing software for the printing
industry, who is trying to get his head around the main concepts in JDF and is looking
for inspiration for design approaches for JDF-enabling his software.
1.2 Overview
This licentiate thesis consists of two parts. The purpose of the first part is to give the
reader the context in which the licentiate studies have been conducted. It gives a brief
overview of the history of system integration in the printing industry, and an
introduction to the industry standard Job Definition Format (JDF). Chapter 2 gives an
overview of print production and the information flows in a printing plant. In
Chapter 3, Job Definition Format (JDF) is introduced. Chapter 4 describes the
concepts behind JDF’s digital job ticket format, while chapter 5 describes the different
system roles in a JDF-enabled print production workflow. Chapter 6 presents two
software tools for building JDF-enabled systems that have been developed within the
framework of this licentiate thesis project—Alces and the Elk Framework. Chapter 7
provides a summary of the papers included in the second part of this thesis. Finally,
chapter 8 discusses the work presented in the papers and suggests future extensions of
the work.
The second part of this thesis consists of the four main papers published during these
licentiate studies. Paper I describes a JDF-enabled simulation tool based on the Elk
Framework. Paper II explains the motivation for and design principles behind Alces.
Paper III and Paper IV build on the experiences learned from the development of Elk
and Alces and discuss various approaches to implementing a software layer for JDF-
enabling systems in the print production workflow.
1
2
2 Background
Before delving into the details of Job Definition Format, this chapter provides an
introduction to print production, the information flows in a printing plant, and the
most important standards that preceded JDF.
2.1 Print Production

A printing plant is typically organized into three production departments: prepress,
press, and postpress. Overseeing these three departments is a fourth, management-
related, department that handles incoming customer orders, plans production,
manages inventory, and is responsible for other administrative tasks. Figure 2-1
provides an overview of the departments and the information flow between them.
Printing Plant
Management
Management
Information
Information
Systems
Systems (MIS)
(MIS)
Plates, Printed Printed

Customer, Originals etc sheets product
Customer,
agency,
agency, Prepress
Prepress Postpress
Postpress Press
Press Distributor
Distributor
publisher
publisher Data Data Data Data
Storage
Storage
Consumables
Supplier
Supplier
Figure 2-1 Overview of the production flow in a printing plant (inspired by

[Kipphan 2001, Figure 1.2-1])
A prepress department prepares customer source material for print. In terms of inputs
and outputs, the inputs to a prepress department are the customer’s specification of the
printed product and the customer’s source material, today almost exclusively in digital
form, such as PDF. Outputs are printing plates and configuration parameters for the
printing press.
A press department takes the output from the prepress department as input and
produces printed sheets of paper. The printed sheets are input to the postpress
department that cuts, gathers, folds, and binds them. The postpress department
outputs finished printed products.
Traditionally, the three production departments have been relatively isolated from
each other, with a minimum of information being communicated between them. The
communication between the production departments and the management
department, that in theory should have a holistic view of the whole printing plant and
up to date information about all customer orders currently in production, has been
even more non-existent. The only time information traveled between departments
3
was when one department handed off the printed product to another department in
the form of a job ticket.
2.2 Job Tickets

In the printing industry, the term print job, or job, is used to refer to a customer order
to produce a printed product. During the production of a job, a job ticket is sent
around the printing plant together with the printed product and is used to collect
technical and administrative information related to the job, such as product
specification, customer contact information, scheduling, and equipment
configuration parameters [Kipphan 2001, Section 1.9.2.2]. The arrows marked “Data”
in Figure 2-1 represent job tickets being transferred between the printing plants
departments.
Traditionally, the job ticket was a collection of papers (see Figure 2-2) in a folder. This
resulted in error-prone and time-consuming re-entering of information when a job
moved between systems. It also made it very difficult to overview the status of all jobs
in production since that required manually collecting and analyzing all job tickets.
Figure 2-2 A job ticket for specifying a job for a wide format printer
As computer-integrated manufacturing (CIM) started to make its way into print
production in the 1990s [Kipphan 2001, Section 1.2.5] and computer-controlled
production equipment became more common, job tickets were digitized.
4
A digital job ticket format is a data format for exchanging print job definitions, and
information related to the production of print jobs, between the various production
and management systems in a printing plant. Initially, the scope of the open digital
job ticket formats did not cover all aspects of print production and different vendors
in the printing industry developed their own proprietary digital job ticket formats.
Examples of three such formats are Portable Job Ticket Format (PJTF) [Adobe 1999],
Print Production Format (PPF) [Daun et al. 1998], and IfraTrack [Ifra 2002]—all of
which have influenced the development of JDF.
2.3 Job Tracking

In order to be able make well-grounded decisions related to production, the
management of a printing plant needs to have up-to-date information about all jobs
in production and be able to monitor the status of all systems in the printing plant.
This requires that there is some mechanism in place that allows for the management
information systems to track the progress of jobs through production and to monitor
the various production systems involved.
Certain sectors in the printing industry, such as catalog printing and packaging
printing, have early on adopted a view of their production as a manufacturing process,
as opposed to the craftsmanship view used by most of the printing industry. The
newspaper industry is another sector that was early to adopt production concepts from
the manufacturing industry.
The newspaper industry works under the pressure of tight schedules—each day a new
product must be produced and the deadlines met. Real-time updates from production
systems are crucial for providing an up-to-date view of the production status of a
newspaper. In 1994, IFRA3, an international newspaper association, published a
vendor-independent specification, IfraTrack, which defined how status and
management information should be exchanged between the systems in the newspaper
production workflow. The most recent version of the specification, IfraTrack 3.0, was
published in 2002 [Ifra 2002].
As commercial printing has evolved there has been an increasing demand for the same
level of job tracking and monitoring that has been available in the newspaper industry
for more than a decade.
3
Ifra, http://www.ifra.com
5
6
3 Job Definition Format (JDF)
Job Definition Format (JDF) is an industry standard that specifies how to integrate the
various heterogeneous systems in the print production workflow:
“JDF is an industry standard designed to simplify information exchange between
different applications and systems in and around the graphic arts industry.” [CIP4
2005b]
The JDF specification [CIP4 2005b] is essentially a middleware specification for the
printing industry. It specifies a job ticket format for exchanging administrative and
technical information related to a print job, and a messaging protocol for
communicating information between the various systems in the print production
workflow. In other words, the JDF Specification specifies what information systems
should exchange and how they should exchange it.
The JDF job ticket format allows the customer’s intent of the printed product to be
defined. It also allows the printing plant’s production view—what work steps are
required to produce the customer’s product—to be defined. Chapter 4 explains the
concepts behind JDF’s job ticket format without going into the details of how the
information is represented. For a complete description of the syntax of the JDF job
ticket format the reader is referred to the JDF specification [CIP4 2005b].
JDF’s messaging protocol—Job Messaging Format (JMF)—is used by the systems in
the print production workflow to communicate job tracking information; monitor the
various production systems, such as prepress equipment, printing presses, finishing
equipment; and to a certain extent, control the production systems. An overview and
analysis of JMF is given in Paper III and Paper IV. For a complete description, the
reader is referred to the JDF specification [CIP4 2005b].
3.1 History and Prior Integration Standards

JDF is not a first attempt at integrating the systems in the print production workflow,
but rather the best practices learned from previous attempts.
Portable Job Ticket Format (PJTF) was a proprietary job ticket format developed by
Adobe for exchanging processing instructions between systems in prepress. Another
important job ticket format that preceded JDF was Print Production Format (PPF)
[Daun et al. 1998], developed by an industry consortium named CIP34. PPF is used to
store and transfer information generated at different production steps in prepress,
press, and postpress. A typical usage example is to use PPF data (colloquially referred
to as “CIP3 data”) generated in prepress to configure the ink keys on a printing press.
The newspaper industry’s job tracking specification IfraTrack has also influenced the
development of JDF, particularly its messaging protocol Job Messaging Format (JMF),
used to monitor the systems on the plant floor and track print jobs in production.
It is mainly the models and concepts used by PPF, PJTF, and IfraTrack that have
influenced JDF. In many cases there are direct mappings between the data that can be
4
The International Cooperation for Integration of Prepress, Press, and Postpress (CIP3)
7
represented in PPF, PJTF, or IfraTrack to a representation in JDF. The structure,
syntax, and methods of exchanging data between systems used by preceding standards
are however not shared by JDF. Previous attempts used proprietary data formats that
required specialized programming tools, and largely relied on embedding metadata in
large content files, which required a lot of resources to process. JDF is based on a
generic data format named XML [W3C 2006] and data is exchanged between systems
using self-contained files and standard network protocols [Fielding et al. 1999].
The first draft of JDF (officially named JDF 1.0) was developed by a group consisting
of Adobe5, Heidelberg6, Agfa7, and MAN Roland8. In 2001 the group handed over the
draft of JDF to CIP4, which in 2000 had been formed out of CIP3. The first version of
JDF that could actually be implemented was JDF 1.1, published in 2002. JDF 1.2 was
presented at Drupa9 2004 and received a lot of attention in the media thanks to
effective marketing from CIP4 and its member organizations. At the time of writing
JDF has reached version 1.3.
3.2 The CIP4 Organization

JDF is developed and maintained by an industry consortium named CIP4—The
International Cooperation for the Integration of Processes in Prepress, Press and
Postpress Organization. CIP4 publishes the JDF specification [CIP4 2005b] and
develops a number of tools that can be used for building systems that use JDF.
CIP4 is an open organization where all members are welcome to actively participate.
The organization’s web site [CIP4] acts as a hub through which all members
communicate and where all information produced by the organization is collected.
CIP4’s work is conducted in working groups that specialize in different areas of the
print production workflow, for example prepress, flexography printing, digital
printing, or binding. It is mostly vendors that develop products for a specific area of
the print production workflow that contribute to the corresponding CIP4 working
group. Each working group normally meets every other week using a web-based phone
conference system.
The working groups suggest changes to the JDF specification and submit them to
CIP4’s Technical Steering Committee (TSC) who decides what should be included in
the next version of the JDF specification. The TSC consists of the chairmen of the
working groups.
Twice a year a one-week technical interoperability conference—“interop” for short—is
hosted by one of CIP4’s member organization. The purpose of an interop is for CIP4’s
members to meet to test the interoperability of their JDF-enabled systems, and to have
5
Adobe Systems Incorporated, http://www.adobe.com
6
Heidelberger Druckmaschinen AG, http://www.heidelberg.com
7
Agfa-Gevaert Group, http://www.agfa.com
8
MAN Roland Druckmaschinen AG, http://www.man-roland.com
9
Drupa, http://www.drupa.com
8
face-to-face working group meetings. The atmosphere at CIP4’s interops is very
informal; it is a perfect opportunity for developers to meet peers and exchange
experiences related to implementing JDF.
3.3 The JDF Specification and its Ancillary Specifications

The JDF specification describes the structure and syntax of the JDF job ticket format,
the syntax of Job Messaging Format (JMF), the roles of the systems in a JDF-enabled
workflow, the routing of jobs through the workflow, the execution of jobs, etc.
Although the 900 page JDF specification provides a complete specification of the
different constructs available for defining a print job and how it is to be produced, the
specification often allows for more than one way of describing a certain aspect of a
print job. This leads to different implementations of the JDF specification providing
the same functionality but in different ways, thus hampering interoperability between
systems.
To alleviate this problem CIP4 provides a collection of ancillary specifications called
Interoperability Conformance Specifications (ICS). These specifications specify subsets
of the JDF specification that are to be used when two systems in a specific sector of the
print production workflow exchange information. For example, there is an ICS that
defines the minimum subset of the JDF job ticket format that a prepress system must
use when sending a job to an offset printing press [CIP4 2005a]. When implementing
a JDF-enabled system a developer should always start by identifying what ICSs the
system must comply with.
All published ICS documents are publicly available on CIP4’s web site [CIP4 2006e].
Section 5.2 provides a more detailed description of the ICS documents and system
interoperability.
9
10
4 The JDF Job Ticket Format
The JDF job ticket format uses a hierarchical tree structure to describe a print job. The
structure is very similar to a Work Breakdown Structure (WBS) [Haugan 2001] with
deliverables and tasks, going from general to specific. At the root of the tree is a
specification of the printed product to produce—product definition. At the leaves of
the tree are definitions of the activities required to produce the printed product—
process definitions.
The JDF job ticket format is based on XML [W3C 2006] and uses XML Schema [W3C
2004] to describe its syntax and structure. Extensible Markup Language (XML) is a
general syntax for specifying markup languages. The advantage of XML is that there
are widely available tools and programming libraries for processing any markup
language that uses XML syntax. This has made XML the de facto data exchange
format for text-based information, and is why JDF’s job ticket format is encoded in
XML.
We now leave XML and instead focus on the print job model of the JDF job ticket
format from a higher level, explaining the main concepts behind the model, not how
it is represented in XML.
4.1 Product Model

As mentioned above, the JDF job ticket format models a print job as a tree of
JDF nodes. In the general case, the root JDF node of the tree is a product node that
represents a specification of the printed product that the customer wants produced—
the customer’s intent of the product. If the product can be divided into sub-parts that
can be given separate but more specific specifications, these sub-parts are represented
as product nodes that are children of the root product node. All product nodes in the
tree can be recursively divided into sub-parts represented by child product nodes.
The number of levels of product nodes, i.e. the level of granularity of the product
specification, depends on the product. In commercial printing a job usually has two
levels of product nodes. For example, a customer may want to print a book. The root
product node may specify that 500 copies of a book should be printed, that the spine
should be glued, and that the finished books should be delivered to a certain address.
The root product node has two child product nodes. One child node specifies the
media that should be used for the cover, and that the cover should be printed in color;
the other child node specifies the media that should be used for the body of the book,
and that the body should be printed in black and white. Figure 4-1 shows a possible job
structure for a book job taken from an example in the JDF Specification [CIP4 2005b,
Section 2.2.1]. Nodes 1, 2, and 3 are product nodes.
11
Figure 4-1 JDF job ticket tree structure [CIP4 2005b, Figure 2-2]
4.2 Process Model

The tree structure of the JDF job ticket format describes, from top to bottom,
deliverables and the work steps required to produce the deliverables. Deliverables are
represented by product nodes. The work steps required to produce a product node are
represented by three different types of JDF nodes: process nodes, combined process
nodes, process group nodes. The sections that follow describe these three node types in
bottom-up order.
4.2.1 Process Nodes

A process node is always a leaf in a job tree and defines the most fine-grained work
step (activity) that can be modeled in JDF. The JDF process model is based on the
producer-consumer model—a process consumes input resources and produces output
resources.
Process Resource
Figure 4-2 Process network

Processes are linked together by their input and output resources. A process can start
execution as soon as all, or an adequate subset, of its input resources become available.
During process execution input resources are consumed, transformed, or combined to
produce output resources. The output resources of one process are the input resources
of one or more other processes. As Figure 4-2 illustrates, the linking of processes using
resources creates a network of processes allowing serial, parallel, overlapping, and
iterative processing to be modeled [CIP4 2005b, Section 4.3; Enlund 1998].
12
?
ColorantControl
ColorantControl
?
DevelopingParams
DevelopingParams
?
ExposedMedia
ExposedMedia
?
ImageSettingParams
ImageSettingParams ImageSetting ExposedMedia
ExposedMedia
Media
Media
RunList
RunList
?
TransferCurvePool
TransferCurvePool
Figure 4-3 The ImageSetting process

The current version of the JDF specification defines more than 90 processes and more
than 190 resources that can be used as input or output resources to the processes; most
of these are related to prepress and postpress. Figure 4-3 shows the JDF process
ImageSetting [CIP4 2005b, Section 6.4.14], and its input and output resources. Image
setting is a prepress process that exposes a bitmap image on to a film or a plate. The
process is typically performed by a device called an imagesetter [Kipphan 2001,
Section 3.2.12.1].
4.2.2 Combined Process Nodes

A combined process node is a leaf node used for defining several processes that are
executed as one atomic process by a single system. For example, a digital printing
system typically interprets page descriptions and instructions, renders pages, and then
prints the rendered pages on paper. The Integrated Digital Printing ICS [CIP4 2006b]
requires that conforming digital printing systems be able to execute a combined
process node consisting of the following JDF processes: LayoutPreparation,
Imposition, Interpreting, Rendering, and DigitalPrinting.
Before a combined process can execute, all input resources that provide parameters for
its internal process must be defined and available. Intermediate resources produced
and consumed by the combined process’s internal processes do not need to be defined.
4.2.3 Process Group Nodes

A process group node is used to create logical groupings of process nodes, for example
grouping together processes in prepress, press, and postpress groups, see Figure 4-1.
This allows a system to provide an abstract declaration of a group of processes without
defining all the child process nodes. A process group node can also be used to define
resources that are used by its descendant nodes, thus removing redundancy. Child
nodes of a process group node can be process nodes, combined process nodes or
process group nodes.
13
4.2.4 Gray Boxes
A special case of process group node is a Gray Box. A Gray Box is used to specify an
ordered process chain consisting of a minimum set of processes, and the input and
output resources of the process chain. This allows a sequence of processes to be defined
without needing to define all intermediate processes or resources.
ColorantControl
ColorantControl
?
Device
Device
?
InterpretingParams
InterpretingParams ExposedMedia
ExposedMedia
Layout
PlateMaking Preview
Layout Preview (Separation)
(Separation)
Gray Box
?
Media
Media Preview
Preview (Thumbnail)
(Thumbnail)
RunList
RunList (Document)
(Document)
RunList
RunList (Marks)
(Marks)
Figure 4-4 Gray Box for plate making

Gray Boxes were first developed for communication between MIS and prepress
workflow systems [CIP4 2006g, Section 2]. MIS systems usually do not have
knowledge about all production details and often write Gray Boxes instead of explicit
process definitions to a JDF job ticket. When a production system receives a JDF job
ticket with a Gray Box that it can interpret it “expands” the Gray Box by adding
process nodes to the Gray Box process group, linking the processes as necessary. The
algorithm for Gray Box expansion is defined in [CIP4 2005b, Section 3.2.2.1].
To summarize, Gray Boxes provide a way of defining a sequence of processes without
needing to have detailed knowledge of all the processes and their resources.
14
4.3 Resource Model
In JDF, resources represent the “things” that are the inputs and outputs of processes.
Resources are what link processes together to create the network of processes, see
Figure 4-2, that represent the workflow for producing a print job.
During the production of a print job, the resources used go through a number of state
changes. For example, when a resource is ready for consumption by a process it
changes state to Available; when a resource is in use by a process it has the state InUse.
The resources’ states determine when a process can be executed.
4.3.1 Resource Classes

There are five main classes of resources: parameter resources, physical resources, intent
resources, implementation resources, and placeholder resources.
Parameter resources are configuration parameters or input data, such as files, for a
process. For example, ImageSettingParams is a parameter resource used to configure an
imagesetter, see Figure 4-3.
Physical resources are divided into three sub-classes: consumable resources, quantity
resources, and handling resources. Consumable resources are consumed by processes;
for example, Ink and Media resources are consumed during printing. A consumable
resource can be used to create a quantity resource. Quantity resources are semi-finished
goods, such as printed sheets from a printing press. Handling resources are resources
that are used by a process but not destroyed during the execution of a process; for
example, plates (ExposedMedia) for a printing press.
Intent resources are used together with product intent JDF nodes (see Section 4.1) to
specify various aspects of the printed product to produce. For example, the intent
resource MediaIntent can be used to specify the characteristics of the paper the product
should be printed on.
Implementation resources define the equipment and personnel needed to execute a
process. There are only two resources of this class: Employee and Device.
Placeholder resources are used as temporary stand-ins for other resources. They are
used when the actual resource produced or consumed by a process group (see
Section 4.2.3) is unknown.
4.3.2 Partitioning of Resources

In a similar way to the product and process models, the resource model of JDF is also
hierarchical. Resources of the same type can share properties by having the properties
factored out and placed in a parent resource. Child resources can then inherit the
parent’s properties or choose to override them. This hierarchical grouping of resources
of the same type is called partitioning.
Partitioning is used to minimize the number of resources and process nodes used to
describe how to produce a print job. For example, the ImageSetting process (see Figure
4-3) is used to produce a printing plate, represented in JDF by the ExposedMedia
resource. If four printing plates were to be produced (one for each separation cyan,
15
magenta, yellow, and black) for one side of a sheet, one alternative would be to have
four ImageSetting processes, each one outputting one ExposedMedia resource. Instead,
the recommended alternative is to define one ImageSetting process that outputs one
partitioned ExposedMedia resource. The resource’s partitions are four ExposedMedia
resources, one for each printing plate. Each partition inherits all properties
(represented by XML attributes and child elements) defined in the parent resource.
4.3.3 Resource Linking

Resources connect processes and determine the sequence of processes that will be
executed in order to produce a printed product.
The resources required to produce a product are defined in so-called resource pools that
are associated with each JDF node in a job tree. A JDF node can use any resource
defined in its own resource pool and the resource pools of its ancestor JDF nodes.
Resource pools are only used to house the definitions of resources. The linking of input
and output resources to a JDF process node, process group node, or combined process
node is defined using resource links in the JDF node’s resource link pool. A resource
link references a resource defined in a resource pool and specifies if the resource should
be used as input or output to the JDF node. Several JDF nodes can link to the same
resource; for example, one process produces a resource as an output and another
process uses the resource as an input.
As mentioned in Section 4.3.2 above, resources are hierarchical and can be divided
into partitions. Resource links can refer to a specific partition of a resource, for
example a specific printing plate.
Physical resources (Section 4.3.1) exist in amounts, such as a stack containing 1000
sheets of paper. A resource link can reference a specific amount of a physical resource.
This allows a process to produce a resource while one or more other processes consume
the same resource. This is called overlapping processing and the resource linking
mechanism used is called a pipe. [CIP4 2005b, Section 4.3.3] gives a detailed
description of overlapping processing and pipes.
4.4 Comparison with other Workflow Models

An excellent but somewhat dated overview of workflow management in the graphic
arts and printing industry is given in [Enlund 1998]. The paper concludes by
suggesting a merge of CIP3’s and IFRA’s standards—something that today has been
realized in the form of JDF.
As indicated above, the print production workflow is resource driven. The different
activities required to produce a printed product depend on the availability of resources.
A printing plate cannot be created until the pages used for the plate are available; the
press cannot start printing before the plates are ready; the printed product cannot be
bound before all pages have been printed.
Modeling print production with generic workflow models or using more low-level
theoretical models is in some cases not possible or becomes overly complex [Tuijn
16
2004]. In particular, overlapping processing with partially produced objects/resources is
difficult to model.
The resource model used by JDF considers all “things” needed to execute a process as
resources. Generic workflow models such as the Workflow Management Coalition’s
(WfMC) [WfMC 1999] typically differentiate between objects and resources, see
Figure 4-5. “Objects” are the inputs and outputs of a process, while “resources”
correspond to JDF’s implementation resources—the equipment and personnel
required to execute a process. An example of a model from the printing industry that
also separates objects and resources is the newspaper-manufacturing model described
in [Nordqvist 1996].
Resources
Resources
Input
Input Output
Output
Activity
Activity
objects
objects objects
objects
Figure 4-5 Generic process/activity model
17
18
5 JDF-enabled Workflows and their Systems
5.1 Workflow Component Roles
A printing plant’s production workflow consists of various systems, from
management information systems to production equipment in prepress, press, and
postpress. The JDF Specification [CIP4 2005b] refers to these systems as workflow
components and arranges them in a hierarchy. Each system in this model is classified as
having one or more of the following workflow component roles:
5.1.1 Agent
An Agent is a system that writes JDF instances. Most JDF-enabled systems update or
add information to the JDF instances they process, and are therefore Agents.
5.1.2 Controller
A Controller interprets JDF instances, optionally adds specific information known by
the Controller, and then routes the JDF instances to other systems for further
processing. A Controller may split a JDF instance into several parts and route each
part to a different system for processing—spawning. A Controller may also merge
several JDF instances and send the new JDF instance for processing—merging.
In the JDF workflow system hierarchy, Controllers are located at the top levels of the
hierarchy (Figure 5-1). The JDF Specification implies that there is a single monolithic
controller at the root level of the hierarchy in the form of a Management Information
System (MIS), see Section 5.1.5. Typically, there are two levels of Controllers in the
hierarchy: an MIS at the root level, and several sector specific Controllers, such as a
prepress workflow system, at the level below.
5.1.3 Device
A Device is a system that receives JDF instances, and executes the processes specified
by one or more of the process nodes or combined process nodes in the JDF instance.
An example of a Device is a JDF-enabled front-end for a digital printing press. The
front-end receives JDF instances, interprets the relevant process nodes, and sends
proprietary control commands to the digital printing press hardware.
5.1.4 Machine
A Machine is a system that receives proprietary control commands from a Device and
does not know anything about JDF. In the Device example above, the digital printing
press would be a Machine.
19
Figure 5-1 Hierarchy of workflow components ([CIP4 2005b], Figure 2-1)
5.1.5 Management Information Systems

A very important concept in a JDF-enabled workflow is the Management Information
System (MIS). The JDF Specification defines an MIS as: “the overseer of the
relationships between all of the units in a workflow … in effect, a macrocosmic
controller. It is responsible for dictating and monitoring the execution of all of the
diverse aspects of the workflow.”
Different MISs vary in complexity and feature set. An MIS normally has some or all
of the following functionality [Bellander et al. 1999]:
• Estimating & quoting • Job history
• Scheduling • Standardized reports
• Order entry & job tracking • Receivables
• Raw material inventory • Payables
• Shop floor data collection • General ledger & financials
• Invoicing & receivables
The JDF Specification and the ICS documents tend to describe an MIS is a single
monolithic system. However, there could be several separate systems in a printing
plant that provide different types of, or overlapping, management information
system functionality. These systems go under different names [Handberg 2003], such
as Production Management System (PMS) or Manufacturing Planning and Control
(MPC) system. For the sake of simplicity, we will here adhere to the MIS view used by
the JDF Specification and refer to the MIS as a single system.
The MIS concept used in [CIP4 2005b] in many aspects overlaps the Global
Production Management System (GPMS) described by [Nordqvist 1996].
20
5.2 System Interoperability
The JDF Specification defines a hierarchical relationship between Controllers and
Devices, a messaging protocol for communicating between the systems, and a job
ticket file format for exchanging production data. However, it would be unrealistic to
require that all systems in a JDF-enabled environment implement the entire JDF
Specification. An MIS needs to have more complex JDF/JMF processing capabilities
than an imagesetter; an offset printing press controller only needs to know how to
execute JDF process nodes of type ConventionalPrinting; a folding machine only
needs to know how to execute JDF process nodes of type Folding. Depending on in
what sector of the workflow a system is located, and what it does, it will implement a
certain subset of the JDF Specification.
If vendors would choose to implement arbitrary subsets of the 900 pages thick JDF
Specification it is unlikely that their systems would be interoperable. To alleviate this,
CIP4 provides a set of Interoperability Conformance Specification [CIP4 2006e]
documents that specify the minimum requirements placed on systems in different
sectors of the workflow [CIP4 2006a]: “Each ICS defines a set of conformance
requirements that a conforming JDF-enabled product must meet in order to achieve
interoperability with other conforming JDF-enabled products.”
All ICSs build on the Base ICS [CIP4 2006a]. It extends on the JDF Specification and
specifies the minimum level of JDF and JMF functionality that any JDF-enabled
system must have—what values in JDF job tickets and JMF messages a system must
read and write, and what JMF messages a system must be able to send and receive.
ICS
ICS
Conventional
PrepressICS
PrintingICS
MIStotoConventional
Conventional
ICS
ICS
Conventional
ICS
Prepresstoto
PrintingICS
PrintingICS
BindingICS
MIStotoPrepress
DigitalPrinting
Creatortoto
ICS
Prepress
ImpositionICS
LayoutCreator
Printing
Printing
Binding
Imposition
IntegratedDigital
MIS
MIS
Layout
Integrated
MIS
MISICS
ICS
Base
BaseICS
ICS
JDF
JDF1.2
1.2
Figure 5-2 ICS Stack

The other ICSs extend the Base ICS as illustrated in Figure 5-2. They define
conformance requirements for specific pairs of systems that interoperate in a specific
context. For example, an MIS and a prepress system that communicate must
implement the MIS to Prepress ICS [CIP4 2006g].
21
5.2.1 System Roles and Interfaces
When a system conforms to an ICS it conforms to the ICS in the capacity of one of
two roles—Manager or Worker—defined in the Base ICS [CIP4 2006a]. As mentioned
earlier, there is a hierarchical relationship between the systems in a JDF-enabled
environment. A system that is a Controller and delegates work to other system splays
the role of Manager, while the systems that do the work are Workers.
The MIS to Prepress ICS [CIP4 2006g] specifies conformance requirements for the
communication between MIS systems and systems in prepress. The ICS specifies that
the MIS is the Manager and the prepress system is the Worker.
A JDF-enabled system may conform to multiple ICSs and may play the role of both
Manager and Worker. A prepress workflow system is a typical example. A prepress
workflow system conforming to the MIS to Prepress ICS plays the role of a Worker—
it receives gray boxes from a MIS (Manager). However, in the context of the Prepress
to Conventional Printing ICS [CIP4 2005a] the same prepress workflow system is a
Manager—it notifies a press controller (Worker) about the availability of plates,
previews, or other resources.
Legend
Management
InformationSystem
System(MIS)
(MIS) Worker
W
Interface
MIS to Prepress ICS MIS to Conventional Printing ICS Binding ICS

Worker
Worker
M M M
W W W
Manager
M
Interface
Prepress
Prepress W
Workflow
Workflow Press
PressController
Controller Binding
BindingSystem
System Manager
Manager
System
System M
Prepress to
Conventional Printing ICS
Figure 5-3 Example of systems and ICSs

In ICS parlance, a Manager implements a Manager Interface, and a Worker
implements a Worker Interface. A Manager communicates with a Worker through the
Worker’s Worker Interface; and the Worker communicates with the Manager through
the Manager’s Manager Interface. However, the wording in [CIP4 2006a, Section
A.2], where these concepts are defined, is extremely confusing. Hopefully the
interpretation that follows, illustrated as a UML component diagram in Figure 5-3, is
more clear: when a Worker communicates with the Manager it talks to the Manager’s
Manager Interface; when a Manager talks to a Worker it talks to the Worker’s Worker
Interface.
Figure 5-4 shows a more detailed hierarchy of systems, showing the Manager and
Worker roles used in the ICSs, plus the workflow component roles defined by the JDF
Specification and described in Section 5.1 above.
22
Management
InformationSystem
System(MIS)
(MIS)
JDF
JDFWorkflow
WorkflowComponent
ComponentRoles:
Roles:Controller,
Controller,Agent
Agent
MIS
MIStotoPrepress
PrepressICS
ICSRole:
Role:Manager
Manager
MIS
MIStotoConventional
ConventionalPrinting
PrintingICS
ICSRole:
Role:Manager
Manager
MIS to Prepress ICS MIS to Conventional Printing ICS
M M
W Prepress to W
Conventional Printing ICS
Prepress
PrepressWorkflow
WorkflowSystem
System W Press
PressController
Controller
JDF
JDFWorkflow
WorkflowComponent
ComponentRoles:
Roles:Controller,
Controller,Agent
Agent JDF
JDFWorkflow
WorkflowComponent
ComponentRoles:
Roles:Device,
Device,Agent
Agent
MIS
MIStotoPrepress
PrepressICS
ICSRole:
Role:Worker
Worker MIS
MIStotoConventional
PrintingICS
ICSRole:
Role:Worker
Worker
M
Prepress
PrepresstotoConventional
PrintingICS
ICSRole:
Role:Manager
Manager Prepress
PrepresstotoConventional
PrintingICS
ICSRole:
Role:Worker
Worker
Proprietary Communication
Printing
PrintingPress
Press
JDF
JDFWorkflow
WorkflowComponent
ComponentRoles:
Roles:Machine
Machine
Figure 5-4 Example of system roles
5.3 MIS Managed Production

The MIS plays a central role in JDF. The concept of a MIS-managed printing plant is
implied in the JDF Specification, and the MIS-related ICS documents explicitly
describe such an environment—this is the concept that is the foundation for the MIS
ICS [CIP4 2006f]: “This ICS describes the data flow in a print shop in a MIS-managed
environment. However, this data flow does not necessarily also apply to non-MIS-
managed environments.”
In a MIS-managed printing plant the MIS is located between the customer and the
production systems on the shop floor. Customers deliver product intent in the form of
JDF instances with JDF product intent nodes to the MIS. The MIS has the
information necessary to map the product intent to a high-level description of the
workflow required to produce the product.
In the cases where an MIS has detailed knowledge about a process and the capabilities
of the system that will execute the process, the MIS appends JDF process nodes to the
JDF product intent nodes. However, in many cases the MIS does not have detailed
knowledge about all the processes and systems required to produce a product. Instead,
the MIS uses a special kind of JDF process group nodes called gray boxes [CIP4 2006f]
to provide an abstract definition of a group of the processes. This is common when an
MIS specifies the prepress workflow for a product. Rather than specifying all the
prepress processes required, the MIS specifies a prepress gray box and then delegates
the JDF instance to a prepress workflow system. The prepress workflow system has
detailed knowledge of all the systems available in the printing plant’s prepress
department and can expand the gray box into detailed process definitions. The MIS to
Prepress ICS [CIP4 2006g] defines the gray boxes that the MIS creates and that are
expanded by the prepress workflow system.
23
24
6 JDF Tools
The Tools & Infrastructure working group of CIP4 is responsible for developing and
maintaining a number of JDF software libraries and tools for the organization’s
members. The CIP4 software is distributed under an open source license [CIP4 2006c]
and is available for download from CIP4’s web site [CIP4 2006d]. CIP4’s members
may free of charge use the CIP4 software libraries, or parts thereof, in their commercial
products.
6.1 JDFLib
The core software library that all of CIP4’s JDF tools are based on is JDFLib—an
application programming interface (API) for creating, reading, and manipulating JDF
job tickets and JMF messages.
JDFLib is available for the Java programming language and for the C++ programming
language. The Java version of the library, JDFLib-J, is where CIP4 first implements
new features before porting them to the C++ library, JDFLib-C. Both JDFLib-J and
JDFLib-C are used in several vendors’ JDF-enabled products.
The other JDF tools developed by CIP4 are based on JDFLib-J. One of these tools is
the JDF Editor [Andersson 2003; Thunell 2003], a visual editor for editing and
visualizing JDF job ticket files and JMF message files. The JDF Editor can also be used
to convert files between different JDF versions, and to validate that files adhere to the
JDF specification.
Two of CIP4’s JDF tools have been developed in collaboration the Digital Media
Division at ITN, Linköping University, Sweden10: the Elk Framework and Alces.
6.2 The Elk Framework

The Elk Framework, colloquially referred to as Elk, is a software library written in Java
that provides the infrastructure and services need by a JDF Device—a Worker (see
Section 5.1.3 and 5.2.1). Using the Elk Framework, vendor’s can focus on
implementing the code that realizes the actual process in their Device and not worry
about the generic JDF-functionality needed by all devices, such as a JMF messaging, a
job queue, etc.
Elk consists of two parts: an API that defines the programming interfaces for
accessing the Device services; and a reference implementation of the services defined
by the API. The intention is that vendors can either use the default reference
implementations of the Device services defined by the API, or plug in their own
implementations of the services.
10
Digital Media Division, ITN, Linköping University, Sweden, http://media.itn.liu.se
25
JMF Messages
JDF Instances
Device
Incoming
Incoming
Messaging
Messaging
Gateway
Gateway
Message
QueueStatus
QueueStatus
Message Processors
Processor
Processors
Processor
Message Processors
State Changes State Changes
Poll for
new job Subscription
Job
JobQueue
Queue Process
Process
Subscription
Manager
Manager
Outgoing
Outgoing
Messaging
Messaging
Gateway
Gateway
JMF Messages
JDF Instances
Figure 6-1 The Elk Framework
Figure 6-1 shows the components that represent the most important services provided
by Elk, and the interactions between the components. The Process component
marked in bold represents the JDF process that the Device implements. This is the
component that a vendor would implement. For example, a vendor could use Elk as a
front-end to JDF-enable their digital printing press. Ideally, the vendor would only
have to implement the process component, which would interpret JDF job tickets and
call the vendor’s proprietary APIs that control the digital printing press’s hardware.
Elk’s reference implementation includes two Elk process components that implement
simulated JDF processes: one component implements the JDF Approval process; and
one implements the JDF ConventionalPrinting process. The simulated processes are
intended for demonstrating the Elk Framework and for testing JDF-enabled systems
that play the Manager role.
A more detailed description of the Elk Framework and the services it provides are
given in Paper I. Extensive documentation, the library binaries, and the source code
are available at the project web site [Buckwalter 2005a].
26
6.3 Alces
During the development of the Elk Framework a tool for testing the JMF messaging
functionality of the Elk reference implementation was needed. This led to the
development of the test tool Alces.
Alces plays the role of Manager (see Section 5.2.1). Using Alces, the JMF messaging
functionality of a system can be tested, although Alces was originally designed for
testing JDF Devices. Alces connects to a Device and can then send JMF messages to
or receive JMF messages from the Device. Tests are applied to all JMF messages sent
and received. Developers are encouraged to write new tests for Alces.
Alces software architecture consists of a core module that provides the infrastructure
for JDF messaging and the test framework. On top of the core module two different
versions of Alces are built: Interactive Alces and Automated Alces. Interactive Alces
has a graphical user interface that allows a user to manually test a Device. Figure 6-2
shows a screenshot of Interactive Alces’ user interface.
Figure 6-2 Interactive Alces testing the Elk ConventionalPrinting Device

Automated Alces is run from a command line and automatically sends a sequence of
JMF messages specified by the user. When the tests are finished running a log file
containing the test results is written. On use case for Automated Alces is in quality
assurance: a continuous integration tool [Almagro and Julius 2002] could build and
deploy a new version of a Device each time its source code is updated, and then
automatically test the Device by running Automated Alces. CIP4 uses a similar
approach for testing Elk and its other JDF tools.
Alces is described in more detail in Paper II. The source code and binaries are available
for download from the project web site [Buckwalter 2005b].
27
28
7 Summary of Included Papers
7.1 Paper I
A JDF-enabled Workflow Simulation Tool
Paper I describes how a system based on the Elk Framework can be used for simulating
an arbitrary process in a JDF-enabled print production workflow. A description of the
Elk Framework’s architecture and core components is given, and a first prototype of a
simulated process is presented.
7.2 Paper II
A Tool for Testing Compliance with CIP4’s Interoperability Conformance
Specifications
During the development of the Elk Framework it was realized that a tool was needed
for testing the framework’s compliance with the JDF and ICS specifications. This led
to the development of the test tool—later named Alces—presented in Paper II.
7.3 Paper III

Integration Patterns Applied to Print Production
The Elk Framework presented in Paper I and the test tool Alces presented in Paper II
both communicate with other systems using Job Definition Format’s messaging
protocol Job Messaging Format (JMF). This paper analyzes JMF and the different
types of system interactions that it supports. The result is the concepts found in JMF
expressed using the patterns found in two pattern languages for system integration.
7.4 Paper IV
A Messaging-Based Integration Architecture for Print Production Workflow Systems
The Elk Framework (Paper I) and Alces (Paper II) use different design approaches for
the software layer that handles JMF communication with other systems. Elk’s design is
biased towards handling incoming communication while Alces’ design is biased
towards handling outgoing communication. Paper IV builds on the experiences
gained from developing Elk and Alces and uses the system integration patterns of
JMF identified in Paper III to present a more flexible JMF integration layer that
handles both incoming and outgoing JMF communication equally well.
29
30
8 Discussion
The licentiate studies documented in the form of this thesis have focused on different
aspects of integrating the disparate systems in the print production workflow—from
production equipment to management information systems—using software. The
design approaches presented have been based on the industry standard Job Definition
Format (JDF), which specifies a digital job ticket format for exchanging administrative
and technical information related to a print job and a messaging protocol for
communicating information between the systems in the workflow.
One concrete result of these studies is the Elk Framework [Buckwalter 2005a], an open
source software library that provides the services needed by JDF-enabled production
equipment. Programmers developing a piece of JDF-enabled production equipment,
in JDF parlance a Device/Worker, can leverage the generic JDF functionality provided
by the Elk Framework and instead focus on developing the core functionality of their
system. At the time of writing, one commercial product under development is known
to be based on the Elk Framework. The product is a JDF-enabled front-end for a
digital printing system.
Besides generic JDF functionality, the Elk Framework includes two simulated JDF
processes, described in Paper I and [Stering 2006]. These act as reference systems for
programmers developing Devices. CIP4’s product certification working group and
several CIP4 members use the simulation-based Elk Devices for testing purposes. For
example, one vendor uses the simulation-based Elk Devices for testing the JDF
functionality of their prepress workflow system.
Another result of these licentiate studies is a test tool named Alces [Buckwalter 2005b].
Originally developed for testing the Elk Framework, Alces can be used for testing the
JMF messaging functionality of any Device/Worker. Alces is used by several CIP4 for
testing their systems.
The Elk Framework and Alces represent two opposing system roles in the JDF
workflow model: Alces takes on the role of a Manager; Elk takes on the role of a
Worker. Elk and Alces each contain an integration layer for JMF messaging. These
JMF integration layers use different architectural designs biased towards the
requirements of the different system roles Elk and Alces play. A possible continuation
of the work presented in this thesis would be to design a new JMF integration layer,
equally suitable for both Manager and Worker systems. Papers III and IV provide a
starting point for such work.
31
32
References
Adobe. 1999. Technical Note #5620, Portable Job Ticket Format – Version 1.1. Adobe
Systems Incorporated.
Almagro, Alden, and Paul Julius. 2002. CruiseControl – continuous integration
toolkit. http://cruisecontrol.sourceforge.net. Accessed 2006-10-26.
Andersson, Anna. 2003. The CIP4 JDF Editor, the Editing Part.
http://www.cip4.org/documents/jdf_overview/MasterProject_Anna_Andersson.pdf.
Accessed 2006-10-25.
Bellander, Mats, Leif Handberg, and Panagiota Koulouvari. 1999. Identifying
requirements for the implementation of production management systems in graphic
arts companies. TAGA 51th Annual Conference 51, 36-54.
Buckwalter, Claes. 2005b. Alces. http://elk.itn.liu.se/alces. Accessed 2006-10-26.
Buckwalter, Claes. 2005a. The Elk Framework. http://elk.itn.liu.se. Accessed 2006-10-
25.
CIP4. CIP4 Website. http://www.cip4.org. Accessed 2006-10-24.
CIP4. 2004. MIS Base ICS – Application Notes, Version 0.5 beta.
http://www.cip4.org/documents/jdf_specifications/MIS_APPNOTE_Beta_0_5.pdf.
CIP4. 2005b. JDF Specification, Release 1.3. http://www.cip4.org. Accessed 2006-10-
31.
CIP4. 2005a. Prepress to Conventional Printing ICS.
http://www.cip4.org/document_archive/documents/ICS-PRECP-1.0.pdf. Accessed
2006-10-31.
CIP4. 2005c. MIS to Conventional Printing – Sheet-Fed ICS, Version 1.0.
http://www.cip4.org/document_archive/documents/ICS-MISCPS-1.0.pdf. Accessed
2006-10-31.
CIP4. 2006e. Interoperability Conformance Specifications (ICS) Registry.
http://www.cip4.org/document_archive/ics.php. Accessed 2006-10-31.
CIP4. 2006d. JDF Open Source Software.
http://www.cip4.org/open_source/index.html. Accessed 2006-10-25.
CIP4. 2006g. MIS to Prepress ICS, Version 1.01.
http://www.cip4.org/document_archive/documents/ICS-MIS-Prepress-1.01.pdf.
CIP4. 2006f. MIS ICS 1.0 Errata revision A.
http://www.cip4.org/document_archive/documents/ICS-MIS-1.0RevA.pdf. Accessed
2006-10-31.
CIP4. 2006a. Base Interoperability Conformance Specification, 1.0 Errata Revision B.
http://www.cip4.org/document_archive/documents/ICS-Base-1.0RevB.pdf. Accessed
2006-10-31.
33
CIP4. 2006b. Integrated Digital Printing ICS, Version 1.0 Errata Revision A.
http://www.cip4.org/document_archive/documents/ICS-IDP-1.0RevA.pdf. Accessed
2006-10-24.
CIP4. 2006c. CIP4 Software License, Version 2.0.
http://www.cip4.org/open_source/cip4_software_license_v2.html. Accessed 2006-10-
25.
Daun, Stefan, Georg Lucas, and Jürgen Schönhut. 1998. Specification of the CIP3
Print Production Format - Version 3.0.
http://www.cip4.org/documents/ppf_specifications/index.html. Accessed 2006-10-31.
Enlund, Nils. 1998. Workflow Management in Graphic Arts Production. IARIGAI 25,
191-203.
Fielding, R., J. Gettys, J. Mogul, H. Frystyk, L. Masinter, P. Leach, and T. Berners-Lee.
1999. Hypertext Transfer Protocol -- HTTP 1.1.
http://www.w3.org/Protocols/rfc2616/rfc2616.html. Accessed 2006-10-24.
Handberg, Leif. 2003. On the implementation of production management systems in
the graphic arts industry. KTH, Royal Institute of Technology.
Haugan, Gregory T. 2001. Effective Work Breakdown Structures. Project
Management Institute.
Ifra. 2002. Ifra Special Report 6.21.3 – IfraTrack 3.0.
http://www.ifra.com/WebSite/news.nsf/(StructuredSearchAll)?OpenAgent&IFRATRA
CK. Accessed 2006-10-05.
Kipphan, Helmut. 2001. Handbook of Print Media. Springer-Verlag.
Nordqvist, Stig. 1996. A Model for Global Production Management Systems in
Newspaper Production, Real Time Management of Time Critical and Heterogeneous
Processes. KTH, Royal Institute of Technology.
Stering, Ola. 2006. Development of a Prototype for JDF Enabled Software.
http://www.stering.se/thesis/MasterThesis.pdf. Accessed 2006-10-30.
Thunell, Evelina. 2003. The CIP4 JDF Editor – Visualization of JDF.
http://www.cip4.org/documents/jdf_overview/MasterProject_Evelina_Thunell.pdf.
Tuijn, Chris. 2004. Workflow Modeling in the Graphic Arts and Printing Industry.
Color Imaging IX: Processing, Hardcopy, and Applications 5293, 66-74.
W3C. 2004. XML Schema. http://www.w3.org/TR/2004/REC-xmlschema-0-
20041028/. Accessed 2006-10-02.
W3C. 2006. Extensible Markup Language (XML) 1.0 (Forth Edition).
http://www.w3.org/TR/xml/. Accessed 2006-10-02.
WfMC. 1999. Workflow Management Coalition, Terminology & Glossary, TC 1011
Issue 3.0. http://www.wfmc.org/standards/docs/TC-1011_term_glossary_v3.pdf.
34
35
TAGA 57th Annual Technical Conference 2005 Paper I
Toronto, Ontario, Canada; April 17-20, 2005; p. 271-281
Proceedings, TAGA 2005, 57th Annual Technical Conference, Toronto, Canada

Claes Buckwalter
Keywords: Workflow, software framework, simulation, JDF
Abstract: Job Definition Format (JDF) is a relatively young industry
standard that specifies a workflow model and a data format for
describing print jobs and exchanging production information. Although
most vendors today offer JDF-enabled products, little research has been
conducted aiming at measuring the benefits of using JDF in production.
One reason for this is likely the lack of suitable tools.
This paper presents a JDF-compliant tool that can be used to simulate the
interaction of arbitrary devices in a print production workflow. This tool
has many usage scenarios, one of them being the possibility to simulate
devices in “live” production in order to measure JDF performance and
detect production bottlenecks.
1 Introduction
A print production workflow can be modeled by a network of inter-
connected distinct processes. A process is here defined as a sequence of
related operations that consumes, transforms or combines input
resources in order to generate output resources. For instance, the process
of traditional offset printing takes input in the form of substrate, printing
plate, ink, and press configuration parameters; and produces output in
the form of printed matter. In a modern print production workflow a
majority of the processes are represented by software systems that
control and execute underlying subsystems, such as physical devices, for
example a printing press. To achieve an optimized workflow, the
software systems representing the workflow’s processes need to
communicate and exchange information in a well-defined manner. Job
Definition Format (JDF) is a specification (CIP4, 2004a) that defines this
information exchange between processes. The JDF Specification defines:
• A job ticket format for describing print jobs and all the processes and
resources in prepress, press, and postpress required to produce print
jobs

Department of Science and Technology (ITN), Linköping University, Sweden
• A communication protocol, named Job Messaging Format (JMF), for

exchanging information between systems in the production
workflow
To summarize, JDF specifies a solution for integrating all systems in the
print production workflow, from prepress, through press, to postpress,
including the management information systems (MIS) monitoring and
controlling the workflow.
Under certain circumstances it may be of interest to be able to simulate
one or more processes in a print production workflow. By inserting a
simulated process into a real print production workflow one could test
the effects that the added process has on the performance of the
workflow and production as a whole. One could also build an entire
print production workflow using only simulated processes, but use real
management information systems to track and control these processes.
Such a setup would allow one to experiment with different workflow
configurations using real MIS systems.
The difficulties of designing a simulation tool for newspaper production
workflows have been discussed in Nordqvist and Fällström (1996). A
majority of the difficulties discussed also apply to general prepress, press
and postpress workflows. However, by leveraging JDF a significant
amount of these difficulties can be eliminated. The work of defining the
process or processes to simulate and specifying how to integrate the
simulation tool with real production systems is fully covered by JDF.
Hence, once a software framework implementing the JDF Specification is
in place, research efforts can be focused on developing sophisticated and
realistic simulations of processes.
This paper presents a first version of a software framework that
implements the JDF Specification and that can be used by a simulation
tool to integrate with other JDF-enabled systems in print production
workflows. The software framework presented provides an application
programming interface (API) defining the services required of a JDF-
enabled system. The framework, named the Elk Framework, can be used
by developers wishing to implement a system that integrates with other
systems using the JDF job ticket format and the JMF messaging protocol.
As a proof-of-concept, a simulation tool that uses the Elk Framework is
also presented.
2 Print Production Workflow

As described in Enlund (1998), a print production workflow, or any
workflow for that matter, can be modeled as a network of linked
activities that perform operations on objects. When an activity executes it
consumes, transforms, or combines input objects in order to generate
output objects. Applied to the activity of offset printing, input objects
would be paper, ink, printing plates; output objects would be printed
sheets of paper. An activity requires a set of resources in order to execute.
Examples of resources required for printing are a printing press, and a
worker operating the press. During execution an activity is under the
influence of control signals. Input control signals modify or query the
internal state of an activity. Output control signals are triggered by
changes of the activity’s internal state.
Activities are linked together using input objects and output objects to
create process networks. An output object from one activity is the input
object for the next activity in the workflow. Objects can link activities
together in several different ways to produce networks of parallel,
sequential, or iterative activities.
The systems that a print production workflow consists of can be grouped
into two different types, as shown in Figure 2-1:
• Production systems on the plant floor that execute one or more
activities in the workflow; for example, preflight software, a printing
press, or a folding machine. Production systems are often controlled
by software, and in some cases, often in prepress, consist entirely of
software.
• Systems that monitor and control the production systems, for
example a production planning system. These systems are computer
systems and are usually called management information systems
(MIS).
Management
Management Information
Information Systems
Systems (MIS)
(MIS)
Production
Prepress
Prepress Systems
Systems Press
Press Systems
Systems Postpress
Postpress Systems
Systems Systems
Figure 2-1 Systems in a print production workflow

A critical requirement for achieving an optimal print production

workflow is that management information systems and production
systems can communicate and exchange information in real-time during
production (Enlund, 1998). Over the years, several industry standards
have been developed that specify the integration of systems in the print
production workflow; for example, IFRAtrack (Fällström, 2002), for
tracking newspaper production, and Print Production Format (PPF) (Daun
et al., 1998), for exchanging configuration data between systems.
However, none of these standards have covered the entire workflow. It
was not until the printing industry’s major vendors joined forces and
developed Job Definition Format (JDF) that there was an industry
standard that covered all aspects of the print production workflow.
2.1 Job Definition Format (JDF)

Job Definition Format (CIP4, 2004a) is an industry standard maintained by
an international consortium named CIP4 (CIP4, 2005), consisting of
system vendors, organizations, and research institutes. JDF defines a
model for specifying a print job and all of the workflow activities
required to produce a print job. The workflow model defined by JDF is
similar to the generic workflow model described above. However, the
terminology is slightly different (see Figure 2-2):
• The generic workflow model’s activity is called a Process.
• The generic workflow model’s objects and resources are generalized
and called Resources.
• The generic workflow model’s control signals are realized using a
messaging protocol called Job Messaging Format (JMF). A system that
executes a Process in a JDF workflow uses JMF to communicate with
other production systems and management information systems in
the workflow.
JMF Messages
Input
Input Output
Output
Resources
Process
Process Resources
Resources Resources
Figure 2-2 A JDF Process
In addition to defining a workflow model, JDF also attempts to define all

of the Processes and Resources required in a print production workflow,
such as Screening and SaddleStiching (Processes), and
ColorCorrectionParams and Employee (Resources).
However, most importantly—JDF defines what information should be

exchanged between systems in the workflow and the manner in which
this information is exchanged, thus making it possible to connect and
integrate all systems in a print production workflow.
2.1.1 JDF Integration Technologies

On a more concrete level, JDF’s model of a print job, including the
Processes required to produce the print job, is described using XML
syntax (Yergeau et al., 2004). A JDF XML document that describes a print
job is called a JDF job ticket or a JDF instance. A print job is produced in a
JDF-enabled workflow by letting management information systems
route the print job’s JDF job ticket to the production systems that realize
the Processes defined in the JDF job ticket.
To enable JDF job tickets to be transferred between the systems in a
workflow JDF defines a messaging protocol called Job Messaging Format
(JMF). JMF messages are small XML documents that are used to control
and monitor production systems, and to send and track JDF job tickets
through the workflow.
The strength of JDF, integrating the heterogeneous systems in the print
production workflow, can naturally also be applied to integrating
simulation tools into real production environments.
3 Process Simulation
Under certain circumstances it may be of interest to be able to simulate
one or more processes in a print production workflow. By inserting a
simulated process into a real print production workflow one could, for
example, test the impact the added process has on the workflow. One
could also build an entire print production workflow using only
simulated processes, but use real management information systems to
track and control the processes in the workflow. Such a setup would
allow one to experiment with configurations of production systems
using real management information systems.
In order to simulate a process one must first create a model of the
process. The type of simulation model most suitable for modeling a
process in a print production workflow is a discrete event simulation
model (Bäck et al., 1997). Once a process simulation model has been
implemented in software, the model must be integrated with a print
production workflow. JDF specifies how to integrate systems in a print
production workflow. Hence, integrating a simulated process with real
systems in a print production workflow is trivial if the simulated process
has an integration layer that implements the JDF Specification.
Print
Print Production
Production
Workflow
Workflow
JDF Instances
JMF Messages
JDF
JDF Integration
Integration Layer
Layer
Simulation
Simulated
Simulated Process
Process Tool
Figure 3-1 Process Simulation with JDF Integration
A generic and reusable software framework that provides the services

required of the JDF Specification would be extremely useful for
integrating simulated processes with real production systems. The
remaining part of this paper describes such a framework.
4 The Elk Framework

The JDF Specification defines several roles that a system in a workflow
can have (CIP4, 2004a, 2004b). Two of these roles are the Device role and
the Agent role. A system with the Device role reads a JDF job ticket and
executes one or more of the processes specified in the job ticket. A
system with the Agent role can create and modify JDF job tickets. If a
system has both of these roles it implements a Worker Interface (CIP4,
2004b). A system that implements the Worker Interface is called a
Worker. More specifically, a Worker is a system that can receive a JDF job
ticket; execute one or more of the processes specified by the job ticket;
update the job ticket; and send the job ticket to another system in the
workflow, see Figure 4-1. A JDF-enabled process simulation tool would
need to implement a Worker Interface, and would therefore be Worker.
Modify
Modify JDF
JDF
instance
instance Send
Send JDF
JDF
instance
instance
Create
Create JDF
JDF
instance
instance
Execute
Execute JDF
JDF Receive
Receive JMF
JMF
instance
instance message
message
Read
Read JDF
JDF Send
Send JMF
JMF
instance
instance message
message
Receive
Receive JDF
JDF
instance
instance
Worker
Figure 4-1 Worker use case diagram

The generic functionality required of a Worker can, as Figure 3-1 hints,
be abstracted into a reusable software framework for JDF integration.
Presented here is such a framework, named the Elk Framework.
The Elk Framework is implemented in the Java programming language
and consists of two parts:
• An application programming interface (API) that expresses the
generic functionality required of a Worker as a set of services
• A reference implementation of the API
4.1 Services
The Elk Framework API consists mainly of interfaces and abstract
classes. In other words, the API does not contain actual implementations
of any services, it just defines the service and how they are accessed
using the Java programming language. One can say that the API is a
specification of the services. The following are the most important
services defined by the Elk Framework API:
4.1.1 Messaging Gateway

A Messaging Gateway is used to send and receive JMF messages and JDF
instances without exposing the underlying network transport protocol.
By using a Messaging Gateway one needs not be concerned with the
details of sending and receiving JMF messages and JDF instances.
Instead one can focus on processing the JMF/JDF received and
generating JMF/JDF to be sent, see Message Processor.
4.1.2 Message Processor

A Messaging Gateway routes JMF messages to Message Processors. A
Message Processor knows how to process a specific type of JMF message,
for example a QueueStatus JMF message (CIP4, 2004a), which queries the
status of a Worker’s queue. A Message Processor processes JMF
messages in some implementation specific way, possibly delegating the
processing to other components within the Worker.
4.1.3 Subscription Manager

Management information systems monitor a Worker by subscribing to
notifications of state changes that occur within a Worker. A Subscription
Manager alleviates the Worker from having to deal with the intricacies of
managing subscriptions and sending JMF messages containing
notifications of state changes.
4.1.4 Job Queue

A Job Queue manages jobs, corresponding to JDF instances, sent to a
Worker for processing. Jobs are typically added to a Job Queue via a
Message Processor. A Process, see below, takes jobs from a Job Queue and
executes the jobs.
4.1.5 Process
A Process component reads JDF instances and executes one or more of
the processes defined in a JDF instance. In other words, a Process is the
component in a Worker that communicates directly with the underlying
software or equipment that does the actual work. For example, a Process
component that implements the ConventionalPrinting process
(CIP4, 2004a) would configure the printing press according to the
parameters specified in the JDF instance and then start the printing
press.
4.2 Reference Implementation and Simulation Tool

Besides an API, the Elk Framework also consists of a reference
implementation that exemplifies how the API’s services can be combined
to create the JDF integration layer of a Worker. By leveraging the
reference implementation a simulation tool can be integrated with a JDF-
enabled print production workflow, see Figure 3-1. All that is required is
that one creates an implementation of a Process component, see 4.1.5, that
executes the process simulation model.
As a proof-of-concept a simulation tool has been created that uses the Elk
Framework. The tool implements a simple simulation of a proofing
process, in JDF terminology called Approval (CIP4, 2004a). The Approval
process is used when a resource, for example a print-ready PDF
document, needs to be proofed/approved before the next process in a

print job’s workflow can commence.
Figure 4-2 shows an overview of the most important components that
the simulation tool consists of. The component Simulated Approval Process
implements the simulation model. It takes a job, a JDF instance, from the
job queue; simulates the execution of the job, consuming input resources
and producing output resources accordingly; and then sends off the
updated JDF instance for further processing in the workflow. During
process execution, all state changes within the simulation model are sent
to the management information systems monitoring the process or
tracking the job.
JMF Messages
JDF Instances
Incoming
Incoming
Messaging
Messaging
Gateway
Gateway
QueueStatus
QueueStatus
Message Processors
Processor
Message Processors
Processor
Message Processors
State Changes State Changes
Poll for
new job Simulated
Simulated Subscription
Subscription
Job
JobQueue
Queue Approval
ApprovalProcess
Process Manager
Manager
Outgoing
Outgoing
Messaging
Messaging
Gateway
Gateway
JMF Messages
JDF Instances
Figure 4-2 Overview of the simulation tool's components

5 Conclusions and Future Work

Job Definition Format (JDF) defines a workflow model for print
production and specifies how to integrate the heterogeneous systems in
the print production workflow. By leveraging JDF, the integration of
simulation tools into real print production workflows becomes greatly
simplified. A simulation tool into two distinct modules: a module
concerned with simulating the production process and a module that
provides the services necessary for JDF integration. This paper focused
on the JDF integration module and presented the Elk Framework—a
software framework that provides the generic services required by any
system that wishes to integrate with a JDF-enabled print production
workflow.
As a proof-of-concept, a simple simulation tool was presented that uses
the foundation and infrastructure provided by the Elk Framework.
Preliminary testing of the simulation tool in an environment with
commercial production systems has been conducted in cooperation with
the CIP4 Organization. The preliminary tests have been successful and
further tests will be conducted as the Elk Framework evolves.
The development of the Elk Framework will be continued with a future
focus on designing and implementing more accurate simulation models
of production processes and running these simulation models in real
print production environments. Of interest is also the possibility of
creating a virtual print production workflow consisting of simulated
processes.
More information regarding the Elk Framework can be found at the
project web site: http://elk.itn.liu.se
6 Acknowledgments
The author wishes to thank professor Björn Kruse, ITN, Linköping
University, and Dr. Rainer Prosi, CIP4, for their valuable feedback and
support. The author would also like to extend his gratitude to the CIP4
Organization, and the T2F research program (www.t2f.nu) for their
financial support.
7 References
Bäck, A., Lehtonen, T., Karttunen, A., Kuusisto, M., Launonen, R.
1997 Evaluation of Printing Production in Networks by Means of Computer
Simulation Models, Advances in Printing Science and Technology,
vol. 24, pp. 177–190
CIP4
2004a JDF Specification Release 1.2,
http://www.cip4.org/documents/jdf_specifications/JDF1.2.pdf
2004b Base Interoperability Conformance Specification (Base ICS) 1.0,
http://www.cip4.org/document_archive/documents/ICS-Base-
1.0.pdf
2005 The International Cooperation for the Integration of Processes in
Prepress, Press and Postpress Organization (CIP4),
http://www.cip4.org
Daun, S., Lucas, G., Schönhut, J.
1998 CIP3 PPF Specification Version 3.0, Darmstadt, Germany,
http://www.cip4.org/documents/technical_info/cip3v3_0.pdf
Enlund, N.
1998 Workflow Management in Graphic Arts Production, Advances in
Printing Science and Technology, vol. 25, pp. 191–203
Fällström, F.
2002 IFRAtrack 3.0, IFRA Special Report 6.21.3, Darmstadt, Germany
Nordqvist, S., Fällström, F.
1996 Simulation of Newspaper Production Processes—Decision and
Management Support Tools, TAGA 1996 Conf. Proc., pp. 299–317
Yergeau, F., Bray, T., Paoli, J., Sperberg-McQueen, C. M., Maler E.
2004 Extensible Markup Language (XML) 1.0 (Third Edition),
http://www.w3.org/TR/2004/REC-xml-2004020
A Tool for Testing Compliance with CIP4’s
Interoperability Conformance Specifications
2005 International Conference on Digital Production
Paper II
Printing and Industrial Applications
Amsterdam, The Netherlands; May 9, 2005;
p. 83-84; ISBN/ISSN 0-89208-256-9
Proceedings, 2005 International Conference on Digital Production Printing and Industrial Applications
Amsterdam, The Netherlands; May 9, 2005; p. 83-84; ISBN/ISSN 0-89208-256-9
A Tool for Testing Compliance with CIP4’s

Interoperability Conformance Specifications
Claes Buckwalter
ITN, Linköping University
Norrköping, Sweden
Abstract presented in this paper. Instead, the test tool presented

here is concerned only with testing a product’s ability to
Job Definition Format (JDF) is a relatively young consume and produce JDF instances and JMF messages
industry standard developed by The International as specified by the ICS’s that the product claims to
Cooperation for the Integration of Processes in comply with.
Prepress, Press and Postpress (CIP4). JDF specifies a
data format for describing print jobs and exchanging The Test Tool
production information between systems in the print
production workflow. Most vendors in the printing The test tool implements the role of a manager; a piece
industry today offer “JDF-enabled” products, but the of software that sends JDF instances and JMF messages
industry lacks a well-defined test protocol and to a worker. The worker role is implemented by a piece
specialized tools for testing and verifying the level of of software that processes received JDF instances and
JDF-compliance that products have. JMF messages and after processing may send
This paper presents an open source test tool for information back to the manager. The worker is the
testing the level of JDF compliance as specified by the software under testing by the test tool presented here. An
CIP4 organization’s Interoperability Conformance example of a product with the manager role would be a
Specification (ICS) documents. The test tool is semi- piece of prepress controller software that sends jobs to a
automated and validates system behavior and output of RIP, the RIP being a worker.
JDF instances and JMF messages both syntactically and
based on context. Test Procedure
The test tool sends JDF/JMF data to a worker and
Introduction tests that the worker responds correctly by producing
valid output. The following tests are performed on JDF
Although most vendors in the printing industry offer instances and JMF messages produced by the worker:
some level of JDF-support in their products there is 1. The syntax of the XML structure is validated against
unfortunately no guarantee that JDF-enabled products the JDF XML Schema [4]
from one vendor will be interoperable with those from 2. The presence and correctness of all required XML
another vendor. To alleviate this problem the CIP4 elements and attributes specified by the relevant ICS
organization has developed the Interoperability documents is checked
Conformance Specification (ICS) documents. Each ICS 3. The XML data is examined and it is checked that it
document defines a subset of the JDF specification [1] is correct according to the current context
that is required by a certain class of product. The Base Validation against the JDF XML Schema is
ICS [2] is the least common denominator that all JDF- straightforward and performed using CIP4’s JDF library
enabled products must comply with. On top of the Base JDFLib-J [5]. The presence of the XML elements and
ICS there are at the time of writing six other ICS attributes required by the ICS documents are tested by
documents [3] for different product classes. test cases configured with XPath expressions. One test
case with a set of XPath expressions is available for each
Testing JDF Compliance ICS document. Verifying that JDF instances and JMF
messages that the worker produces are correct according
Testing and verifying the behavior of a JDF compliant to the current context is performed by maintaining a
product is a complex task. For example, testing that a record of all JDF and JMF data previously consumed and
printing press interprets a JDF job ticket and produces produced by the worker. Any new data produced by the
the correct output would involve analyzing the printed worker is compared with the previously recorded data
sheets and in some way attempting to verify that they and validated using specifically built test cases.
match what the JDF job ticket specified. Obviously, All test results are logged in an XML file. It is left to
there are many factors that have nothing to do with a other tools beyond the scope of this paper to analyze and
product’s ability to interpret JDF data that can influence visualize the information in the XML log file. For
the physical output produced by the product. Functional example, the XML log file could be transformed using
testing of this kind is beyond the scope of the test tool
XSLT to an XHTML document for viewing in a web a test case for the Base ICS. Additional test cases for
browser. other ICS’s must be implemented for testing more than
the minimal level of JDF functionality. Nonetheless, the
Architecture test tool is still useful since many vendors still lack full
The test tool is implemented as a Java application support for even the Base ICS.
that consists of three main modules, as shown in The complete source code and up to date
Figure 1. The client module sends JDF/JMF data to the information regarding the development of the test tool
worker under test; the server module receives JDF/JMF presented in this paper is available at [6].
data from the worker; and the test module coordinates
the test data sent to the worker and validates all data References
produced by the worker. The outgoing test data used to
probe the worker consists of a set of manually written 1. JDF Specification Version 1.2 [Online]. Available:
JDF and JMF files; all validated using CIP4’s CheckJDF http://www.cip4.org/documents/jdf_specifications/JDF1.2.
tool [5]. These files can easily be modified or replaced if pdf [2005, February 4]
necessary. The test cases are dynamically loaded at 2. Base Interoperability Conformance Specification (Base
startup of the test tool and are configured using ICS) [Online]. Available:
configuration files. New ICS support can be added by http://www.cip4.org/document_archive/documents/ICS-
creating a new test case. Base-1.0.pdf [2005, February 4]
3. ICS Registry [Online]. Available:
http://www.cip4.org/document_archive/ics.php [2005,
February 4]
Test Tool (Manager)
4. XML Schema for JDF Version 1.2 [Online]. Available:
Test JDF/JMF http://www.cip4.org/Schema/JDFSchema_1_2/JDF.xsd
Client Software
Module Module under test
[2005, February 4]
Test
(Worker) 5. JDF Open Source [Online]. Available:
JDF/JMF
Cases Server http://www.cip4.org/open_source/index.html [2005,
Module
February 4]
6. JDF ICS Test Tool [Online]. Available:
http://www.itn.liu.se/~clabu/dpp05-51 [2005, February 4]
Test
JDF/JMF ICS Test
Results
Log
Test Files Configs
Biography
Figure 1. Architecture Claes Buckwalter has a Master’s degree in Media

Technology and Engineering from Linköping University,
Sweden, where he is currently a Ph.D. student. His Ph.D.
Future Work studies focus on process automation and information
interchange between processes in the print production
The test tool has so far been used for testing CIP4’s workflow, mainly within prepress. Before committing to
internal software tools but more extensive testing against an academic career, Claes co-founded Swedish software
third-party products must be conducted in order to company Frog Software that develops Internet-based
thoroughly evaluate the test tool. Currently, there is only print job delivery solutions.
Integration Patterns
Applied to Print Production
TAGA 58th Annual Technical Conference 2006 Paper III
Vancouver, British Columbia, Canada;
March 19-21, 2006; p. 54-68
Proceedings, TAGA 2006, 58th Annual Technical Conference, Vancouver, Canada
Integration Patterns
Applied to Print Production
Claes Buckwalter*
Keywords: messaging, integration, pattern language, JMF, JDF
Abstract: In a modern printing plant software systems are ubiquitous
and indispensable. Systems for order management, production planning,
and other administrative systems are implemented in software. Most, if
not all, equipment on the plant floor has a software front-end that either
controls the physical equipment directly or displays instructions for a
human operator to interpret and execute. These software systems are not
isolated islands. During production they need to communicate and
exchange information. For example, a prepress workflow system may
send configuration parameters to production equipment and production
equipment may send status updates to production monitoring systems.
This type of communication is typically implemented by sending
messages, discrete units of data, between the systems.
Integrating heterogeneous systems using messaging is nothing unique to
the printing industry. It is a well-proven solution and there are several
general-purpose solutions available for integrating disparate systems
using messaging. The experience and knowledge on the subject has been
documented in several pattern languages.
This paper examines Job Definition Format’s messaging protocol Job
Messaging Format (JMF), and maps JMF concepts to patterns found in
pattern languages for system integration using messaging. Weaknesses
found in JMF are discussed and patterns are applied to suggest
alternative solutions. The result is JMF expressed using general
enterprise integration patterns.
*
Digital Media division, ITN, Linköping University, Sweden
1 Introduction
Software systems play a vital role in a modern printing plant.
Management Information Systems (MIS), workflow systems, and
prepress systems that process digital content are implemented entirely in
software. Most equipment on the plant floor has a software front-end
that controls the physical equipment directly or displays instructions for
human operators to interpret and execute.
Efficient print production requires that the software systems can
communicate. Digital content, job specifications, configuration
parameters, and tracking data need to be exchanged between systems
continuously during production. Integrating the heterogeneous systems
in the printing plant is crucial.
The integration technology with the widest acceptance in the printing
industry is Job Definition Format (JDF), maintained by the industry
consortium CIP4 [7]. The JDF specification [4] defines an XML-based
data format, a “job ticket format”, that allows systems in the print
production workflow to describe printed products, and the workflow
required to produce them, in a standardized manner. Included in the JDF
standard is an XML-based communication protocol called Job Messaging
Format (JMF). JMF allows systems to exchange units of data, messages,
containing control commands, JDF job ticket data, and tracking
information.
Integrating disparate systems using messaging is not unique to the
printing industry; the principles behind JMF are similar to those of
general-purpose integration solutions such as Web Services and
message-oriented middleware [10]. Best practices and solutions to
reoccurring problems within the area of system integration using
messaging have been documented in several pattern languages [1, 3, 8, 10].
Originally used in architecture [2], then in object-oriented software
design [9], a pattern language is a collection of reusable solutions,
patterns, which can be used to solve problems in a particular problem
space.
This paper provides an analysis of JMF and classifies the concepts found
in JMF using patterns found in patterns languages for system integration
and service interaction [1, 3, 8, 10]. JMF supports the concept of message
routing performed by intermediate systems, for example a workflow
system that routes messages to/from systems under its controls. This is
beyond the scope of this paper, which focuses on direct point-to-point
communication between systems without an intermediary.
2 The Communication Models of JMF

The JDF specification [4] defines two communication models for JMF
messaging: “unidirectional” and “bidirectional” messaging. Most JMF
messaging is of request-reply type where a system sends a request
message and gets a reply message back. The bidirectional
communication model of JMF uses the HTTP protocol for message
transport. HTTP is a bidirectional in the sense that a system sending a
request gets an immediate reply on the same communication channel as
the request was sent. The unidirectional communication model uses files
for message transport. A system sends a request by writing a file to a
location and receives a reply by reading a file from another location. The
file-based protocol is unidirectional in the sense that a request does not
receive an immediate reply. Instead, the reply is received over a separate
channel.
This section classifies the two communication models of JMF based on
the level of decoupling between sender and receiver.
2.1 File-Based JMF Messaging

Exchanging information between systems by reading and writing files is
a common integration style. In the graphic arts industry this integration
style is called “hot folder” integration and has a long history of use in
prepress workflows where it is used to automate the exchange and
processing of content files, such as PDF documents.
In a file-based JMF messaging scenario each system is configured with
an input folder that it uses to receive files containing JMF messages. A
system’s input folder can be regarded as the channel that the system uses
to receive messages from one or more other systems. A system sends a
message by writing a file containing the message to the input folder of
the receiving system. The sender’s message contains a URL that specifies
a file (a channel) to which the receiver can write a reply message.
The JDF specification [4] describes file-based JMF messaging as
unidirectional and asynchronous. Unidirectional in that separate channels
are used for sending and receiving messages; a single channel is never
use for both. Asynchronous in that a system can send a message without
requiring that the receiver be available at the time of sending. The sender
and receiver are decoupled by the file system that provides an
infrastructure for messaging while ensuring a loose coupling between
systems. The file system can be viewed as a primitive form of message-
oriented middleware or messaging system [10].
2.2 HTTP-Based JMF Messaging

The Hypertext Transfer Protocol (HTTP) is the network transport protocol
used to transfer web pages between web servers and web browsers.
HTTP is also used by Web Services standards as the transport protocol

for exchanging business data between heterogeneous and distributed
applications. JMF has several similarities to Web Services standards.
HTTP-based JMF messaging requires that each system implement a
HTTP client and a HTTP server. The sender of a message uses its HTTP
client to open a HTTP connection to the address of the receiver’s HTTP
server. A HTTP request containing a JMF message is sent over the
connection. The receiver’s HTTP server receives the request, process the
message and replies using a HTTP response containing a reply JMF
message. The request and reply messages are both sent over the same
HTTP connection.
HTTP-based JMF messaging is described by the JDF specification as
bidirectional and synchronous. The communication is bidirectional in that
the HTTP connection the sender uses to connect to the receiver is used to
send both the request JMF message and the reply JMF message. The
communication is synchronous in that both sender and receiver must be
available at the time of sending and that the sender blocks until the
request message is sent and a reply received back. This type of
communication is often called Remote Procedure Call (RPC) [10] because it
is similar to invoking a procedure or method in a programming
language. JMF messaging is not the only example of using the HTTP
protocol for RPC communication; most Web Services standards, for
example SOAP [11], use this approach.
The synchronous nature of HTTP-based JMF messaging, and RPC in
general, entails a tight coupling between the systems involved in the
communication.
2.3 Coupling
Coupling is an important concept that applies at all levels in software
design. It is generally considered good design to strive for as loosely
coupled, decoupled, software components that have a minimum number
of dependencies on each other. Systems assembled of loosely coupled
components tend to be flexible and allow a component to be modified or
replaced with a minimum of impact on other components. The JDF
specification’s classification of file-based JMF messaging as
“asynchronous” and HTTP-based JMF messaging as “synchronous”
indicates the degree of coupling between systems in these two types of
communication. However, a more precise classification of the two types
of JMF messaging is desirable.
Eugster et al. [8] have identified three dimensions of (de-)coupling in the
domain of communication middleware. These dimensions have been
formalized by [1] and used to classify common middleware solutions.
The three dimensions of decoupling are:
• Time decoupling – the sender and receiver of a message do not

need to be active at the same time.
• Space decoupling – a message is sent to a symbolic address, not
the direct address of a system.
• Synchronization decoupling – senders do not block while sending a
message and receivers are notified by a callback when a new
message is available.
Using these three dimensions the two communication models of JMF
messaging can be classified, see Table 1. A set of notational elements for
each possible combination of couplings has also been developed [1]. The
notations corresponding to file-based and HTTP-based JMF messaging
are shown in Figure 1.
Table 1 Decoupling of file-based and HTTP-based JMF messaging

Time Space Synchronization
decoupling decoupling decoupling
Blocking send
File-based JMF Yes Yes
Blocking receive
Blocking send
HTTP-based JMF No No
Non-blocking receive
Figure 1 Decoupling configuration notations [1] for file-based (left)

and HTTP-based (right) JMF messaging
File-based JMF messaging provides the highest degree of decoupling

between communicating systems and has a classification similar to
message-oriented middleware systems [1]. The file system acts as a
primitive messaging system [10] that decouples sender and receiver. A
sender can write a message file to the file system without the receiver
being active. A sender sends a message by writing a file to a URL which
points to a path in a file system, not directly to the receiving system.
When a system sends a JMF message the thread sending the message
typically blocks until the file has finished being written to the file system.
To receive messages a system typically has a thread that scans the file
system at a specified time interval – the Polling Consumer pattern [10].
When the thread discovers that a file it blocks until the file is read, the
message processed, and possibly a reply message sent. To summarize,
file-based JMF provides space decoupling and time decoupling but the
blocking send and receive characteristics result in limited
synchronization decoupling.
Systems participating in HTTP-based JMF messaging are both space
coupled and time coupled. A system sending a JMF message connects
directly to the receiver and both systems are active during the delivery of
the message. The message-sending thread of the sender typically blocks
until the message has been sent and a reply is received. Receiving a JMF
message is typically non-blocking. For each message received by a
system a new thread is started that handles message processing and the
sending of a reply – the Event-Driven Consumer [10] pattern.
While HTTP-based JMF messaging inflicts a higher coupling between
communicating systems it is often considered less complex to implement
the messaging endpoints of a system with these characteristics. The
blocking send combined with time coupling relieves the sender of
managing any state information related to the message being sent. This is
managed by the programming language’s call stack. In a time decoupled
system the sender would have to store the context to which the message
is related so that when a reply is later received the context can be
recreated and processing continue.
In practice, HTTP-based JMF messaging is the communication model
implemented by the majority of JDF-enabled systems. The JDF
specification [4] implicitly favors HTTP messaging and the Base ICS [5]
explicitly requires that systems of base conformance level 2 and upwards
support HTTP-based messaging. In fact, file-based JMF messaging is not
required at all by the Base ICS. Instead, a hot folder exchange of JDF
instance files is required that is based on the same principles as file-
based JMF messaging.
The rest of this paper describes JMF from the point of view of HTTP-
based JMF messaging.
3 Patterns in JMF
Two pattern languages that describe the integration and interactions of
distributed heterogeneous systems are [10] and [3]. This section uses
these two pattern languages to examine JMF and identify where the
design choices made for JMF correspond to the documented patterns.
The patterns identified are summarized in Appendix A.
3.1 Message Format

In essence, the JDF job ticket format and Job Messaging Format (JMF) are
Canonical Data Models [10] that standardize the data exchange between
systems in the print production workflow. Each system may use its
proprietary data model internally, but must be able to export and import
data according to the canonical data model defined by the JDF
specification [4].
As JDF evolves, new versions of the specification are released. Each new
version of the JDF specification results in a new version of the XML
schema that defines the syntax of the JMF message format. In addition, a
JMF message can be conformant with several Interoperability Conformance
Specifications (ICS) [6], each of which may have multiple versions. For a
system to know how to process a message it needs to able to identify the
version and format of the message received. JMF solves this by
implementing the Format Indicator [10] pattern. Each JMF message
contains version number fields and identifies the XML schema(s) that the
message’s syntax adheres to.
The fundamental JMF messaging interaction is point-to-point request-
reply and can be mapped to the Send/Receive [3] and Remote Procedure
Invocation [10] patterns. A request message is sent by one system and
received by another system; the receiver processes the message and
sends a reply message back to the requestor. In a HTTP-based JMF
messaging scenario the reply message can be sent synchronously on the
same channel as the request message or asynchronously on a separate
channel.
Implementing the Send/Receive pattern requires the each message be
uniquely identifiable. All JMF messages therefore have a unique
identifier, a message ID. A system receiving a reply to a request message
it previously sent must be able to correlate the reply message with the
original request. Therefore, a system sending a reply is required to
specify the ID of the original request message in the reply message. This
corresponds to the Correlation Identifier [10] pattern.
In the case of a synchronous message reply, the replier sends the reply
message over the same channel as it received the request message; the
reply message is sent using a HTTP response to the request message’s
HTTP request over the same HTTP connection. If the requesting system
accepts asynchronous replies, the request message contains a Return
Address [10] that may be used by the receiving system to send the reply
message; in this case the request and reply are sent over separate
channels.
Some JMF message types are used to move large amounts of data
between systems. An example is the JMF SubmitQueueEntry message that
is used to submit a print job, consisting of a JDF instance file and high-
resolution content files, to a system for execution. JMF supports sending
all files related to the print job in a single large message called a MIME
package [4]. However, this is often an inefficient approach, especially in
the case where the print job, including all related files, must be delegated
to another system for execution. As a more efficient alternative, JMF

implements the Claim Check [10] pattern. Instead of sending the JDF
instance file and the content files in a single JMF message, a system can
choose to send a JMF message containing a URL, a claim check, which
points to the JDF instance file. The JDF instance file, in turn, contains
URL references to the content files. The receiving system can use the
claim check URL to first retrieve the JDF instance file, and then retrieve
the relevant content files.
3.2 JMF Message Families

The JDF specification [4] divides JMF messages into six message families,
each family consisting of messages of different types used for specific
purposes. For example, the message of type QueueStatus falls under the
Query message family and is used to request the state of a system’s
queue. There are 44 message types in total.
The six message families of JMF correspond to three message
construction patterns documented in [10]. The Command Message pattern
is used to invoke a procedure in another system. The Document Message
pattern is used to transfer data between systems. The Event Message
pattern is used to asynchronously notify systems of events.
This section identifies the patterns found in the six message families of
JMF.
3.2.1 JMF Query

A JMF Query message requests information about the state of a system.
The caller may specify a Return Address [10] allowing the callee to
process the Query request asynchronously. The caller may also specify a
subscription for the Query requiring the callee to send a Signal message
on a certain time interval or when a specific state is reached.
A JMF Query message is the Command Message [10] pattern.
3.2.2 JMF Command

A JMF Command message requests a change in a system’s state. The
caller may specify a Return Address [10] allowing the callee to process the
Command request asynchronously.
A JMF Command message is the Command Message [10] pattern.
3.2.3 JMF Response

A JMF Response message is a mandatory synchronous reply to a Query or
Command request notifying the caller that the request has been received.
A Response may or may not contain the results of the processed Query or
Command request.
A JMF Response message is the Document Message [10] pattern.
3.2.4 JMF Acknowledge

A JMF Acknowledge message is an optional asynchronous reply to a
Query or Command request. If the caller of the request specified a Return
Address [10] the callee may choose to process the request asynchronously
and send one to three Acknowledge messages notifying the caller of the
completed stages of message processing (Received, Applied, and
Completed). The final Acknowledge message sent by the callee must
contain the results of the processed Query or Command.
A JMF Acknowledge message is a combination of the Document Message
and Event Message patterns [10].
3.2.5 JMF Signal

A JMF Signal message is an asynchronous reply to a Query message sent
on a certain time interval or when a specific state is reached. Signal
messages are sent to the Return Address [10] specified in the Query
request that initiated the subscription.
A JMF Signal message is the Event Message [10] pattern.
3.2.6 JMF Registration

A JMF Registration message requests that the callee send JMF Command
messages to a third party on a certain time interval or when a specific
state in the callee system is reached.
A JMF Registration message is the Command Message [10] pattern.
3.3 JMF Message Interactions

The interactions of JDF-enabled systems using the six message families
of JMF map to five of the interaction patterns defined in [3].
A system sends a Query or Command message to a system and receives a
Response message as a reply. This corresponds to the Send/receive [3] and
Remote Procedure Invocation [10] patterns, illustrated in Figure 2.
Figure 2 Send/Receive pattern in JMF

The extension of the above interaction that includes asynchronous

Acknowledge messages is a variant of the Multi-responses [3] pattern,
Figure 3.
Figure 3 Multi-responses pattern with Acknowledge

Another JMF interaction that fits the Multi-responses [3] pattern definition
is a Query message specifying a subscription; see Figure 4.
Figure 4 Multi-responses with Signal

The sending of a Signal or Acknowledge message corresponds to the

Send/Receive [3] pattern. The reception of a Signal or Acknowledge
corresponds to the Receive/Send [3] pattern. To be more specific, the Send
part of this incarnation of the Receive/Send pattern only requires that the
receiver send a JMF message if it encounters a message-processing fault.
If the receiver processes the JMF message successfully, it is not required
to send a JMF message as a reply. However, in the case of HTTP-based
JMF messaging a HTTP response with HTTP status code 200 (the request
has succeeded) must be sent.
The sending of a Registration and the resulting interactions map to the
Request with referral [3] pattern, see Figure 5. Any JMF message that uses
a Return Address [10] can be considered to map to the Request with referral
pattern. For example, the return address of a Query subscription could
refer to a third party instead of the sender of the Query containing the
subscription.
Figure 5 Request with referral in JMF

4 Conclusions and Discussion

File-based JMF messaging and HTTP-based JMF messaging both have
weaknesses. The space and time decoupling of systems provided by file-
based JMF messaging is a favorable property it shares with message-
oriented middleware solutions [1, 10]. However, while message-oriented
middleware systems are designed specifically for messaging, file-based
JMF messaging uses conventional file systems not designed with the
intention of serving as a messaging infrastructure.
HTTP-based JMF messaging lacks both space and time decoupling: the
sender connects directly to the receiver, requiring that both systems be
active during the interaction. Nonetheless, the simplicity of HTTP’s
request-reply point-to-point communication is what has made it into the
ubiquitous protocol it is and the protocol used by both Web Services [10]
standards and JMF to integrate distributed systems.
In practice, HTTP-based JMF messaging is the communication model
that JDF-enabled systems implement. The JDF specification [4] implicitly
favors HTTP and the ICSs [6] explicitly require that systems implement
JMF messaging over HTTP in order to be conformant.
Although HTTP-based JMF messaging enforces a tight coupling between
the message endpoints of interacting systems, there is nothing
preventing a system from internally implementing a loose coupling to its
endpoint. By adding an intermediate layer between a system and its
message endpoint the system can be decoupled from the messaging
technology, see Figure 6.
Message
Endpoint
HTTP
Intermediate
Intermediate
Client
Layer
System
Layer
HTTP
System
HTTP
Server
Figure 6 Decoupling of system and message endpoint

When sending a message a system would call the intermediate layer. The
call would return immediately and it would be left to the intermediate
layer to take responsibility for the delivery of the message to the receiver.
Likewise, when receiving a message a system’s message endpoint would
call the intermediate layer, which would determine further processing of
the message. The intermediate layer could be designed to provide full

decoupling between the system and its message endpoint, see Table 2.
Table 2 Decoupling properties
Time Space Synchronization
Non-blocking send
Intermediate Layer Yes Yes
Blocking send
Blocking receive
Blocking send
HTTP-based JMF No No
An intermediate layer could also support the notion of reliable delivery of

JMF messages, a topic covered by neither the JDF specification nor the
ICSs. Reliable delivery is concerned with guaranteeing the delivery of
messages, in the order they were sent, and without duplicates. The JDF
specification defines the necessary constructs to support guaranteed
delivery and delivery without duplicates. The Multi-responses [3] pattern
with Acknowledge messages (Figure 3) can be used to implement
guaranteed delivery of messages, and a receiver can eliminate message
duplicates by keeping a log of the IDs of received messages. However,
additional constructs need to be added to the JDF specification to
support ordered delivery of messages.
5 Acknowledgments
The author wishes to thank professor Björn Kruse, Linköping University,
and the members of the CIP4 organization for their feedback and
support.
6 References
1. L. Aldred, W. M.P. van der Aalst, M. Dumas, and A.H.M. ter Hofstede. On
the Notion of Coupling in Communication Middleware, Lecture Notes in
Computer Science, Volume 3761, pp. 1015 – 1033. Springer-Verlag Berlin
Heidelberg, 2005.
2. C. Alexander, S. Ishikawa, M Silverstein. A Pattern Language - Towns
Buildings Construction. Oxford University Press, 1977.
3. A. Barros, M. Dumas, A.H.M. ter Hofstede. Service Interaction Patterns:
Towards a Reference Framework for Service-based Business Process
Interconnection. Technical Report FIT-TR-2005-02, Faculty of Information
Technology, Queensland University of Technology, Brisbane, Australia,
March 2005.
http://sky.fit.qut.edu.au/~dumas/ServiceInteractionPatterns.pdf, accessed
March 2006.
4. CIP4. JDF Specification Release 1.3, 2005.
http://www.cip4.org/documents/jdf_specifications/JDF1.3.pdf, accessed
March 2006.
5. CIP4. Base Interoperability Conformance Specification (Base ICS) 1.0 rev A, 2005,
http://www.cip4.org/document_archive/documents/ICS-Base-
1.0RevA.pdf, accessed March 2006.
6. CIP4. Interoperability Conformance Specification (ICS) Registry.
http://www.cip4.org/document_archive/ics.php, accessed March 2006.
7. CIP4. The International Cooperation for the Integration of Processes in
Prepress, Press and Postpress Organization (CIP4) home page.
http://www.cip4.org, accessed March 2006.
8. P.Th. Eugster, P.A. Felber, R. Guerraoui, and A.-M. Kermarrec. The Many
Faces of Publish/Subscribe. ACM Computing Surveys, 35(2), pp. 114/131. June
2003.
9. E. Gamma, R. Helm, R. Johnson, J. Vlissides. Design Patterns: Elements of
Reusable Object-Oriented Software. Addison-Wesley, 1995.
10. G. Hophe and B. Woolf. Enterprise Integration Patterns. Addison-Wesley,
2004.
11. Simple Object Access Protocol (SOAP) Version 1.2, 2003.
http://www.w3.org/TR/soap12-part1/, accessed March 2006.
Appendix A
Pattern Name Pattern Occurrence in JMF
Canonical Data Job Messaging Format (JMF)
Model Job Definition Format (JDF)
JMF Command
Command Message
JMF Query
JMF Response
Document Message
JMF Acknowledge
Event Message JMF Signal
JMF/@Version
JMF/@ICSVersions
Format Indicator JMF/@xmlns
JMF/*/@xsi:type
HTTP header Content-type
JMF/*/@ID
Correlation Identifier
JMF/*/@refID
JMF/Query/@AcknowledgeURL
JMF/Command/@AcknowledgeURL
JMF/Query/Subscription/@URL
JMF/Registration/Subscription/@URL
Return Address JMF/Command[@Type=’SubmitQueueEntry’]
/QueueSubmissionParams /@ReturnJMF
JMF/Command[@Type=’SubmitQueueEntry’]
/QueueSubmissionParams /@ReturnURL
JDF/NodeInfo/@TargetRoute
JMF/Command[@Type=’SubmitQueueEntry’]
/QueueSubmissionParams /@URL
JMF/Command[@Type=’ReturnQueueEntry’]
Claim Check
/ReturnQueueEntryParams /@URL
JMF/Command[@Type=’ResubmitQueueEntry’]
/ResubmissionParams/@URL
A Messaging-Based Integration Architecture
for Print Production Workflow Systems
Printing Technology SPb’06
Paper IV
Saint Petersburg, Russia; June 26-30, 2006; p. 13-17
Proceedings, Printing Technology SPb’06, Saint Petersburg, Russia
A Messaging-Based Integration Architecture

for Print Production Workflow Systems
Claes Buckwalter
Digital Media, ITN, Linköping University, Sweden
Abstract Thus, when designing a JMF integration layer, the portion of a

system that handles JMF interactions with other systems, there
A print production workflow consists of a number of systems are several pattern languages where applicable well-proven
specialized at executing specific tasks. In order to realize an solutions can be found. In this paper a hypothetical architecture
efficient workflow it is not enough to simply assemble all the for a JMF integration layer is presented expressed using pattern
required systems, the systems must also communicate with each languages for system integration using messaging [1, 2, 8, 9].
other and exchange information. The printing industry has used
several approaches for integrating systems. A common
approach has been to use so-called “hot folders” to exchange
Job Messaging Format (JMF)
content files, such as PDF documents, between systems. A JMF message is a small XML document that is exchanged
Another approach, which focuses on the exchange of production between systems using two possible transport protocols: a
and configuration data, is the XML-based Job Definition proprietary file-based protocol that uses “hot folders”, or the
Format (JDF) and its messaging protocol Job Messaging standard network protocol HTTP [10].
Format (JMF).
Although the JDF Specification [5] defines both file-based and
The need to integrate heterogeneous systems is nothing unique HTTP-based JMF messaging, in practice only HTTP is used.
to the printing industry. The experience and knowledge in this The JDF Specification implicitly favors HTTP and the CIP4’s
area has been documented in several pattern languages. By Interoperability Conformance Specifications (ICS) [6] explicitly
applying a combination of several such pattern languages, this require HTTP-based JMF messaging. Therefore, this paper
paper presents a hypothetical integration architecture that discusses JMF from the point of view of HTTP-based JMF
enables a system to communicate with other systems using JMF messaging.
messaging.
JMF Message Families
JMF messages are small XML documents. A JMF message
Introduction consists of a message envelope in the form of a root XML
One prerequisite for efficient print production is that the element named JMF, which contains one or more “messages”
systems involved—Management Information Systems (MIS) that constitute the actual data. These messages are divided into
and the software and hardware in prepress, press, and six message families:
postpress—can communicate and exchange information
continuously during production. The data format and Command messages modify the state of a system, for example
communication technology that is quickly becoming the de submitting a new job to a RIP’s queue.
facto standard for solving this integration problem is Job Query messages query the state of a system, for example
Definition Format (JDF). querying the status of a printing press.
The JDF Specification [5], which is maintained by the industry Registrationmessages instruct a system to send Command
consortium CIP4 [7], defines an XML-based data format for messages to a third system. A MIS may for example tell a
specifying printed products and the workflow steps required to prepress system to send the plates it produces to a press.
produce them. In addition, the JDF Specification defines Job
Messaging Format (JMF), a messaging protocol for exchanging Response messages are synchronous replies to a Command, Query,
information between systems. The main objectives of JMF are Registration, Acknowledge,
or Signal.
transferring job data between systems, tracking jobs, tracking
Acknowledge messages are asynchronous replies to a Command ,
material consumption, and monitoring and controlling systems.
Query, or Registration
The main design principles of JMF share similarities with
Signal messages are events sent by a system when it reaches a
traditional messaging integration technologies, such as
certain state or when a specified interval of time has passed. For
Message-Oriented Middleware [9], and the Web Service [9]
example, a press may notify a MIS each time 100 sheets have
standards that emerged at approximately the same time as JMF.
been printed. A Query is used to specify what Signals a system
The experience and knowledge in the domain of system
should generate.
integration using messaging has been documented in several
pattern languages [1, 2, 8, 9]. A pattern language is a collection Figure 1 illustrates a message flow initiated by a Query or
of reusable solutions, patterns, that are applied to solve Command. Solid message lines correspond to a HTTP Request;
reoccurring problems in a specific domain—for example the dashed message lines correspond to a HTTP Response.
domain of messaging.
Table 1. JMF Message Families
HTTP HTTP Message

JMF Message Family
Request Response Pattern
Command
Query X
Message
Command
Command X
Message
Command
Registration X
Message
Document
Response X
Message
Document
Acknowledge X
Message
Figure 1. Example of a message flow initiated by a Query or Event

Signal X
Command Message
The messages Command, Query, and Registration are request Coupling

messages that initiate a JMF conversation, they are always sent
An important concept in software design is coupling. Coupling
in a HTTP Request. Response, Acknowledge, and Signal messages
is a measure of how dependent components in a system are on
are reply messages. However, only the Response message is sent
each other. Systems consisting of tightly coupled components
in a HTTP Response. Both Acknowledge and Signal messages are
are often difficult to modify because a modification to one
sent in HTTP Requests.
component in the system affects the other components that it is
Messaging Patterns tightly coupled to. Therefore, it is generally considered good
practice to design systems with as loosely coupled, decoupled,
Systems in a print production workflow that communicate using
components as possible.
JMF messaging must be capable of both initiating message
interactions and participating in message interactions initiated The notion of coupling can also be applied to system integration
by third parties. For example, an MIS submitting a job to a using messaging. Eugster et al. [8] have identified three
prepress system initiates a message interaction, which the dimensions of (de-)coupling in the area of system integration
prepress system must respond to. These two cases correspond to using messaging:
two fundamental message interaction patterns: the Send/Receive
pattern and the Receive/Send pattern [2]. • Time decoupling—the sender and receiver of a message
does not need to be active at the same time
A system that initiates a JMF message conversation applies the
Send/Receive [2] pattern. The system sends a request in the • Space decoupling—a message is sent to a symbolic address
form of a Command, Query, or Registration message to a third representing the target system, not directly to a target
party, and receives a synchronous reply in the form of a system
Response message. • Synchronization decoupling—senders do not block while
A system that receives a JMF request message from another sending a message and receivers are notified by a callback
system processes the JMF message and replies with the when a new message is available
processing results in a Response message. This corresponds to These dimensions of decoupling have been formalized by
the Receive/Send [2] pattern. Aldred et al. [1] and used by Buckwalter [3] to classify the two
In Figure 1 there are several occurrences of the Send/Receive communication models of JMF. This classification is
and Receive/Send message interaction patterns: System A summarized in Table 2. Besides the decoupling properties of
participates in a Send/Receive interaction; System B in both a file-based and HTTP-based JMF messaging, Table 2 also
Receive/Send and a Send/Receive interaction; and System C in a specifies the desired decoupling properties of a JMF integration
Receive/Send interaction. architecture that can be added to a system in order to allow it to
communicate using JMF messaging. The remainder of this
The six message families of JMF correspond to three message paper discusses the design of a hypothetical JMF integration
construction patterns documented in the pattern language of [9]. architecture, integration layer, which exhibits these properties.
The Command Message pattern is used to invoke a procedure in
another system. The Document Message pattern is used to
transfer data between systems. The Event Message pattern is
used to asynchronously notify systems of events. Table 1 lists
the JMF message families, their message construction patterns
and specifies whether they are transported in a HTTP Request
or a HTTP Response.
Table 2. Decoupling properties of JMF The Send/Receive message flow begins with a component in a
system sending a message. The proposed hypothetical JMF
Time Space Synchronization integration layer’s Send/Receive message flow consists of the
following steps:

Blocking send 1. A component sends a Command, Query, or Registration by
Blocking receive placing the message on an outbound queue, a Message Channel
[9], which is shared by all components sending messages. Each
HTTP-based Blocking send message put on the queue is equipped with a unique message
No No
JMF Non-blocking receive
ID, the destination address where the message is to be delivered,
and the Return Address [9] of the component sending the
JMF Integration Non-blocking send
Layer
Yes Yes
message.
2. A Smart Proxy [9] picks the message off the outbound queue
and stores the message’s unique ID and the return address of the
JMF Integration Architecture component that sent the message. The message ID is used as
Any system—MIS, prepress workflow, offset press, digital part of the Correlation Identifier [9] pattern that will later allow
press, cutting machine—that wants to communicate using JMF the proxy to route the message’s reply to the return address of
must implement some form of software layer that handles the the component.
sending, receiving, and processing of JMF messages. Figure 2
3. The proxy forwards the message to an Envelope Wrapper [9]
illustrates such a layer. A well-designed JMF integration layer
that wraps the Command, Query or Registration in a JMF envelope,
would shield a system’s internal components from the details of
thereby constructing a complete and valid JMF message. The
sending and receiving JMF messages and would provide a high
envelope wrapper then puts the JMF message on an outbound
degree of decoupling between a system’s components and the
delivery queue.
systems that they communicate with using JMF messaging.
4. A HTTP client picks the JMF message off the outbound
The approach proposed by this paper is to implement the JMF
delivery queue and sends it in a HTTP Request to the message’s
integration layer as a messaging architecture. The proposed
destination address—the URL of the system that the message
architecture is described using the pattern language of Hohpe
should be sent to. The JMF integration layer has now completed
and Woolf [9]. This pattern language provides the building
the delivery of the message on behalf of the sending component.
blocks to describe the different processing steps required of a
JMF integration layer. The pattern language also includes If the HTTP client fails to deliver the message to the destination
graphical symbols that represent its patterns. These symbols are address due to network problems, system downtime, or
used to visualize the proposed JMF integration architecture. whatever other reason, it retries for a specified number of times
or during a specified time period. If the JMF message still cannot
be delivered it is placed on a Dead Letter Channel [9] where a
system administrator can examine the message and take
necessary actions.
When the system that the message was delivered to has
processed the message it sends a synchronous reply containing
the processing results back to the HTTP client in a HTTP
Figure 2. JMF Integration Layer Response. The HTTP client extracts the JMF message from the
HTTP Response and places the JMF message on an inbound
The proposed JMF integration architecture is based on the JMF message queue for the JMF integration layer to deliver the
concept of Pipes and Filters [9]. Pipes, realized by Message reply back to the component that sent the original request.
Channels [9] or queues, are used to decouple components and
the various processing steps, filters, in the JMF integration 5. A special message processor that verifies the correctness of
architecture. Another central concept is that of message routing. inbound JMF messages picks the message of the queue. If the
Based on a message’s properties or some external stimuli, the message is invalid it is placed on an Invalid Message
message is routed through various processing steps before it is Channel [9] where a system administrator can manually analyze
delivered to its final destination—an external system or a the message to determine the fault.
component belonging to the system implementing the JMF If the JMF message is valid it is forwarded to an unwrapper—
integration layer. part of the Envelope Wrapper [9] pattern—which extracts the
A system’s JMF integration layer can be divided into two sub- JMF Response message and forwards the Response to the Smart
architectures: one for handling the Send/Receive [2] message Proxy [9].
interactions of the system’s components; and one for handling 6. The Response message contains the ID of the request that it is
the Receive/Send [2] message interactions of the system’s a reply for—the Correlation Identifier [9] pattern. Using the
components. Figure 3 shows the architecture of the proposed request’s ID the Smart Proxy [9] can lookup the stored Return
JMF integration layer using the symbols of pattern language [9]. Address [9] of the component that sent the request. The proxy
Although both Send/Receive and Receive/Send message flows then places the Response on the components inbound Message
are shown in Figure 3 this article focuses on the Send/Receive Channel [9].
message flow, the symbols inside the dashed rectangle.
Figure 3. Receive/Send (top) and Send/Receive (bottom) message flows through the JMF integration layer
7. The component that sent the original request (Command, as soon as the message has been placed on the JMF integration
Query, or Registration ) message is notified when a Response layer’s outbound message queue; and when a reply message is
message is available on its inbound queue. The component available on the component’s inbound message queue the
removes the Response message from the queue, correlates it with component is notified by a callback.
the corresponding request message by extracting the request
message’s ID from the reply—Correlation Identifier [9] The principle of a messaging integration layer is nothing unique
to JMF integration in the printing industry. Several other
pattern—and then processes the reply. The JMF integration
layer has completed delivering the reply message back to the industries use similar approaches to decouple system
component that sent the corresponding original request components from the details of message interactions with
external systems. In recent years, the concept of an Enterprise
message.
Service Bus (ESB) [4], a configurable infrastructure that
facilitates message processing, routing, and delivery, has
Conclusions become increasingly popular. In theory, the entire JMF
By implementing a JMF integration layer a system in the print integration layer presented in this paper could be realized with
production workflow—be it an MIS or software/hardware in an Enterprise Service Bus.
prepress, press, or postpress—can completely decouple it’s
internal components from the details of the message interactions References
with external systems. The only action required of a system
1. L. Aldred, W. M.P. van der Aalst, M. Dumas, and A.H.M. ter
component in order to send a message is to place the message Hofstede. On the Notion of Coupling in Communication
together with delivery instructions on an outbound queue and Middleware. Lecture Notes in Computer Science, Volume 3761,
wait to be notified when a reply is available on its inbound pp. 1015–1033. Springer Verlag, 2005.
queue.
2. A. Barros and E. Boerger. A Compositional Framework for
The component sending the message does not connect directly Service Interaction Patterns and Interaction Flows. Proceedings
to the message’s destination system and is not dependent on the of the Seventh International Conference on Formal Engineering
destination system being available at the time the message is Methods (ICFEM'2005), Manchester, UK, pp. 5-35. Springer
Verlag, 2005.
sent—the component is space decoupled and time decoupled
from the destination system. The sending component is also 3. C. Buckwalter. Integration Patterns Applied to Print Production.
synchronization decoupled from the destination system of the TAGA 2006 Proceedings, 2006.
message. The sending component’s thread of execution returns 4. D. Chappell. Enterprise Service Bus. O’Reilly Media Inc, 2004.
5. CIP4. JDF Specification Release 1.3, 2005.

http://www.cip4.org/documents/jdf_specifications/JDF1.3.pdf,
accessed March 2006.
6. CIP4. Interoperability Conformance Specification (ICS) Registry.
http://www.cip4.org/document_archive/ics.php, accessed March
2006.
7. CIP4. The International Cooperation for the Integration of
Processes in Prepress, Press and Postpress Organization (CIP4)
home page. http://www.cip4.org, accessed March 2006.
8. P.Th. Eugster, P.A. Felber, R. Guerraoui, and A.-M. Kermarrec.
The Many Faces of Publish/Subscribe. ACM Computing Surveys,
35(2), pp. 114-131. June 2003.
9. G. Hophe and B. Woolf. Enterprise Integration Patterns.
Addison-Wesley, 2004.
10. World Wide Web Consortium. Hypertext Transfer Protocol
(HTTP). http://www.w3.org/Protocols/, accessed March 2006.
Author Biography
Claes Buckwalter has a M.Sc. in Media Technology and Engineering
from Linköping University, Sweden, where he is currently a Ph.D.
student. Buckwalter’s research interests are integration technologies
and workflow automation applied to the graphic arts industry.
Buckwalter is also involved in the CIP4 organization where he is
currently chairman of the Tools & Infrastructure working group.

JDF-Printing White Paper

Uploaded by

Document Information

Original Description:

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

JDF-Printing White Paper

Uploaded by

Copyright:

Available Formats

Linköping Studies in Science and Technology

Thesis No. 1285

Integrating Systems in the

Integrating Systems in the

© Claes Buckwalter 2006

Department of Science and Technology

ISBN 91-85643-26-2 ISSN 0280-7971

Printed by LiU-Tryck, Linköping, Sweden, 2006

2.1 Print Production

Plates, Printed Printed

Figure 2-1 Overview of the production flow in a printing plant (inspired by

2.2 Job Tickets

2.3 Job Tracking

3.1 History and Prior Integration Standards

3.2 The CIP4 Organization

3.3 The JDF Specification and its Ancillary Specifications

4.1 Product Model

4.2 Process Model

4.2.1 Process Nodes

Figure 4-2 Process network

Figure 4-3 The ImageSetting process

4.2.2 Combined Process Nodes

4.2.3 Process Group Nodes

Figure 4-4 Gray Box for plate making

4.3.1 Resource Classes

4.3.2 Partitioning of Resources

4.3.3 Resource Linking

4.4 Comparison with other Workflow Models

Figure 4-5 Generic process/activity model

5.1.5 Management Information Systems

Figure 5-2 ICS Stack

MIS to Prepress ICS MIS to Conventional Printing ICS Binding ICS

Figure 5-3 Example of systems and ICSs

MIS to Prepress ICS MIS to Conventional Printing ICS

Figure 5-4 Example of system roles

5.3 MIS Managed Production

6.2 The Elk Framework

State Changes State Changes

Figure 6-2 Interactive Alces testing the Elk ConventionalPrinting Device

7.3 Paper III

A JDF-enabled Workflow Simulation Tool

• A communication protocol, named Job Messaging Format (JMF), for

2 Print Production Workflow

Figure 2-1 Systems in a print production workflow

A critical requirement for achieving an optimal print production

2.1 Job Definition Format (JDF)

Figure 2-2 A JDF Process

In addition to defining a workflow model, JDF also attempts to define all

However, most importantly—JDF defines what information should be

2.1.1 JDF Integration Technologies

Figure 3-1 Process Simulation with JDF Integration

A generic and reusable software framework that provides the services

4 The Elk Framework

Figure 4-1 Worker use case diagram

4.1.1 Messaging Gateway

4.1.2 Message Processor

4.1.3 Subscription Manager

4.1.4 Job Queue

4.2 Reference Implementation and Simulation Tool

document, needs to be proofed/approved before the next process in a

State Changes State Changes

Figure 4-2 Overview of the simulation tool's components

5 Conclusions and Future Work