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. 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. 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. 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.Dataworks Enterprise Architecture
Dataworks Enterprise is an extensible software component system
designed and built specifically to support financial information systems.
The Component Set
Why Components?
Dataworks Enterprise Architecture
Logical Architecture
Process Architecture and the Launcher
