The initial motivation for this protocol was to provide more flexibility in the timing of the implementation of different versions of application and database programs. The result is much broader. It would, for example: allow databases to be shared remotely with little need to co-ordinated internal implementation specific details; allow moving databases to different operating systems and hardware platforms without changing applications; and facilitate the migration of data from one database program to another. The last could be accomplished by first implementing the protocol on both application programs and on the database programs. This decouples the applications from the specific database program. The migration can then take place without further changes to the application programs.
Using the protocol also has licensing implications which will be of special interest to organizations providing data to others: computers running the client programs would not in general be required to have a licence for the database software, since it runs only on the server.
It is hoped that eventually the application and database vendors will support the protocol so that end users do not have to absorb the fairly significant cost of supporting proprietary or specialized interfaces between applications and databases. This is interesting for vendors as well. They then only have one interface to support, which does not depend on a format or specification under the control of another vendor, and their product will be able to exchange data with other programs or databases. In the meantime, end user organizations can still realize support savings and reduce the risk associated with critical dependencies by implementing the protocol themselves. Examples with the code provide the essential pieces and it is hoped that organizations using the same applications or database programs will co-ordinate their efforts and also lobby the vendors to take over support.
This protocol is not a query language interface like SQL. The client program must provide an identifier for the object to be exchanged with the database.
The general idea is that applications can make requests to a server for information about a data object as well as for the data to be provided. The main type of information about an object is the structures which are available for transmitting the data. (If the application already has that information then it can make a direct request for a data object.) The implementation uses RPC's so it is supported on TCP/IP type networks like the Internet.
Constructive suggestions and comments are welcomed. I can be reached at pgilbert@bank-banque-canada.ca or by phone at (613) 782-7346.