The main purpose of the TFS Hub is to allow data sources to be shared among
multiple customers in a properly permissioned and auditable manner. The central
technology in use is Dataworks Enterprise. The hub itself is implemented as an expandable number of boxes connected using
TCP/IP virtual circuits in a LAN environment. Most of the boxes attached to the
hub are dedicated to ingest or distribution of data. The hub itself in the
diagram is more conceptual than physical. Dataworks Enterprise Handlers ingest data from various TF or external data
providers. These sources are made available to downstream clients in the form
of Dataworks Enterprise sources. As each handlers makes data available it
attaches permissioning information to the data so that downstream clients can
choose whether the individual user has access to the data. In many cases, the
actual sources of data might be arrays of TF data server, such as GT data.
Dataworks Enterprise provides support for load-balancing between these sources
using Hydra (and, later Freeway). Some sources will initially be �un-permissioned� relying on facilities within
the remote server to apply source level permissions to the source. For
instance, if a client needs access to a set of WorldScope data, they may have a
specialised source created for them that is hidden from all other customers.
The customer need not be aware of this operation. In the long term all sources
of data should be permissioned in the hub. Internal distribution within the hub will use TCP virtual circuit technology in
the first instance using standard Remote Server/Client technology. At some time
in the future, the distribution technology in the hub will be based on Freeway
for performance and scalability reasons and to simplify management of the hub. By sharing data in the hub, we should be able to increase the reliability of
data without incurring substantial additional costs. The central tail circuit distribution technology is TCP virtual circuits
supported by standard Dataworks Enterprise Remote Servers. Dataworks Enterprise
Remote servers provide configuration options that allow them to show/hide or
rename Dataworks Enterprise sources according to groups depending on peer
connection addresses. At some time in the future, this data will be centralised
into the permissioning server to ease the cost of implementation. The Remote Server that provides the tail circuits are either shared between
customers or are private to them depending on customer requirements, cost, ease
of implementation, etc. Apart from ingest and tail circuit technologies the hub supports a central
permissioning server (and its associated SQL Server database), This server (a
hybrid Dataworks Enterprise handler) holds permissioning information for
accounts that access the hub. NOTE: this may not the same as accounts that may
be accessing data for management and efficiency reasons. Dataworks Enterprise
permissioning system is a fully distributed permissioning system that can
integrate various permissioning models in use in TF. The simplest customer configuration would be entirely hosted within Monmouth
house. This solution would either be providing some external API (XML/HTML) or
might form part of a hosted web/wap solution.TFP Hub Configurations
This document is meant to provide a road map for the planning
and implementation of TF Dataworks Enterprise solutions for customers relying
on a basic shared data environment known as the TF Dataworks Enterprise hub.
This document is intended to help Thomson staff understand what the Hub is,
what it is for and how it can help in the rollout of various specific solution
types.
The TFS Hub
Customer Configuration One
In this environment, the remote server(s) may be either shared between customers where bandwidth/CPU resources allow or may be allocated on a per customer basis. Downstream clients accessing the shared data must be permissioned appropriately in order to use it. This might involve one or more user accounts within the central permissioning server (depending on the particular roles for those accounts) and may have oone or more downstream accounts associated with users of the shared data. Where there is a one to one mapping between roles and accounts, the permissioning information will be held on the hub permissioning server. Where there are many downstream accounts connecting to a small number (or one) upstream account, the architecture allows the use of a Permissioning Proxy that translates from one to the other.
In some cases, the data provided may be �summarised� in this configuration, depending on customer requirements. This will be achieved using Dataworks Enterprise Snapshot solution or something similar.
This type of solution is managed and maintained by central systems support staff such as TICCS FM, TICCS Real-Time Support and WAN Support.
Customer Configuration Two
In the second configuration, some part of Dataworks Enterprise system is installed at the customer site. Again the permissioning is distributed to the host on the customer site (which probably has implications for SLA boundaries). As with the first case, data is access from the Hub with the appropriate permissioning information.
Configuration Two: Solutions
Implemented at the Customer Site
In this case, central systems are managed and maintained as they are for the first configuration. However, the equipment and software at the customer site may either be managed by the customer or by field services depending on costs and customer requirements.
As with the first configuration, there may be use of the Permissioning Proxy at the customer site, to handle variations between on-site and central user accounts or simply to provide localised caching of permissioning information.
As with configuration two, the data provided may be �summarised� in this configuration, depending on customer requirements.
Customer Configuration Three
In the third scenario, the customer demands non-shared data (or we decide that for implementation reasons this is more appropriate). Generally, for customers in this category we will endeavour to move them to configuration two or four depending on requirements.
In this case, some private data resources are made available to the customer possibly with the addition of hub-based shared resources. Where the latter is the case, the customer must be permissioned to receive that data. The private resource may or may not be permissioned as appropriate depending on the downstream requirements of the customer. For instance, if they have a permissioning requirement for heir users then the source has to provide the permissioning information at the point of ingest.
The management of the central systems will, as usual, fall into the respective groups who maintain Monmouth systems, e.g. TICCS FM, WAN Support Team, TICCS Real-Time Support, etc. The support for customer site systems will be provided either by the customer or by field services depending on requirements.
Configuration Three: Some Customers
Demand Private Access to particular data sets
Customer Configuration Four
In this configuration, some private data is made available directly on the customer site. This may be because the data is external to TF or it may simply be a matter of delievery costs and bandwidth requirements. The most obvious case is the real-time distribution of GT data. This may be better provided using broadcast satellite to the customer site rather than distributing the data across the normal circuits.
Configuration
Four: Some Data needs to be integrated at the Customer Site
It is likely in this case that there is a back path circuit for the delivery of other kinds of TF data, e.g. DataStream, Intraday pricing, using the standard RemoteClient/Server technology. If a client demands this level of support, it is likely that they will have a number of central system accounts and a larger number of user accounts downstream. The Permissioning Proxy will resolve these issues at the customer site.
Support for the customer site systems will depend on the requirements of the customer, the location of the SLA boundary and the needs of TF, but would normally be provided by field services.
Support Issues
Dataworks Enterprise Support Team are relying on field services to provide support for:
- Hardware
- Operating Systems and Services
- Communications Infrastructure
- Remote Access Support
Support for Dataworks Enterprise software should be provided by specially trained individuals such as Thierry�s group (assuming the appropriate FSA accreditation) and as a second or third tier by Dataworks Enterprise Support.
Support in Monmouth house would continue as at present.