|
This document describes features of the new product - Unicorn Application Server 3.0.
Unicorn Application Server 3.0 is a small footprint, high performance, document-centric solution with the low ownership cost, designed to provide the efficient integration of applications in the distributed computing environment.
Unicorn Application Server 3.0 is a small footprint, high performance, document-centric solution with the low ownership cost, designed to provide the efficient integration of applications in the distributed computing environment.
The product is a direct successor of Unicorn Print Server 2.0. Unicorn Application Server inherits the core architecture and all functionality of Unicorn Print Server. Numerous features are added in order to support functionality required for the efficient integration of non-printing applications. In particular, the extensive support is provided for XML-enabled solutions.
The product has open and extensible architecture. The rich set of features is available to support creation of custom components and to facilitate integration with the third party products.
Unicorn Application Server is designed to process client requests in the distributed computing environment. It is assumed that each request specifies a document with an additional set of parameters. There are no limitations with regards to the document content and format. In particular, the document may contain data to be processed (for example, the spool file in case of the print request) or the request itself encoded in some form (for example, using XML). Request parameters specify additional details of processing requested. In particular, the application needed to process the request must be identified in some way; other parameters may specify arguments required by this application (for example, every print request must specify in some way the name of a logical printer). It is assumed that the specified application is under control of the application server. The application may be implemented as an integral part of the server (for example, the printing engine or the XML processing engine) or be callable as an external component.
Clients may submit requests using various protocols. For example, print requests may be submitted with the usual printing protocols (like LPD). Alternatively, requests may be transmitted over HTTP (using, for example, Web browsers as clients). Furthermore, clients supporting CORBA may use that architecture for sending requests to the application server. Various submission protocols are supported by the print server gateways, which are responsible for receiving requests and registering them in the server database.
Requests received by the application server are stored as jobs in the server job pool. Each job represents an independent unit of work. Each job has an associated document and collection of attributes. Job attributes describe various characteristics of the job. In particular, parameters of the original request are stored as attributes. Furthermore, information about the current job state is stored in form of job attributes as well.
Jobs are processed by the application server asynchronously. Each job is scheduled for processing depending on its attributes (for example, job priority and submission time) and on the availability of resources. If requested, the response can be transmitted back to the client when the job processing is completed. Alternatively, the client can query remotely the server job pool, in order to examine the current job status.
More detailed description of the job processing can be found in the section 7. Architecture of this document.
Unicorn Application Server 3.0 provides the full backward compatibility with its predecessor, Unicorn Print Server 2.0. The entire printing engine is included as an integral part into the new product. The printing engine implements the complete functionality available in the previous versions of Unicorn Print Server. This feature provides the substantial investment savings for the present users of Unicorn Print Server, keeping the cost of migration minimal.
Unicorn Application Server provides the sophisticated set of features, which enable processing of documents represented using the Extensible Markup Language (XML). Although using XML is fully optional, customers can get substantial benefits integrating XML-enabling functionality into their applications.
XML was designed as a language for describing the document contents in the presentation-neutral form. The typical XML document provides a structured description of the document contents, which is not dependent on the way the document might be presented. Depending on the application, each particular XML document can be presented in various formats, for example, in PostScript format for printing, in PDF format for archiving, or in HTML format for publishing on the Web.
Unicorn Application Server provides the rich set of modules which implement various XML-enabling technologies according to the recommendations of the World Wide Web Consortium (W3C). Furthermore, several technologies supporting interoperability with non-XML applications are implemented as well. In particular, modules are available for generating XML documents from the contents of relational databases or from plain text files, for importing structured XML documents into relational databases, for automating external applications using the instructions extracted from XML documents.
The XML-enabling modules of the server support the full set of features available in Unicorn XML Toolkit.
Using XML-enabling features, Unicorn Application Server can be efficiently used to interact with XML-aware applications. Alternatively, the same features can be used to make legacy applications XML-aware at the low cost.
Unicorn Application Server supports presentation of XML documents using the Extensible Stylesheet Language (XSL) technology. With this approach, the concrete presentation of an XML document is defined using XSL stylesheets. Each particular stylesheet contains instructions describing the presentation of a certain document class in some particular format. For any particular document class, various stylesheets can be designed, providing different presentation forms and different rendering (for example, PostScript, PDF, or HTML) for every document of that class.
The XSL facility can be efficiently used for the purposes of document composition, replacing the older composition technologies supported by the previous releases of Unicorn Print Server.
The XSL support is provided using the Unicorn Formatting Objects engine, which is available as a standard module of the application server.
The XSL formatting engine can be efficiently combined with the printing engine of the application server, providing the facility for the production printing of XML documents. With this approach, clients submit XML documents to the server. The appropriate stylesheet is selected from the server stylesheet library based on the request parameters or on the document contents. The stylesheet is automatically applied to the original XML document; the result of formatting is delivered to the requested output device.
Unicorn Application Server is an extensible solution. The server functionality can be extended in several ways.
The typical server installation includes a collection of components running within the application server framework. If necessary, purpose-built components implementing the custom functionality may be developed and integrated in this framework.
Furthermore, many components of the application server are scriptable; that is, their behavior may be customized using scripts. Applications managed by the server may be represented as scripts as well. The product provides several embedded high-level scripting languages in order to support the rapid development of server-based applications. Currently supported are three languages: Python, ECMAScript, and Tcl. All supported languages provide access to the core server object model. Additionally, Python and ECMAScript implement built-in interfaces for all standard modules supported by the server (these modules are discussed in the section 6. Standard Modules), as well as interfaces to external databases (with ODBC) and external applications (with COM and CORBA). Scripts can also access programming resources provided by the standard libraries of the respective languages. For example, custom server graphical consoles can be designed with the graphical user interface toolkit Tk, available for Tcl and Python.
The core server object model is accessible using a simple yet powerful application programmer interface. The server object model design is inspired by the family of ISO standards (primarily ISO 9594 "The Directory" and ISO 10175 "Document Printing Application"). All jobs controlled by the server, as well as all entries describing the components of the server environment (for example, printers, applications, resources, etc.) are represented as objects, each object having an associated collection of attributes. The interface to this object model provides entry points for creating new objects (submitting jobs, adding environment entries), modifying attributes of existing objects, deleting existing objects (canceling jobs, removing entries), and listing objects and their attributes selected using certain criteria.
The interface to the core object model is available at several levels. The low-level libraries for C and C++ can be used by developers of the completely new server components. Alternatively, each scripting language supported by the server provides binding for this interface. Furthermore, the same functionality is exposed using CORBA; external CORBA-enabled applications can interact with the server engine, implementing, for example, custom job submission tools or managing consoles.
The library of standard modules is shipped with the product distribution. The custom solutions can be built from these modules, using the scripting languages supported by the server as integration tools. Additional modules can be created and added to the server module library by the third party vendors using the toolkits described in the section 5. Extensibility and Interoperability. This section describes standard modules currently available; new modules may be added in the future.
The printing engine implements the complete printing functionality provided by the application server; this functionality is equivalent to that implemented by the previous releases of Unicorn Print Server. There is no separate API designed to access the printing engine; instead, the printing process can be controlled via the core object model of the server, accessible from any supported scripting language.
The XML toolkit implements the complete functionality of the standalone Unicorn XML Toolkit, with included Unicorn Formatting Objects supporting the XSL formatting.
The PDF toolkit implements the collection of interfaces designed to read, analyze, transform and generate PDF documents.
The Unicorn file handler toolkit implements a lightweight database engine, which may be used when common relational databases are too heavy or too expensive.
All toolkits listed in this section are accessible from Python and ECMAScript languages supported by the server.
Client requests are received via the application server input gates and registered as jobs in the server job pool. This process is described in the section 2. Basic Concepts.
The lifecycle of every job consists of up to three phases: pre-processing, scheduling, and final processing.
At the pre-processing phase, each job passes through the chain of special components called pre-processors. Depending on the nature of each particular job, pre-processors may modify values of the certain job attributes and/or alter the contents of the associated document. In particular, default attribute values may be set; values for other attributes may be extracted from the contents of the associated document; the document content itself may be filtered depending on the attribute values. Pre-processing is selective; some pre-processors may consider only jobs of the certain classes, skipping all other jobs.
Once pre-processing of a particular job is completed, the job becomes eligible for scheduling. The special server component, called scheduler, is responsible for starting the final processing of jobs depending on their attributes. In particular, the priority and the submission time of every job, as well as availability of resources required for the job processing, are taken in account. Additionally, the client may set various attributes which affect job scheduling, like the suggested job starting time; the client may also assign the held state to the job, effectively making the job ineligible until explicitly released.
Once the job is scheduled for the final processing, it is acquired by the appropriate processor. Each processor is a component of an application server, implementing a particular application or class of applications. For example, all print requests are processed by the specially designed class of output processors, responsible for the delivery of documents to the requested output devices. Applications, which are not related to printing, are usually implemented as scripts in languages supported by the application server (see the section 5. Extensibility and Interoperability for details). These scripts can access built-in server modules (for example, XML and PDF toolkits) and databases, as well as standard library modules provided by the respective implementations of scripting languages (for example, if Python is chosen as a scripting language, the entire collection of Python extension modules can be used). Scripts can communicate with the external databases and applications using standard protocols (ODBC, COM, and CORBA). In particular, applications may generate new requests and submit them to the remotely running instances of the application server, thus implementing the distributed data processing.
Therefore, the typical installation of the application server includes one or more pre-processor components, one scheduler, and one or more processor components. Some pre-processor and processor components may be scriptable; that is, their exact behavior may be described by the standard or custom scripts. Scripts, as well as related resources (like XSL stylesheets) are stored in the libraries managed by the server; selection of scripts may be done dynamically depending on the actual values of job attributes. Typically, for each customer, the individual configuration of the application server is built from the available modules, depending on the customer requirements. The architecture of Unicorn Application Server provides the flexible framework for the integration of particular modules.
This section provides references to products and technologies developed by Unicorn Enterprises SA, which are used in Unicorn Application Server 3.0. For general information about Unicorn products and technologies, please visit the company's Web site at https://www.unicorn-enterprises.com
Unicorn Print Server 2.0. The detailed product description for Unicorn Print Server 2.0 is available at https://www.unicorn-enterprises.com/products_uxps.html
Unicorn Formatting Objects 1.02.00. The detailed product description for Unicorn Formatting Objects 1.02.00 is available at https://www.unicorn-enterprises.com/products_ufo.html
Unicorn XML Toolkit 1.00.00. The detailed product description for Unicorn XML Toolkit 1.00.00 is available at https://www.unicorn-enterprises.com/products_xmlkit.html
|