advertisement

Print

RSDP: A Really Simple Proposal
Pages: 1, 2

A Really Simple Proposal

As specifications go, RSDP is about as simple as it gets; almost simple enough to squeeze onto a cocktail napkin.



Incoming Query

An RSDP server should expect to receive either an XML-RPC (machine-machine) or HTTP/CGI (human-machine) query. The server will listen on two user defined ports, one for HTTP, one for HTTPS.

If the client opens the base URL for the server, the server responds by serving an HTML form that allows the user to interact with the server manually. This is provided so that users can interact with the server manually. It need not be an especially pretty interface, just sufficient so that developers can submit test queries that mirror XML-RPC queries. This will be helpful for troubleshooting purposes.

If the client submits an XML-RPC query, the server should present a single XML-RPC method, rsdp(), which is invoked as follows:


rdsp(dbname, username, password, querytype, query, strict, outputformat)

rsdp("books","brian","password","sql","SELECT * FROM books WHERE 
  author = 'Brian McConnell' ORDER BY pubdate;'",false,"xml")

NOTE: this instance of rsdp() invokes a SQL query, but the 
querytype param allows other query languages such as XQuery 
to be used as well.

The RSDP server then invokes the query expression, after first validating the user. The server is responsible for implementing security policies (for example, access control lists, IP filtering, etc.) internally.

Result Set

If the client is interacting with the server via the HTML form interface, the server will present records within tables, perhaps with a hyperlink to display the same recordset in XML.

If the client is interacting with the server via XML-RPC, the server will reply by either returning an error code, or by returning an XML recordset, as shown in the example below (data types are omitted for brevity). If the optional strict parameter is true, the server returns strictly typed XML, using the basic data types defined in the XML spec. If false or omitted, the server returns loosely typed XML and assumes the client application will perform any necessary data type conversions. The outputformat parameter allows the client to request other formats besides XML, such as CSV, HTML, and so on.


<recordset>
<count>X</count>
<record>
<recid>1234</recid>
<firstname>John</firstname>
<lastname>Doe</lastname>
</record>
<record>
....
</record>
</recordset>

Implementing RSDP should require a minimal effort on the part of database vendors. If vendors are slow to do this, developers can build scripts to provide this functionality in the interim. Since it is trivial to build XML-RPC web services in languages like PHP, developers need not wait for vendors to ship direct support for RSDP and can build their own solutions. In the long run, it will be best if vendors support something like this directly, as they will be able to optimize the interface for performance, as well as to implement security features within the database engine (rather than rely on an external script to intercept malicious SQL commands).

Class Libraries and Wrapper Functions

Using RSDP in client-side applications will generally be quite straightforward, since most languages now support XML-RPC.

Developers can further simplify the interface by writing small class libraries or wrapper functions that make the XML-RPC interface look like a conventional database API.

For example, one might create a rsdp class in Python that exposes a set of methods such as:

  • rsdp.execute(): Execute SQL query.
  • rsdp.forward(): Skip forward one record.
  • rsdp.back(): Skip back one record.
  • rsdp.first(): Jump to first item in recordset.
  • rsdp.last(): Jump to last item in recordset.

This approach will provide developers with something that looks and behaves as expected, while also providing an additional layer of idiot-proofing. In fact, the class will just submit a query, store the results, and provide the same type of cursor methods found in existing database APIs. This won't improve performance, but it will make the interface to RSDP consistent with conventional APIs. This will also ease the transition to vendor-specific interfaces if a project outgrows RSDP.

Summary

RDSP, or whatever it ends up being called, will not replace current database access protocols, but it will have an important role to play in rapid application development, and in distributed applications.

As I mentioned earlier, databases are easy enough to work with, after you've installed the DB server and necessary middleware to communicate with it. The problem with currently available tools is that it is difficult to build distributable packages that use client/server databases. While it is certainly possible to build packages that automatically install and configure the necessary components, doing so requires a lot of time and effort that could otherwise be spent refining the application itself.

While it will not solve SQL compatibility issues between vendors, an interface like RDSP will eliminate the need for an application to be tightly coupled with database middleware (for example, ODBC drivers in Windows, a MySQL package for Perl, etc). This will save time for developers, who will not have to spend so much time on installation scripts, and for users, who will not have to fight with as many database configuration issues.

RSDP will also enable ASPs to host database services, much as companies currently host websites, blogs, and the like. While it may not scale well enough for enterprise applications, this will certainly be viable for most small- and mid-sized projects. Moreover, if the interface proves popular, I think it is likely that people will find workarounds to the performance issues that are likely to arise (for example, by using HTTP load balancing to spread workload around among the servers answering read-only queries).

Next Steps and Neat Tricks

What is the next step? RDSP front ends can be built with or without vendor participation. To further this end, I have created a wiki where people can post documentation and pointers to RSDP implementations for various database engines. If this takes off, hopefully vendors will follow up by embedding RDSP-like support in their systems.

Apart from simplifying database access, RSDP has the potential to be the equivalent of RSS on steroids. RSDP calls embedded within web pages could link to many different databases to merge dynamic content into web pages.

For example, imagine a website that covers upcoming events. RSDP would make it easy to display event information. One would simply embed a statement like:


rsdprss("events","guest","password","sql","SELECT * FROM calendar 
  WHERE startdate >= #20050402# AND startdate <= #20050502# 
  AND category = 'movies' ORDER BY startdate;")

The web server queries the database server and imports the recordset as an RSS feed. Thus, people would be able to create websites that pull content in using specific search criteria from many different sources. This is just a simple example of how you might do this. Once you make databases more readily accessible, there are all sorts of potential applications.

More Information

For more information, documentation, and source code for RSDP client and server implementations, visit the RSDP Wiki at rsdp.editme.com.

Brian McConnell is an inventor, author, and serial telecom entrepreneur. He has founded three telecom startups since moving to California. The most recent, Open Communication Systems, designs cutting-edge telecom applications based on open standards telephony technology.

Return to the O'Reilly Network.