Major features of Transformation Server include:
Service-oriented architecture that allows your application to control export operations with complete isolation from the memory and execution space of the export process, for maximum fault tolerance.
Multiple interfaces - Transformation Server includes interfaces in C/C++, Java, or the SOAP protocol.
Process management - Transformation Server can monitor its export processes and will restart them in the event of an exception or an infinite loop.
Support for all of the Outside In Export SDKs.
A published add-on interface that allows the developer to implement custom input/output.
A published add-on interface that allows customer or third- party export code to be integrated into Transformation Server.
There may be references to other Outside In Technology SDKs within this manual. To obtain complete documentation for any other Outside In product, see:
and click on Outside In Technology.
This chapter includes the following sections:
The updated list of supported formats is linked from the page http://www.outsideinsdk.com/. Look for the data sheet with the latest supported formats.
Support has been added for Oracle Linux x86-64 R7.
Transformation Server consists of several components that interact with each other and your application. Some of these components are optional, depending on the way you wish to configure your application.
This is an executable that hosts the Outside In Export SDKs. It is controlled through a SOAP version of the Outside In Export APIs. This executable can be used directly by an application or an application server, or accessed indirectly through the Transformation Manager.
The Transformation Manager is an executable that is used as a central controller for Transformation Agents. The Transformation Manager controls a pool of Transformation agents, each of which is used to perform Export operations. The Transformation Manager presents the same SOAP version of the Outside In API as does the Transformation Agent, and will manage a queue of transformation requests. The Transformation Manager also monitors the status of Transformation Agents, and will kill and restart an agent if it has become unresponsive. If your application already has app server functionality, you may decide not to use the Transformation Manager.
This module allows an application written in C to control Transformation Server through a C API that resembles the embedded version of the Outside In C API as closely as possible. This module handles all SOAP communication between an application and Transformation Server, and is the fastest way to migrate an existing application from using the embedded version of the Outside In SDK to Transformation Server.
The Java client is a set of JAR files that provide objects that represent a Java version of the Outside In SDK API, and handle all SOAP communication between a Java application and Transformation Server. This client allows a Java application to use Transformation Server without the need to write any C/C++ code.
This section describes the system software architecture.
Client applications control document transformations by communicating with an application called the Transformation Manager, which itself manages a pool of processes called Transformation Agents (see The Transformation Agent).
The following ilustration depicts this communication.
Requests to transform documents are distributed among the available running Transformation Agents. If all available Transformation Agents are in use, transformation requests are queued until an agent is available.
The interface that controls transformations is called the Transform API. The Transform API provides the means to initiate a transformation and pass parameters to the technology that will perform the transformation.
The Transform API is accessed via SOAP messages, through C-language function calls using the C Client Module, and /or through Java methods presented by the Java Client object.
The Transformation Agent (TSAGENT) is the worker process in which a transformation actually occurs. Transformation Agents host the available Transformation Engines and Input/Output Providers.
The following illustration depicts the transformation agent.
Transformation Engines and IO Providers are loadable modules (DLLs) that execute within the Transformation Agent process.
The C language interfaces between the Transformation Agent, the Transformation Engines, and IO Providers are fully documented in this guide.
Combined with the extensibility of the Transform API, this allows third party repositories and transformation technologies to be incorporated into Transformation Server without any changes to the infrastructure itself.
Transformation Server's SCCTS client module runs inside an application's process, and presents a C language interface through which the application can invoke all of the functionality of Transformation Server. SCCTS will provide all of the SOAP/HTTP communication, and will support the same IO Provider API that is available on the server.
If an application provides custom IO on the client side, the interface module will marshal IO operations between the client process and Transformation Agent, over a socket connection.
For a developer, the only difference between implementing an IO provider on the client versus on the server is that client-side IO provider code is not required to exist in a shared library or DLL, and is invoked through the Transform API rather than a configuration file.
Much like the C/C++ client module, the Java client object provides a Java version of the Transform API (see Initiating Transformations Using the Java API) that allows an application to access Transformation Server directly through code, rather than through the SOAP protocol.
The Java client object will handle all of the SOAP communication with Transformation Server, and will return the results back to the calling application.
If the client application developers wish to provide their own Java-based input/output, they may do so by implementing the Java version of the IO Provider API. (Note: the IO Provider API on the server side is C-based only.)
Each Outside In product has an sdk directory, under which there is a subdirectory for each platform on which the product ships (for example, ts/sdk/ts_win-x86-32_sdk). Under each of these directories are the following three subdirectories:
redist - Contains only the files that the customer is allowed to redistribute. These include all the compiled modules, filter support files, .xsd and .dtd files, cmmap000.bin, and third-party libraries, like freetype.
sdk - Contains the other subdirectories that used to be at the root-level of an sdk: common, lib (windows only), resource, samplefiles, and samplecode (previously named 'samples'). In addition, one new subdirectory has been added, demo, that holds all of the compiled sample apps and other files that are needed to demo the products. These are files that the customer should not redistribute (.cfg files, exportmaps, etc.).
In the root platform directory (for example, ts/sdk/ts_win-x86-32_sdk), there are two files:
README - Explains the contents of the sdk, and that makedemo must be run in order to use the sample applications.
makedemo (either .bat or .sh – platform-based) - This script will either copy (on Windows) or Symlink (on Unix) the contents of …/redist into …/sdk/demo, so that sample applications can then be run out of the demo directory.
The following notice must be included in the documentation, help system, or About box of any software that uses any of Oracle's executable code:
Outside In Image Export, PDF Export, Search Export, XML Export, HTML Export © 1991, 2015 Oracle.
The following notice must be included in the documentation of any software that uses Oracle's TIF6 filter (this filter reads TIFF and JPEG formats):
The software is based in part on the work of the Independent JPEG Group.