This is the fourth part in a series of articles where I'm going to describe the internal workings of the StreamServer.
This part will focus on the output pipeline of the StreamServer Runtime Engine.
We have in the previous articles covered how data is received and processed by the StreamServer. It is now time to take a look at how data is delivered.
Here is the image describing the relationship between the kernel and the output pipeline from the first article in the series.
The output pipeline is responsible for finalizing the data that the Process has created. It is designed in a similar way as the input pipeline. This means that it is a pipeline of components that implements a data flow from the kernel to the output queue. Each component can alter the data and then sends it to the next component.
The components in the pipeline are independent of each other it is possible to insert new components to create a pipeline that is tailored for a specific need. If the output needs to be sorted a sort component can be inserted and so on. This architecture makes up a very flexible system that makes adoption and new development rapid and robust.
What components that should be used are determined by looking at the information in the Execution Model. Examples of existing components that can be used include finishing objects for page oriented output, like OMR and Sheet layout, components, compression components and splitter components that can split output pipeline into two branches. The split component can be used to make a copy of the output and send it to a desired backup storage, e.g. an archiving system. The available processes are internal to the StreamServer (the older ones) or SCF services that can be invoked for example Adobe XFA or Storyteller Composition engine. This document only discusses the internal processes.
For page-oriented output generated from the PageOUT process a device driver must be used to create the final output format. This must be taken care of in the output pipeline because it is first here that the server knows which output connector that will receive the output and the device driver is connector dependent. The reason it is connector dependent is that the connector often points to a receiving device and this device normally only accepts only one format. The device is implemented as an output pipeline component that is only inserted when the output is sent from a PageOUT process. The output sent from the PageOUT is device independent in form of a sequence of commands that the device driver should implement and execute. The driver is implemented in a loadable module (see section Input Pipeline). The device driver will accept the commands from the PageOUT and create device formatted data that it will pass on to the next component in the pipeline.
The last component in the output pipeline is always a component that writes the data to an output queue.
The Output Queue stores the documents created before they are actually sent. It queues up documents in the case that more documents are created by the server than it can send. In case of an unexpected server shutdown during execution it also provides robustness since it has the ability to reprocess the documents when the server is restarted. It is also possible to manually resend documents using StreamStudio.
Several servers can share the same output queue. This provides possibilities for scaling over multiple servers.
The Output Connectors are responsible for sending the output to the final destination. There is one output connector for each communication method supported.
The Output Connectors are only responsible for delivering the data to its destination, they don't format or analyze the data. The connector polls the queue and when it finds something to deliver it just reads the data and tries to send it. If it fails it can be configured to retry. The output connectors are services provided by the SCF but setup and created runtime by the StreamServer based on its configuration from Design Center.
The topic for the next article will be the Post Processor.
InDepth Part 5 - StreamServer Runtime Engine - Post Processing