This distribution consists of 3 main modules:
an adodb-recordset to xmlrpc-value (and viceversa) conversion module for adodb, forming the core of the library
an xmlrpc web-service server that provides the functionality of a SQL-to-HTTP proxy
an xmlrpc driver for ADODB that can be used to transparently connect applications to remote databases using the xmlrpc web-service server
Module 1 can be used stand-alone in any application; module 2 depends on module 1 and module 3 depends on both 1 and 2.
The above schema documents a typical usage scenario. We will refer to that image throughout the rest of the documentation.
part A is the database to be accessed by the client app. It can be any database supported by adodb
part B is the PHP-powered web service that lets remote clients access the database using xmlrpc function calls. It needs a php-supporting web server to run
part C is the client application, and is the most varying of the 3 parts:
it can be written in PHP and make use of the adodb xmlrpc driver (module 3 above). The programmer only needs to know the adodb api.
it can be written in PHP and make direct use of xmlrpc calls. The programmer needs to know the phpxmlrpc api and decode 'by hand' the recordset received from the db
it can be written in any other language than PHP, making use of an appropriate xmlrpc library
it can be part of a website as well as a stand-alone application
Needless to say, all 3 parts can reside on the same as well as on 3 completely separate physical servers (any combination is allowed).
A few usage cases:
A is SQLserver, B is IIS. They both reside on the same Windows 200 server. C is a PHP application running in Apache on Linux. Advantage: no need of ODBC drivers on the linux server
A is Sybase, B is Apache. They both reside on the same Solaris server. C is is a PHP application running as a service on a SCO Unix. Advantage: no need for recent Sybase client libraries when compiling PHP on SCO
A is Oracle, B is Netscape Fasttrack. They reside on different servers in the intranet. C is a PHP application running in Apache on a hardened Solaris in the DMZ. Advantage: instead of giving direct access to the internal database through the firewall separating the intranet and DMZ networks, only a (custom) port is opened for HTTP request