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.