<!DOCTYPE book PUBLIC "-//OASIS//DTD DocBook XML V4.1//EN"
"http://www.oasis-open.org/docbook/xml/4.1/docbookx.dtd"
[
- <!ENTITY local SYSTEM "local.ent">
+ <!ENTITY % local SYSTEM "local.ent">
+ %local;
<!ENTITY manref SYSTEM "manref.xml">
<!ENTITY progref SYSTEM "progref.xml">
<!ENTITY % common SYSTEM "common/common.ent">
-->
<!NOTATION PDF SYSTEM "PDF">
]>
-<!-- $Id: book.xml,v 1.42 2006-10-12 11:52:24 marc Exp $ -->
+<!-- $Id: book.xml,v 1.52 2007-01-18 09:39:38 adam Exp $ -->
<book id="metaproxy">
<bookinfo>
<title>Metaproxy - User's Guide and Reference</title>
- <author>
- <firstname>Adam</firstname><surname>Dickmeiss</surname>
- </author>
- <author>
- <firstname>Marc</firstname><surname>Cromme</surname>
- </author>
- <author>
- <firstname>Mike</firstname><surname>Taylor</surname>
- </author>
+ <authorgroup>
+ <author>
+ <firstname>Adam</firstname><surname>Dickmeiss</surname>
+ </author>
+ <author>
+ <firstname>Marc</firstname><surname>Cromme</surname>
+ </author>
+ <author>
+ <firstname>Mike</firstname><surname>Taylor</surname>
+ </author>
+ </authorgroup>
+ <releaseinfo>&version;</releaseinfo>
<copyright>
- <year>2006</year>
+ <year>2005-2007</year>
<holder>Index Data ApS</holder>
</copyright>
<abstract>
<simpara>
+ This manual is part of Metaproxy version &version;.
+ </simpara>
+ <simpara>
Metaproxy is a universal router, proxy and encapsulated
metasearcher for information retrieval protocols. It accepts,
processes, interprets and redirects requests from IR clients using
- standard protocols such as
+ standard protocols such as the binary
<ulink url="&url.z39.50;">ANSI/NISO Z39.50</ulink>
- (and in the future <ulink url="&url.sru;">SRU</ulink>
- and <ulink url="&url.srw;">SRW</ulink>), as
+ and the information search and retireval
+ web services <ulink url="&url.sru;">SRU</ulink>
+ and <ulink url="&url.srw;">SRW</ulink>, as
well as functioning as a limited
<ulink url="&url.http;">HTTP</ulink> server.
+ </simpara>
+ <simpara>
Metaproxy is configured by an XML file which
specifies how the software should function in terms of routes that
the request packets can take through the proxy, each step on a
You may modify your copy of the software (fix bugs, add features)
if you need to. We encourage you to send your changes back to us for
integration into the master copy, but you are not obliged to do so. You
- may NOT pass your changes on to any other party.
+ may NOT pass your changes on to any other party.
</para>
</listitem>
<listitem>
packages
(<literal>frontend_net</literal>);
others are sinks: they consume packages and return a result
- (<literal>z3950_client</literal>,
- <literal>backend_test</literal>,
+ (<literal>backend_test</literal>,
<literal>bounce</literal>,
- <literal>http_file</literal>);
+ <literal>http_file</literal>,
+ <literal>z3950_client</literal>);
the others are true filters, that read, process and pass on the
packages they are fed
(<literal>auth_simple</literal>,
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
- <link linkend="filterref"
- >the reference guide to Metaproxy filters</link>.
+ <xref linkend="reference"/>.
</para>
<para>
The filters are here named by the string that is used as the
</section>
<section>
+ <title><literal>load_balance</literal>
+ (mp::filter::LoadBalance)</title>
+ <para>
+ Performs load balancing for incoming Z39.50 init requests.
+ It is used together with the <literal>virt_db</literal> filter,
+ but unlike the <literal>multi</literal> filter it does send an
+ entire session to only one of the virtual backends. The
+ <literal>load_balance</literal> filter is assuming that
+ all backend targets have equal content, and chooses the backend
+ with least load cost for a new session.
+ <warning>
+ <para>
+ This filter is experimental and yet not mature for heavy load
+ production sites.
+ </para>
+ </warning>
+ </para>
+ </section>
+
+ <section>
<title><literal>log</literal>
(mp::filter::Log)</title>
<para>
as multiple different logging formats.
</para>
</section>
-
+
<section>
<title><literal>multi</literal>
(mp::filter::Multi)</title>
<title><literal>session_shared</literal>
(mp::filter::SessionShared)</title>
<para>
- When this is finished, it will implement global sharing of
+ This filter implements global sharing of
result sets (i.e. between threads and therefore between
clients), yielding performance improvements especially when
incoming requests are from a stateless environment such as a
web-server, in which the client process representing a session
- might be any one of many. However:
+ might be any one of many.
</para>
- <warning>
- <para>
- This filter is not yet completed.
- </para>
- </warning>
</section>
<section>
(mp::filter::SRUtoZ3950)</title>
<para>
This filter transforms valid
- SRU/GET or SRU/SOAP requests to Z3950 requests, and wraps the
- received hit counts and XML records into suitable SRU response messages.
+ SRU GET/POST/SOAP searchRetrieve requests to Z3950 init, search,
+ and present requests, and wraps the
+ received hit counts and XML records into suitable SRU response
+ messages.
+ The <literal>sru_z3950</literal> 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.
+ See the
+ <ulink url="&url.zeerex.explain;">ZeeReX Explain</ulink>
+ standard pages and the
+ <ulink url="&url.sru.explain;">SRU Explain</ulink> pages
+ for more information on the correct explain syntax.
+ SRU scan requests are not supported yet.
</para>
</section>
are passed untouched.
</para>
</section>
+
+
+ <section>
+ <title><literal>zeerex_explain</literal>
+ (mp::filter::ZeerexExplain)</title>
+ <para>
+ 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
+ <ulink url="&url.zeerex.explain;">ZeeReX Explain</ulink>
+ standard pages
+ for more information on the correct explain syntax.
+ </para>
+ <warning>
+ <para>
+ This filter is not yet completed.
+ </para>
+ </warning>
+ </section>
+
+
</section>
</listitem>
</varlistentry>
<varlistentry>
- <term><literal>frontend_sru</literal> (source)</term>
- <listitem>
- <para>
- Receive SRU (and perhaps SRW) requests.
- </para>
- </listitem>
- </varlistentry>
- <varlistentry>
- <term><literal>sru2z3950</literal> (filter)</term>
- <listitem>
- <para>
- Translate SRU requests into Z39.50 requests.
- </para>
- </listitem>
- </varlistentry>
- <varlistentry>
<term><literal>sru_client</literal> (sink)</term>
<listitem>
<para>
- SRU searching and retrieval.
- </para>
- </listitem>
- </varlistentry>
- <varlistentry>
- <term><literal>srw_client</literal> (sink)</term>
- <listitem>
- <para>
- SRW searching and retrieval.
+ SRU/GET and SRU/SOAP searching and retrieval.
</para>
</listitem>
</varlistentry>
<para>
If Metaproxy is an interpreter providing operations on packages, then
its configuration file can be thought of as a program for that
- interpreter. Configuration is by means of a single file, the name
+ interpreter. Configuration is by means of a single XML file, the name
of which is supplied as the sole command-line argument to the
<command>metaproxy</command> program. (See
- <link linkend="progref">the reference guide</link>
- below for more information on invoking Metaproxy.)
- </para>
- <para>
- The configuration files are written in XML. (But that's just an
- implementation detail - they could just as well have been written
- in YAML or Lisp-like S-expressions, or in a custom syntax.)
+ <xref linkend="reference"/> below for more information on invoking
+ Metaproxy.)
</para>
</section>
<title>Overview of the config file XML structure</title>
<para>
All elements and attributes are in the namespace
- <ulink url="http://indexdata.dk/yp2/config/1"/>.
+ <ulink url="http://indexdata.com/metaproxy"/>.
This is most easily achieved by setting the default namespace on
the top-level element, as here:
</para>
<screen>
- <yp2 xmlns="http://indexdata.dk/yp2/config/1">
+ <metaproxy xmlns="http://indexdata.com/metaproxy" version="1.0">
</screen>
<para>
- The top-level element is <yp2>. This contains a
+ The top-level element is <metaproxy>. This contains a
<start> element, a <filters> element and a
<routes> element, in that order. <filters> is
optional; the other two are mandatory. All three are
and contain various elements that provide suitable configuration
for a filter of its type. The filter-specific elements are
described in
- <link linkend="filterref">the reference guide below</link>.
+ <xref linkend="reference"/>.
Filters defined in this part of the file must carry an
<literal>id</literal> attribute so that they can be referenced
from elsewhere.
client-server dialogues.
</para>
<screen><![CDATA[<?xml version="1.0"?>
-<yp2 xmlns="http://indexdata.dk/yp2/config/1">
+<metaproxy xmlns="http://indexdata.com/metaproxy" version="1.0">
<start route="start"/>
<filters>
<filter id="frontend" type="frontend_net">
<filter type="bounce"/>
</route>
</routes>
-</yp2>
+</metaproxy>
]]></screen>
<para>
It works by defining a single route, called
</virtual>
<virtual>
<database>marc</database>
- <target>indexdata.dk/marc</target>
+ <target>indexdata.com/marc</target>
</virtual>
</filter>]]></screen>
<para>
Index Data's tiny testing database of MARC records:
</para>
<screen><![CDATA[<?xml version="1.0"?>
-<yp2 xmlns="http://indexdata.dk/yp2/config/1">
+<metaproxy xmlns="http://indexdata.com/metaproxy" version="1.0">
<start route="start"/>
<routes>
<route id="start">
</virtual>
<virtual>
<database>marc</database>
- <target>indexdata.dk/marc</target>
+ <target>indexdata.com/marc</target>
</virtual>
<virtual>
<database>all</database>
<target>z3950.loc.gov:7090/voyager</target>
- <target>indexdata.dk/marc</target>
+ <target>indexdata.com/marc</target>
</virtual>
</filter>
<filter type="multi"/>
<filter type="bounce"/>
</route>
</routes>
-</yp2>]]></screen>
+</metaproxy>]]></screen>
<para>
(Using a
<literal>virt_db</literal>
<para>
<emphasis>Stop! Do not read this!</emphasis>
You won't enjoy it at all. You should just skip ahead to
- <link linkend="refguide">the reference guide</link>,
+ <xref linkend="reference"/>,
which tells
<!-- The remainder of this paragraph is lifted verbatim from
Douglas Adams' _Hitch Hiker's Guide to the Galaxy_, chapter 8 -->
</chapter>
-
- <reference id="refguide">
- <title>Reference guide</title>
+ <reference id="reference">
+ <title>Reference</title>
+ <partintro>
<para>
The material in this chapter is drawn directly from the individual
manual entries. In particular, the Metaproxy invocation section is
on each individual filter is available using the name of the filter
as the argument to the <command>man</command> command.
</para>
- &manref;
+ </partintro>
+ &manref;
</reference>
</book>
projects / metaproxy-moved-to-github.git / blobdiff