Metaproxy can act as SRU and web service server, which translates web service requests to ANSI/NISO Z39.50 packages and sends them off to common available targets.
A typical setup for this operation needs a filter route including the following modules:
Table 8.1. SRU/Z39.50 Server Filter Route Configuration
| Filter | Importance | Purpose |
|---|---|---|
frontend_net | required | Accepting HTTP connections and passing them to following filters. Since this filter also accepts Z39.50 connections, the server works as SRU and Z39.50 server on the same port. |
sru_z3950 | required | Accepting SRU GET/POST/SOAP explain and searchRetrieve requests for the the configured databases. Explain requests are directly served from the static XML configuration. SearchRetrieve requests are transformed to Z39.50 search and present packages. All other HTTP and Z39.50 packages are passed unaltered. |
http_file | optional | Serving HTTP requests from the filesystem. This is only needed if the server should serve XSLT stylesheets, static HTML files or Java Script for thin browser based clients. Z39.50 packages are passed unaltered. |
cql_rpn | required | Usually, Z39.50 servers do not talk CQL, hence the translation of the CQL query language to RPN is mandatory in most cases. Affects only Z39.50 search packages. |
record_transform | optional | Some Z39.50 backend targets can not present XML record syntaxes in common wanted element sets. using this filter, one can transform binary MARC records to MARCXML records, and further transform those to any needed XML schema/format by XSLT transformations. Changes only Z39.50 present packages. |
session_shared | optional | The stateless nature of web services requires frequent re-searching of the same targets for display of paged result set records. This might be an unacceptable burden for the accessed backend Z39.50 targets, and this module can be added for efficient backend target resource pooling. |
z3950_client | required | Finally, a Z39.50 package sink is needed in the filter chain to provide the response packages. The Z39.50 client module is used to access external targets over the network, but any coming local Z39.50 package sink could be used instead of. |
bounce | required | Any Metaproxy package arriving here did not do so by purpose, and is bounced back with connection closure. this prevents inifinite package hanging inside the SRU server. |
A typical minimal example SRU
server configuration file is found in the tarball distribution at
etc/config-sru-to-z3950.xml.
Of course, any other metaproxy modules can be integrated into a SRU server solution, including, but not limited to, load balancing, multiple target querying (see Chapter 7, Virtual databases and multi-database searching), and complex RPN query rewrites.