The facts as we know them:
It is very easy to write basic SRW implementations. SOAP toolkits can
use a WSDL description to generate protocol code. Then all we have to
do is implement the single client or server SRW method, which
translates your query format into an CQL query (client) or a CLQ query
into your database query (server).
CQL allows you to specify the format of the result set (Dublin Core,
MARCXML, etc.). All servers must support Dublin Core and the SRW
The query can be a list of attribute-value pairs, or a chunk of XML.
CQL makes a distinction between string search (exact match of a string)
and keyword search (finding all words of a string somewhere in the document).
The result set can contain state-preserving information, like the
original query or an IP address, for use with lightweight clients.
Records in the result set are encoded as strings, with angle brackets
escaped. This doesn't work very well for completely browser-based
clients using SRU, since you lose the ability to apply XPath
statements to returned records. This problem will be addressed in a
Servers can/should retain result sets, so they can be referenced
later, especially when the client is asking for multiple pages from a
set. A good way to force the server to keep a result set is to "touch"
it with the client, and refresh the time.
Authentication/encryption is not built into the protocol, and must be addressed
at a higher level. (See general web services literature.)
Contacts: Ralph LeVan (firstname.lastname@example.org), Matthew Dovey
Comparison to other systems:
Ralph LeVan at OCLC maintains a Java-based SRW/SRU server package. Out of the box, it can connect to OCLC's Pears database and the Lucene indexes created by DSpace.
Databases derive from SRWDatabaseImpl. This class implements the doRequest() method. It is best not to override this method, as it takes care of caching result sets and other useful administrative stuff. It is best to only override the abstract methods getQueryResult and getExtraResponseData.