In order to define the pipeline that defines a transformation the user drops components to the drawing canvas and then connects them up graphically using the connection tool.
The various components of the Koutra X-form fall into three main categories:
Simple pipelines can be defined with the elements above. But these pipelines are not terribly important from the point of view that they only provide one-on-one mapping between the input and the output. This is good enough for performing tasks like reading a file containing XML, transforming this XML into XSL-FO and piping through the FOP processor to generate a PDF file.
Suppose we want to do something more complicated: imagine we have a file containing information for multiple documents, one line for each document. We want to open the file, and for each line, convert the line into a simple XML document, transform this XML into XSL-FO, pipe this through the FOP processor to generate a PDF file, and finally generate a ZIP file that contains all the PDF files produced for the original file.
In order to support this functionality Koutra X-form uses the concept of demultiplexers (demux) and multiplexers (mux). A demultiplexer has a single input, but multiple outputs (it corresponds to the process of reading the orinigal file one line at a time and creating an XML document for each line in our example). A multiplexer on the other hand takes in multiple inputs and produces a single output (it corresponds to the process of reading the multiple PDF files and producing a single ZIP file in our example).
In order to support the definition of such a process through the designer, we also introduce the concept of a template. A template is much like a pipeline item, but it will be executed multiple times (as many times as the demux item generates content). It is not possible during the design time to know the exact contents that will run during a demux/mux pipeline, so graphically we represent this as a demux item followed by a chain of templates ending up to a mux item.
Finally in order to facilitate the execution of such demux/mux pipelines in a cluster of cooperating processes, we introduce the concept of a task boundary template. This is a template that does not itself perform a transformation of its content, but knows how to transfer its contents over a socket, and therefore over the network so that the pipeline that it delimits can be executed over the network at a different computer. In such cases the requirement is that there is a task boundary template right after the demux item and right before the mux item, in a demux/mux pipeline.