We now briefly consider each of the types of filter supported by the core Metaproxy binary. This overview is intended to give a flavor of the available functionality; more detailed information about each type of filter is included below in Reference.
The filters are here named by the string that is used as the
type attribute of a
<filter> element in the configuration
file to request them, with the name of the class that implements
them in parentheses. (The classname is not needed for normal
configuration and use of Metaproxy; it is useful only to
The filters are here listed in alphabetical order:
Simple authentication and authorization. The configuration
specifies the name of a file that is the user register, which
pairs, one per line, colon-separated. When a session begins, it
is rejected unless username and password are supplied, and match
a pair in the register. The configuration file may also specify
the name of another file that is the target register: this lists
sets, one per line, with multiple database names separated by
commas. When a search is processed, it is rejected unless the
database to be searched is one of those listed as available to
A partial sink that provides dummy responses in the manner of the
yaz-ztest Z39.50 server. This is useful only
for testing. Seriously, you don't need this. Pretend you didn't
even read this section.
A sink that swallows all packages, and returns them almost unprocessed. It never sends any package of any type further down the row, but sets Z39.50 packages to Z_Close, and HTTP_Request packages to HTTP_Response err code 400 packages, and adds a suitable bounce message. The bounce filter is usually added at the end of each filter chain route to prevent infinite hanging of, for example, HTTP requests packages when only the Z39.50 client partial sink filter is found in the route.
A query language transforming filter which catches Z39.50
CQL queries, transforms
and sends the
searchRequests on to the next
filters. It is, among other things, useful in a SRU context.
A source that accepts Z39.50 connections from a port specified in the configuration, reads protocol units, and feeds them into the next filter in the route. When the result is received, it is returned to the original origin.
A partial sink which swallows only
HTTP_Request packages, and
returns the contents of files from the local
filesystem in response to HTTP requests.
It lets Z39.50 packages and all other forthcoming package types
(Yes, Virginia, this
does mean that Metaproxy is also a Web-server in its spare time. So
far it does not contain either an email-reader or a Lisp
interpreter, but that day is surely coming.)
Performs load balancing for incoming Z39.50 init requests.
It is used together with the
but unlike the
multi filter, it does send an
entire session to only one of the virtual backends. The
load_balance filter is assuming that
all backend targets have equal content, and chooses the backend
with least load cost for a new session.
This filter is experimental and not yet mature for heavy load production sites.
Writes logging information to standard output, and passes on the package unchanged. A log file name can be specified, as well as multiple different logging formats.
Performs multi-database searching. See the extended discussion of virtual databases and multi-database searching below.
queries by a
three-step process: the query is transliterated from Z39.50
packet structures into an XML representation; that XML
representation is transformed by an XSLT stylesheet; and the
resulting XML is transliterated back into the Z39.50 packet
This filter acts only on Z39.50 present requests, and let all other types of packages and requests pass untouched. It's use is twofold: blocking Z39.50 present requests, which the backend server does not understand and can not honor, and transforming the present syntax and elementset name according to the rules specified, to fetch only existing record formats, and transform them on-the-fly to requested record syntaxes.
This filter implements global sharing of result sets (i.e. between threads and therefore between clients), yielding performance improvements by clever resource pooling.
This filter transforms valid
SRU GET/POST/SOAP searchRetrieve requests to Z39.50 init, search,
and present requests, and wraps the
received hit counts and XML records into suitable SRU response
sru_z3950 filter processes also SRU
GET/POST/SOAP explain requests, returning
either the absolute minimum required by the standard, or a full
pre-defined ZeeReX explain record.
standard pages and the
SRU Explain pages
for more information on the correct explain syntax.
SRU scan requests are not supported yet.
Does nothing at all, merely passing the packet on. (Maybe it
should be called
passthrough?) This exists not to be used, but
to be copied - to become the skeleton of new filters as they are
written. As with
backend_test, this is not
intended for civilians.
Performs virtual database selection: based on the name of the
database in the search request, a server is selected, and its
address added to the request in a
otherInfo packet. It will subsequently be used by a
the extended discussion
of virtual databases and multi-database searching below.
A partial sink which swallows only Z39.50 packages.
It performs Z39.50 searching and retrieval by proxying the
packages that are passed to it. Init requests are sent to the
address specified in the
attached to the request: this may have been specified by client,
or generated by a
virt_db filter earlier in
the route. Subsequent requests are sent to the same address,
which is remembered at Init time in a Session object.
HTTP_Request packages and all other forthcoming package types
are passed untouched.
This filter acts as a sink for Z39.50 explain requests, returning a static ZeeReX Explain XML record from the config section. All other packages are passed through. See the ZeeReX Explain standard pages for more information on the correct explain syntax.
This filter is not yet completed.