What is DataSpider and what does it do?

DataSpider is a generic component based communication bridge to sit between programs and datasources DataSpider receives the message or request from the calling program and translates it to the format of the target program or datasource The target is called with the translated request and the result of this call is translated back to the format of the calling program and returned to it as reply message. This communication can be both synchronous and as an a-synchronous callback.

What programs can use DataSpider?

All dotNet programs can call DataSpider natively using the provided client
All COM+ compatible programs (Microsoft Office, Vb6, Delphi)
All programs that can call WebServices or Urlís
All programs that can use MSMQ
All programs with an external API
All programs with import and export facilities
Other programs might be suitable also depending on their capabilities

What are the advantages?

DataSpider uses the format and protocols of the bridged programs and datasources. Thus adaptations of these programs can remain limited, reducing the amount of work and time needed to realize the link
DataSpider is multi-threaded and can run multiple instances, making it at the same time both light-weight and still fully scalable for future growth of traffic and/or message size.
When something changes in the way these programs work, often only configuration changes are needed to keep the communication bridge working, making it very flexible
All traffic is logged and thus traceable, providing an audit trail
Encryption of the configuration is supported, hiding passwords and other sensible information in the configuration files.
Based on standard Microsoft technologies and thus benefits of regular updates from Microsoft for its main libraries and technologies

Normally each program creates itís own link to the datasources.
When something changes each and every link has to be changed too


DataSpider sits between the programs and the datasources.
When something changes only their references and definitions need to be changed


Components

Connectors service the link between the programs and the datasources
Each communication bridge consists of two connectors
Standard connectors for e.g. ODBC or FlatFiles are available
Custom connectors can be build for almost any target

Processors service the communication
Each processor can service several communication links

Translators perform the translations
A translator usually is specific for one communication link

The portfolio of standard components is continuously expanded and (depending on the purchased license) included in the regularly provided upgrades.

Implementation

For standard links only configuration settings are needed
For some situations a standard component doesnít exist yet. These can be build and added to the component portfolio
For non-standard links components have to be custom build
Develop your own components by referencing the libraries and inheriting from the base components in any dotNet or COM+ compatible language

Which companies benefit?

This will usually be at least medium sized companies with a more complex IT
infrastructure characterized by one or more of the following aspects:

Running several instances of a program
Running different programs and different technologies
Several different internal and/or external datasources
Multiple internal and/or external datasources
Regular changes of programs and datasources
Expected changes of protocols or technologies

These programs can be either client desktop or other server applications.