Dataworks Enterprise Architecture

Dataworks Enterprise is an extensible software component system designed and built specifically to support financial information systems.

The Component Set

Components are delivered in two forms, programmable objects and high-level application components. These components can be combined to form a wide range of sophisticated financial software solutions, from a database interface or a feed handler through to a large-scale set of financial applications.

The programmable objects are delivered in a dynamic link library (DLL) known as RTCache (the Real-Time Cache). Each programmable component is coded to the Component Object Model (COM) standards to maximise their use in a large range of programming and application environments. High-level application components are delivered as a series of small executables that are combined together at run-time using a specialised launcher application. The application level components communicate through the programmable object set.

Typically, each component is formed from more basic components in the set, creating sophisticated solutions from simple well-understood building blocks. For instance, The Publishing Server component, which is delivered as part of Dataworks Enterprise, is built directly from programmable components contained in RTCache.

Dataworks Enterprise components can be combined together in a wide variety of configurations to support a range of specific application solutions. For instance, the Cache components can equally be used in a Web server application, a browser or a Visual Basic project. Similarly, the distribution system component can be used directly by specialised application components.

In addition, the component set is inherently extensible. All Dataworks Enterprise components and programmable objects are directly accessible to customers. They can be used as a foundation to enhance and extend the basic object set.

Why Components?

Component architecture can provide significant benefits over the traditional custom or bespoke application development strategies when developing new systems. A substantial proportion of development costs can be attributed to human factors in development and to the cost of rollout and maintenance of software. Component systems can substantially reduce costs in both these areas.

The use of a component strategy encourages software re-use, which in turn reduces the number of software incidents associated with new systems. In a sense, component strategies encourage the use of well-tested code over untested code. By delivering systems based on commonly used components, system integrators and managers can maximise reliability at a relatively low cost.

From a maintenance perspective, component development can also offer benefits in terms of overall reliability. At the lowest level, components interact with the operating system through a series of basic system level objects. These interactions are, by nature, simple and predictable. Therefore, they can be verified using normal analysis and regression techniques. Since these system level objects are used in very tightly controlled circumstances, they are only exposed to the user via the components that use them. As a result, the components themselves are built on a very firm structural foundation.

In addition, the use of components can also help to focus human skills into areas where those skills are most efficient. For example, Dataworks Enterprise is delivered with a component that allows data to be placed onto a distribution system. The skills associated with interfacing with these systems are encapsulated within the component allowing in-house developers and integrators to concentrate on application functionality rather than the �plumbing�. Components allow system managers and developers to focus on their core business activities.

Dataworks Enterprise represents a new breed in financial software products being designed �from the ground up� and using a component architecture. Thomson Financial aims to exploit those benefits in its own software and to pass those same benefits on to its customers.

Dataworks Enterprise Architecture

Logical Architecture

When deployed, Dataworks Enterprise typically consists of a series of discreet process modules that communicate via the Cache. Each participating module employs components exposed by the Cache through standard COM methods. Customer functionality is typically implemented by creating additional application level modules that also communicate via the Cache.

Dataworks Enterprise Logical Architecture

For instance, one module supplied with the software is the distribution system plug-in. The purpose of the plug-in is to interface the Cache with a specific market-data distribution system or platform. Another component that may be installed is the publishing client module. This allows content from the local Cache to be propagated to a central publishing/contributions system. As each component connects to the Cache, they make their resources available to the Cache and consequently to the application programmer. The system is fundamentally extensible.

Each component is delivered as three files; a script file, an executable file and a configuration file. The script file (now legacy) describes how to run the component executable and was used by the original launch facility. The executable contains the component code. The configuration file contains default configuration information.

Process Architecture and the Launcher

In process terms, the architecture recognises two types of modules; user modules and system modules.

User modules are the applications used by individuals to interact with the market data. They are, typically, UI (user interface) applications launched by users of the system to perform application-specific tasks. In some cases, they may be controls or other in-process components. Some systems (�black box �solutions) do not employ any user modules.

System modules typically provide some service to the Cache, such as a connection to a distribution system or a system management tool. Typically all systems employ one or more of these system modules. To maximise flexibility (in deployment terms) and reliability, system modules are always implemented as process level components.

Thomson Financial provides a launcher process for these system modules known as RTLaunch. The task of the launcher is to run and monitor system modules and to close them down on exit. Application developers can also employ the launcher to launch their own applications where appropriate.

Dataworks Enterprise Process Architecture

When the launcher invokes the first process, the Cache is automatically brought into memory (of that process) and initialises itself including the shared facilities such as the internal messaging system. In addition, it reads some basic configuration information and initialises error logs, etc. As each subsequent process is brought online they too map the Cache into their address space. This causes the Cache to connect them to the shared facilities. Each time a process connects to the Cache, other processes are informed of the change.

During operation, the Cache constantly monitors itself (in all processes) for abnormal disconnection of a process and recovers its shared resources automatically (the OS recovers private resources). Equally, the launcher constantly monitors the state of each process. If any process exits, the launcher will restart the process up to a maximum of five times a minute (to avoid system thrashing on a repeatedly failing module). The launcher maintains logs of its activity for system administrators and other technical staff.

When a process disconnects (both normally and abnormally), the Cache immediately detects this condition and recovers the resources allocated to that process as well as informing the other connected processes of the disconnection. When the final process is disconnected from the Cache, irrespective of whether it is a system or user module, the Cache releases its internal resources prior to being unmapped from system memory.