1 <!-- $Id: introduction.xml,v 1.10 2003-02-21 12:06:05 adam Exp $ -->
2 <chapter id="introduction"><title>Introduction</title>
5 &yaz; is a C/C++ library for information retrieval applications
6 using the Z39.50/SRW protocols for information retrieval.
13 Fast operation. The C based BER encoders/decoders as well
14 as the server component of &yaz; is very fast.
18 <ulink url="http://www.loc.gov/z3950/agency/">Z39.50</ulink>
19 version 3 support. All newer extensions
20 including Z39.50-2000 have been incorporated.
24 <ulink url="http://www.loc.gov/z3950/agency/zing/srw/">SRW</ulink>
25 version 1.0 (over HTTP and HTTPS).
28 Includes BER encoders/decoders for the
29 <ulink url="http://www.nlc-bnc.ca/iso/ill/">ISO ILL</ulink>
33 Supports the following transports: BER over TCP/IP
34 (<ulink url="http://www.faqs.org/rfcs/rfc1729.html">RFC1729</ulink>),
35 BER over unix local socket, and
36 <ulink url="http://www.w3.org/Protocols/rfc2616/rfc2616.html">HTTP
40 Secure Socket Layer support using
41 <ulink url="http://www.openssl.org/">OpenSSL</ulink>.
42 If enabled, &yaz; uses HTTPS transport (for SOAP) or
43 "Secure BER" (for Z39.50).
47 <ulink url="http://zoom.z3950.org/">ZOOM</ulink>
48 C API implementing both Z39.50 and SRW.
51 The &yaz; library offers a set of useful utilities
52 related to the protocols, such as MARC (ISO2709) parser,
54 <ulink url="http://www.loc.gov/z3950/agency/zing/cql/">CQL</ulink>
55 parser, memory management routines, character set conversion.
58 Portable code. &yaz; compiles out-of-the box on most Unixes and
59 on Windows using Microsoft Visual C++.
62 Liberal license that allows for commercial use of &yaz;.
67 <sect1 id="introduction.reading"><title>Reading this Manual</title>
68 <para>Most implementors only need to read a fraction of the
69 material in thie manual, so a quick walkthrough of the chapters
75 <xref linkend="installation"/> contains installation
76 instructions for &yaz;. You don't need reading this
77 if you expect to download &yaz; binaries.
78 However, the chapter contains information about how
79 to make <emphasis>your</emphasis> application link
86 <xref linkend="zoom"/> describes the ZOOM API of &yaz;.
87 This is definitely worth a read if you wish to develop a Z39.50/SRW
94 <xref linkend="zoom"/> describes the generic frontend server
95 and explains how to develop server Z39.50/SRW applications for &yaz;.
96 Obviously worth reading if you're to develop a server.
102 <xref linkend="client"/> describes how to use the &yaz; Z39.50
103 client. If you're developer and wish to test your server
104 or a server from another party, you might find this chapter
111 <xref linkend="asn"/> documents the most commonly used Z39.50
112 C data structures offered by the &yaz; API. Client
113 developers using ZOOM and non-Z39.50 implementors may skip this.
119 <xref linkend="soap"/> describes how SRW and SOAP is used
120 in &yaz;. Only if you're developing SOAP/SRW applications
121 this section is a must.
127 <xref linkend="tools"/> contains sections for the various
128 tools offered by &yaz;. Scan through the material quickly
129 and see what's relevant to you! SRW implementors
130 might find the <link linkend="tools.cql">CQL</link> section
137 <xref linkend="odr"/> goes through the details of the
138 ODR module which is the work horse that encodes and decodes
139 BER packages. Implementors using ZOOM only do not need reading this.
140 Most other Z39.50 implementors only need to read the first two
141 sections <link linkend="odr.introduction">Introduction</link>,
142 <link linkend="odr.use">Using ODR</link>.
148 <xref linkend="comstack"/> describes the network layer module
149 COMSTACK. Implementors using ZOOM or the generic frontend server
150 may skip this. Others, presumably, handling client/server
151 communication on their own should read this.
157 <sect1 id="introduction.api"><title>The API</title>
160 The <ulink url="http://www.indexdata.dk/yaz/">&yaz;</ulink>
161 toolkit offers several different levels of access to the
162 <ulink url="http://www.loc.gov/z3950/agency/">ISO23950/Z39.50</ulink>,
163 <ulink url="http://www.nlc-bnc.ca/iso/ill/">ILL</ulink> and
165 The level that you need to use depends on your requirements, and
166 the role (server or client) that you want to implement.
167 If you're developing a client application you should consider the
168 <link linkend="zoom">ZOOM</link> API.
169 It is, by far, the easiest way to develop clients in C.
170 Server implementers should consider the
171 <link linkend="server">generic frontend server</link>.
172 None of those high-level APIs support the whole protocol, but
173 they do include most facilities used in existing Z39.50
177 If you're using 'exotic' functionality (meaning anything not included in
178 the high-level APIs), developing non-standard extensions to Z39.50 or
179 you're going to develop an ILL application you'll have to learn the lower
183 The basic low level modules, which are independent of the role
184 (client or server), consist of three primary interfaces:
187 <listitem><para>&asn;, which provides a C representation of the Z39.50
188 protocol packages (PDUs).
190 <listitem><para>&odr;, which encodes and decodes the packages according
191 to the BER specification.
193 <listitem><para>&comstack;, which exchanges the encoded packages with
194 a peer process over a network.
198 The &asn; module represents the ASN.1 definition of
199 the Z39.50 protocol. It establishes a set of type and
200 structure definitions, with one structure for each of the top-level
201 PDUs, and one structure or type for each of the contained ASN.1 types.
202 For primitive types, or other types that are defined by the ASN.1
203 standard itself (such as the EXTERNAL type), the C representation is
204 provided by the &odr; (Open Data Representation) subsystem.
207 &odr; is a basic mechanism for representing an
208 ASN.1 type in the C programming language, and for implementing BER
209 encoders and decoders for values of that type. The types defined in
210 the &asn; module generally have the prefix <literal>Z_</literal>, and
211 a suffix corresponding to the name of the type in the ASN.1
212 specification of the protocol (generally Z39.50-1995). In the case of
213 base types (those originating in the ASN.1 standard itself), the prefix
214 <literal>Odr_</literal> is sometimes seen. Either way, look for
215 the actual definition in either <filename>z-core.h</filename> (for the types
216 from the protocol), <filename>odr.h</filename> (for the primitive ASN.1
218 The &asn; library also provides functions (which are, in turn,
219 defined using &odr; primitives) for encoding and decoding data values.
220 Their general form is
223 <funcprototype><funcdef>int <function>z_<replaceable>xxx</replaceable></function></funcdef>
224 <paramdef>ODR <parameter>o</parameter></paramdef>
225 <paramdef>Z_<replaceable>xxx</replaceable> **<parameter>p</parameter></paramdef>
226 <paramdef>int <parameter>optional</parameter></paramdef>
227 <paramdef>const char *<parameter>name</parameter></paramdef>
230 (note the lower-case "z" in the function name)
235 If you are using the premade definitions of the &asn; module, and you
236 are not adding new protocol of your own, the only parts of &odr; that you
237 need to worry about are documented in section
238 <link linkend="odr-use">Using ODR</link>.
243 When you have created a BER-encoded buffer, you can use the &comstack;
244 subsystem to transmit (or receive) data over the network. The &comstack;
245 module provides simple functions for establishing a connection
246 (passively or actively, depending on the role of your application),
247 and for exchanging BER-encoded PDUs over that connection. When you
248 create a connection endpoint, you need to specify what transport to
249 use (TCP/IP, SSL or UNIX sockets).
250 For the remainder of the connection's lifetime, you don't have
251 to worry about the underlying transport protocol at all - the &comstack;
252 will ensure that the correct mechanism is used.
255 We call the combined interfaces to &odr;, &asn;, and &comstack; the service
256 level API. It's the API that most closely models the Z39.50
257 service/protocol definition, and it provides unlimited access to all
258 fields and facilities of the protocol definitions.
261 The reason that the &yaz; service-level API is a conglomerate of the
262 APIs from three different submodules is twofold. First, we wanted to allow
263 the user a choice of different options for each major task. For instance,
264 if you don't like the protocol API provided by &odr;/&asn;, you
265 can use SNACC or BERUtils instead, and still have the benefits of the
266 transparent transport approach of the &comstack; module. Secondly,
267 we realize that you may have to fit the toolkit into an existing
268 event-processing structure, in a way that is incompatible with
269 the &comstack; interface or some other part of &yaz;.
274 <!-- Keep this comment at the end of the file
279 sgml-minimize-attributes:nil
280 sgml-always-quote-attributes:t
283 sgml-parent-document:"yaz.xml"
284 sgml-local-catalogs: nil
285 sgml-namecase-general:t