doc.developer.deployment-overview.html Maven / Gradle / Ivy
DAISY Pipeline - Deployment Overview
DAISY Pipeline - Deployment Overview
-
Fundamental deployment options
-
Typical uses of a desktop-side deployment
-
Typical uses of a server-side deployment
-
On Global and Local Functionality
-
Extensibility via localization of existing Transformers or Scripts
-
Extensibility via Transformer or Script development
-
On Existing Infrastructures and Business Logic Layers
-
On User Interfaces and Targeted Builds
This document discusses overarching themes related to deploying the DAISY Pipeline within an organisation.
Target audience: system integrators, administrators, developers
Latest update: 2007-11-26
Fundamental deployment options
As defined in the original system requirements document of the DAISY Pipeline project,
the tool is designed to allow deployment in both desktop- and serverbased environments. This means that the tool
- can be used as a standalone desktop application, providing transformation utilities in production environments
- can be used as a service provider to other desktop applications
- can be used as a webservice, with public or intranet access
The choice of which of these deployment options to use obviously varies with which parts of the Pipeline functionality is to be exposed, and the nature of the clients.
Typical uses of a desktop-side deployment
- Use as a conversion and utility tool during XML document preparation
-
Many organisations within the DAISY community engage in creation of XML documents that serve as a basis for output formats such as DTBs, E-text, Braille etc.
Via its support for (for example) RTF, ODF, and WordML as input formats, the Pipeline can serve as a utility tool for creating XML masters (typically, but not restricted to, the
DTBook format), and then manipulating/converting these further, either to enrich the master quality, or to create concrete output formats via automated processes.
- Use for manual creation and manipulation of DTBs (and other types of filesets)
-
As the DAISY Pipeline scope includes both processing of singular XML documents as well
as filesets (such as DTBs), much of the functionality in the Pipeline pertains to DTBs, and includes functionality that targets pre-production, production and
post-production stages. The Script and Transformer summary should give an overview of what the DTB-related processing options are.
- Use for validation
-
The validation framework built into the DAISY Pipeline supports many content types and all standardized Schema languages. As such, the validation framework can be
used to perform canonical validation of XML documents and DTBs, but it also supports the addition of local (organisation-specific) subset rules.
The general philosophy regarding validation within the Pipeline is to strive to integrate validation seamlessly into production flows, by removing the need to
use separate applications for validation. This means that validation is typically integrated into other Scripts as a last (and/or intermediary) step. However, the Pipeline
can be used for validation-only purposes as well.
- Use for content migration and maintenance
-
The DAISY Consortium is during 2007 and 2008 investing in the "DAISY Content Migration and Safety Suite", a subproject within the Pipeline which (by building on the already existing validation framework)
will provide functionality relating to content migration and repair. The migration aspect of this project will deliver tools to move DTBs between differernt versions of the DAISY standard
(such as upgrading a Daisy 2.02 DTB to Z3986 for longevity and archival purposes, and "downgrading" a Z3986 DTB to Daisy 2.02 (for distribution purposes). A migration suite for DTBook documents will
also be provided, as well as a "repair" utility (available in a first version in the December 2007 release of the Pipeline) for DTBook documents.
Typical uses of a server-side deployment
- Intranet high-speed TTS DTB renderer
-
The Narrator Script within the Pipeline is a highly configurable XML and TTS-based DTB production system
that is built to support scalable high-speed rendering server-side.
- Public or restricted conversion services
-
Parts of or all transformation services within the Pipeline can be exposed either publicly or to a restricted set of users (say, within the context of a university) to process and/or create various types of output media from a single input document.
- Distribution-time output media creation
-
The Pipeline can be integrated as a transformation service provider at distribution time, allowing the distributed media to be dynamically taylored for a particular user or a particular user group.
- Delivery-time input media control and manipulation
-
The Pipeline can be integrated as a service provider at input media delivery time, acting for example as a gateway for a centralized storage area that receives different types of input from multiple locations.
- Public or restricted validation services
-
The validation framework of the Pipeline can be exposed online to allow a set of distributed production agencies to have a single point of entry for content validation.
On Global and Local Functionality
The default (and publicly available) functionality of the DAISY Pipeline has been written to be globally applicable.
Many times (and thanks to the fact that we are using standards), this functionality can be directly transferred and used within
a local organisational context. However, there are cases when localization and/or functionality additions
are needed to allow a Pipeline deployment to reach its full potential.
Extensibility via localization of existing Transformers or Scripts
A majority of the Pipeline Transformers have been written to allow localization via extensions or via provision of external behavioral guidance configurations.
Some of these extensions can be realized using only script parameters; others will need the intervention of a systems admin or a developer.
The localization features are typically described in the Transformer documentation. As an example, see Localizing and customizing Pipeline Narrator.
Extensibility via Transformer or Script development
When the default Pipeline functionality does not cover all local needs, the solution is to develop one or several local Transformers (which, if they have use cases outside of your own organisation, you may choose to contribute back to the public).
Sometimes, it is enough to append or replace a Transformer in an existing Script; sometimes an
entire Script (with one or many transformers referenced) is needed.
A Pipeline installation can contain any combination of public and organisation-specific Transformers and Scripts. A Pipeline installation can also contain any combination of free and commercial Transformers and Scripts.
Developers, please see the Transformer Authoring Guide for more information.
On Existing Infrastructures and Business Logic Layers
The Pipeline is written to be a context-agnostic tool to be deployed within varying technical and business infrastructures.
As such, it naturally does not provide nor impose any business logic layers; such layers must always be provided locally.
On User Interfaces and Targeted Builds
The Pipeline ships with a set of prebuilt interfaces:
-
The Pipeline Desktop GUI (delivered May 2007). This is the default Rich Client GUI, targeting desktop usage. This GUI is a separate project from the "Pipeline Core".
-
The Pipeline Command-Line UI (delivered spring 2006). The is the default command line interface, integrated into the Pipeline Core, targeting non-graphic desktop usage and integration into simpler application contexts.
-
A browser-based UI (delivered spring 2008). This is a part of the turnkey server deployment kit that is being made available during 2008.
In some circumstances, it is desirable to provide distributions which limit the functionality of the Pipeline for a certain use case,
and which provide a user interface taylored for that limited functionality.
The Pipeline can be made to accomplish this by doing the following:
- Provide a target subset build, which simply "filters out" any Transformers and Scripts that are not needed. This is achieved by (cloning and) manipulating the Pipeline "makefile" (which is an Ant script).
- Provide a specialized UI, either by customizing any of the UIs mentioned above, or by writing a separate standalone UI.