Data Distributor  Full Story

 Full Story

 Features

 Concept

 Prices & Options

 Download

 

Have you been pulling your host data when you should have been pushing it?

Data Distributor introduces a new generation of capabilities for serving data. 

Quick Links

 The Advantage
 The Pull
 The Push

Data Distributor provides centralized, visual management of PC users' predictable host data needs for queries and reports. It seamlessly replicates between DB2/400 physical/logical files, SQL and Oracle tables/views. Data Distributor also replicates to Access tables, Excel spreadsheets and importable flat files.

Data Distributor is Internet enabled, capable of working with any machine connected to the Internet.

Data Distributor also allows AS/400 and Oracle hosts to fully integrate with Microsoft's enterprise-strength database replication capabilities. Data Distributor seamlessly integrates with the SQL 7 Distribution Server to enable bi-directional, transactional data replication between AS/400, Oracle, SQL and mainframe databases.

Data Distributor runs on Windows 95, 98, NT workstation, NT 4+ and 2000 platforms. It utilizes host-based components to improve performance and reduce software requirements. Data Distributor typically replicates data at over 65 megs/min. It can achieve over 170 meg/min on high-end hosts and networks.



The Data Distributor Advantage

The most common ways of accessing host information involves the client pulling the required information from the host, as in this example

Data Distributor produces significant administrative and performance advantages by having the host push predictable, repetitive information to the clients.

The push can be accomplished for both static LkOutS.gif (70 bytes) and volatile LkOutS.gif (70 bytes) data. So if you have a system that works like this LkOutS.gif (70 bytes), Data Distributor will help it hum along like this LkOutS.gif (70 bytes)



The Pull

A pull replication is initiated by the user's machine. It manages the extraction of information from the host. ODBC, OLE-DB, DAO, ADO and Microsoft APIs are all pull replications.

Pull replication was designed for, and shines doing, ad hoc requests: ones unlikely to reoccur anytime soon. Pull replication shows design stresses when used for the predictable, repetitive data requests that constitute 75% to 90% of a typical enterprises' queries.

Pull replication brings the full weight of its ad hoc engine to bear on each and every request, no matter how often or concurrently that request is made. Pull replication also imposes a processing load on the host when the request is made. This generally corresponds to the busiest time of the day, when host resources are needed for line of business processing.

Since pull replication allows each user machine to access the host data, security procedures must be kept current on both the host and user machines.  The security exposures are well known.

Pull replication is also not centrally administered. Each user machine must be configured properly, and it must have a current version of the queries to be made. This causes significant administrative overhead.

And finally, with pull replication there is no central repository administrators can refer to see what information their hosts serve to which applications and to which user machines. That information is distributed within the user machines themselves.



The Push

An alternative to pull replication is possible for the 75% to 90% of data requests which are both predictable and repetitive. The host machine can know which user machines require what information by when. The host can prepare that information and initiate the data transfer. The host caches the results in a mutually agreed location convenient for the user machine to access.

This is called push replication. The user machines will still pull the data into their applications, but from the local store rather than from the host.

Push replication has several advantages:

  • Since the data as of this morning is generally good enough for most queries and reports, the push can be done at night when host resources are available.

  • Once the data is pushed, no further processing is required by the host, no matter how many user machines refer to the data, no matter how often.

  • The administration of what to push, and where, is done centrally, reducing administrative overhead.

  • Since fewer applications access the host, security is improved.


However you don't get all this for nothing. Push replication does require administration to identify repetitive requests, to define them to the host, and to route the applications to refer to the data cache.