This page discusses how JDF-enabled systems communicate with each other.
A system that generates JDF data is called a JDF producer while a system reading and interpreting the data is called a JDF consumer. Of course there are systems that are both a producer and a consumer at the same time.
How do the two systems, a JDF producer and a JDF consumer, talk to each other?
Let’s first look at the ‘physical’ aspect of JDF communication:
- The easiest type of JDF communication is working hotfolder based. A folder or subdirectory on a computer is made accessible to both the JDF producer and consumer. The JDF consumer checks this hotfolder every few seconds. As soon as the JDF producer creates a JDF file in the hotfolder, the JDF consumer picks it up and processes it.
The advantage of this approach is that it is easy to set up and troubleshoot. The main disadvantage is that such an approach does not really lend itself to two-way communication.
- A more sophisticated way of communicating is using HTTP, the same protocol that is also used to transmit this web page to your browser. To be able to use HTTP-communication, both the JDF producer and consumer need to have a small built-in web server that handles the incoming and outgoing messages. Software developers don’t need to create such tools themselves. They can use tools like IIS from Microsoft or Tomcat, an open source alternative. Systems that support JMF always use HTTP.
Usually a JDF project starts with two systems exchanging data but before you know, other systems also get integrated and you end up with multiple systems exchanging job related data. How do these systems communicate from a logical point of view?
- In the early days of JDF, a lot of people assumed JDF communication would be a serial process. An application such as an MIS system would be used to define a job. It would send a JDF file about this job to the prepress system. The prepress system would interpret these data, process the job, add some data and pass the larger JDF to the next application in the chain. This system would do the same and an ever growing JDF file would contain more and more information about a job.
While this approach appears to be logical at first, it has different downsides which is probably why this approach never took off.
- Job progress isn’t logical or linear. Things may change at a very late stage, bouncing back from a press management system to the MIS system. Moving around a single file that follows the job is not possible. Sometimes things happen in parallel in two different departments or companies. It is extremely difficult to keep two or more copies of a file synchronised if various systems change those copies at the same time..
- If a single JDF file would be kept on a central server, the problem of read/write rights pops up: what if both the MIS and the prepress system want to alter the JDF at the same time? What if they both want to change the same data entry in the file?
- After a while that JDF file could become awfully big, especially if logging data are added. Retrieving data from a text file and writing data back into it is not a very efficient way of working.
- A number of vendors looked at a star topology: a single application acts as a JDF manager (or JDF robot or JDF hub) communicating with all other systems on a ‘need to know’ basis. Initially some companies tried to create dedicated software for this but I don’t think such systems ever made it to the market. Nowadays there are a few MIS systems that aim to become JDF hubs.
A centralised approach offers a number of advantages: There is no risk of data integrity conflicts with two systems using different parameters for a particular job setting since all data are centralised in one single system. There is one single point of contact in case of compatibility issues. System administration is easier.
Of course there are also disadvantages: The JDF hub needs to be able to handle the full spectrum of JDF uses which can be a daunting task. As a user you are placing all your eggs in one basket, both when it comes to data communication as well as when it comes to relying on vendors. How flexible is a vendor going to be when its system is also in charge of handling the data of a competitive product?
- Nowadays a lot of the JDF integration projects are point-to-point connections: an MIS system might communicate with a prepress system. It sends the same job description also to a press management system. The prepress system and press management system also exchange data using JDF.
- Nothing stops you from going for a hybrid configuration, a mix of a star topology and point-to-point communication. An example: an MIS system communicates with both a prepress system and a press management system. The prepress system sends ink key data to the MIS system which forwards theyse to the press management system. The prepress system also generates data for the finishing equipment but it passes these JDF along directly, without involving the MIS system.