File: server.backendfunctions.html

package info (click to toggle)
yaz 3.0.34-2
  • links: PTS, VCS
  • area: main
  • in suites: lenny
  • size: 13,404 kB
  • ctags: 12,108
  • sloc: xml: 116,075; ansic: 52,205; sh: 9,746; tcl: 2,043; makefile: 1,141; yacc: 347
file content (377 lines) | stat: -rw-r--r-- 21,475 bytes parent folder | download
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
<html><head><meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1"><title>5.�The Backend Functions</title><meta name="generator" content="DocBook XSL Stylesheets V1.73.2"><link rel="start" href="index.html" title="YAZ User's Guide and Reference"><link rel="up" href="server.html" title="Chapter�4.�Generic server"><link rel="prev" href="server.main.html" title="4.�Your main() Routine"><link rel="next" href="server.invocation.html" title="6.�Application Invocation"></head><body><link rel="stylesheet" type="text/css" href="common/style1.css"><div class="navheader"><table width="100%" summary="Navigation header"><tr><th colspan="3" align="center">5.�The Backend Functions</th></tr><tr><td width="20%" align="left"><a accesskey="p" href="server.main.html">Prev</a>�</td><th width="60%" align="center">Chapter�4.�Generic server</th><td width="20%" align="right">�<a accesskey="n" href="server.invocation.html">Next</a></td></tr></table><hr></div><div class="sect1" lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="server.backendfunctions"></a>5.�The Backend Functions</h2></div></div></div><p>
    For each service of the protocol, the backend interface declares one or
    two functions. You are required to provide implementations of the
    functions representing the services that you wish to implement.
   </p><div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="server.init"></a>5.1.�Init</h3></div></div></div><pre class="synopsis">
bend_initresult (*bend_init)(bend_initrequest *r);
    </pre><p>
     This handler is called once for each new connection request, after
     a new process/thread has been created, and an Initialize Request has
     been received from the client. The pointer to the
     <code class="function">bend_init</code> handler is passed in the call to
     <code class="function">statserv_start</code>.
    </p><p>
     This handler is also called when operating in SRU mode - when
     a connection has been made (even though SRU does not offer
     this service).
    </p><p>
     Unlike previous versions of YAZ, the <code class="function">bend_init</code> also
     serves as a handler that defines the Z39.50 services that the backend
     wish to support. Pointers to <span class="emphasis"><em>all</em></span> service handlers,
     including search - and fetch must be specified here in this handler.
    </p><p>
     The request  - and result structures are defined as
    </p><pre class="synopsis">
typedef struct bend_initrequest
{
    /** \brief user/name/password to be read */
    Z_IdAuthentication *auth; 
    /** \brief encoding stream (for results) */
    ODR stream;
    /** \brief printing stream */
    ODR print;
    /** \brief decoding stream (use stream for results) */
    ODR decode; 
    /** \brief reference ID */
    Z_ReferenceId *referenceId;
    /** \brief peer address of client */
    char *peer_name;           
    
    /** \brief character set and language negotiation 

    see include/yaz/z-charneg.h 
    */
    Z_CharSetandLanguageNegotiation *charneg_request;

    /** \brief character negotiation response */
    Z_External *charneg_response;

    /** \brief character set (encoding) for query terms 
        
    This is NULL by default. It should be set to the native character
    set that the backend assumes for query terms */
    char *query_charset;      

    /** \brief whehter query_charset also applies to recors 
    
    Is 0 (No) by default. Set to 1 (yes) if records is in the same
    character set as queries. If in doubt, use 0 (No).
    */
    int records_in_same_charset;

    char *implementation_id;
    char *implementation_name;
    char *implementation_version;

    /** \brief Z39.50 sort handler */
    int (*bend_sort)(void *handle, bend_sort_rr *rr);
    /** \brief SRU/Z39.50 search handler */
    int (*bend_search)(void *handle, bend_search_rr *rr);
    /** \brief SRU/Z39.50 fetch handler */
    int (*bend_fetch)(void *handle, bend_fetch_rr *rr);
    /** \brief SRU/Z39.50 present handler */
    int (*bend_present)(void *handle, bend_present_rr *rr);
    /** \brief Z39.50 extended services handler */
    int (*bend_esrequest) (void *handle, bend_esrequest_rr *rr);
    /** \brief Z39.50 delete result set handler */
    int (*bend_delete)(void *handle, bend_delete_rr *rr);
    /** \brief Z39.50 scan handler */
    int (*bend_scan)(void *handle, bend_scan_rr *rr);
    /** \brief Z39.50 segment facility handler */
    int (*bend_segment)(void *handle, bend_segment_rr *rr);
    /** \brief SRU explain handler */
    int (*bend_explain)(void *handle, bend_explain_rr *rr);
    /** \brief SRU scan handler */
    int (*bend_srw_scan)(void *handle, bend_scan_rr *rr);
    /** \brief SRU record update handler */
    int (*bend_srw_update)(void *handle, bend_update_rr *rr);

} bend_initrequest;

typedef struct bend_initresult
{
    int errcode;               /* 0==OK */
    char *errstring;           /* system error string or NULL */
    void *handle;              /* private handle to the backend module */
} bend_initresult;
    </pre><p>
     In general, the server frontend expects that the
     <code class="literal">bend_*result</code> pointer that you return is valid at
     least until the next call to a <code class="literal">bend_* function</code>.
     This applies to all of the functions described herein. The parameter
     structure passed to you in the call belongs to the server frontend, and
     you should not make assumptions about its contents after the current
     function call has completed. In other words, if you want to retain any
     of the contents of a request structure, you should copy them.
    </p><p>
     The <code class="literal">errcode</code> should be zero if the initialization of
     the backend went well. Any other value will be interpreted as an error.
     The <code class="literal">errstring</code> isn't used in the current version, but
     one option would be to stick it in the initResponse as a VisibleString.
     The <code class="literal">handle</code> is the most important parameter. It should
     be set to some value that uniquely identifies the current session to
     the backend implementation. It is used by the frontend server in any
     future calls to a backend function.
     The typical use is to set it to point to a dynamically allocated state
     structure that is private to your backend module.
    </p><p>
     The <code class="literal">auth</code> member holds the authentication information
     part of the Z39.50 Initialize Request. Interpret this if your serves
     requires authentication. 
    </p><p>
     The members <code class="literal">peer_name</code>,
     <code class="literal">implementation_id</code>,
     <code class="literal">implementation_name</code> and
     <code class="literal">implementation_version</code> holds
     DNS of client, ID of implementor, name
     of client (Z39.50) implementation - and version.
    </p><p>
     The <code class="literal">bend_</code> - members are set to NULL when
     <code class="function">bend_init</code> is called. Modify the pointers by
     setting them to point to backend functions.
    </p></div><div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="server.search.retrieve"></a>5.2.�Search and Retrieve</h3></div></div></div><p>We now describe the handlers that are required to support search -
     and retrieve. You must support two functions - one for search - and one
     for fetch (retrieval of one record). If desirable you can provide a
     third handler which is called when a present request is received which
     allows you to optimize retrieval of multiple-records.
    </p><pre class="synopsis">
int (*bend_search) (void *handle, bend_search_rr *rr);

typedef struct {
    char *setname;             /* name to give to this set */
    int replace_set;           /* replace set, if it already exists */
    int num_bases;             /* number of databases in list */
    char **basenames;          /* databases to search */
    Z_ReferenceId *referenceId;/* reference ID */
    Z_Query *query;            /* query structure */
    ODR stream;                /* encode stream */
    ODR decode;                /* decode stream */
    ODR print;                 /* print stream */

    bend_request request;
    bend_association association;
    int *fd;
    int hits;                  /* number of hits */
    int errcode;               /* 0==OK */
    char *errstring;           /* system error string or NULL */
    Z_OtherInformation *search_info; /* additional search info */
    char *srw_sortKeys;        /* holds SRU/SRW sortKeys info */
    char *srw_setname;         /* holds SRU/SRW generated resultsetID */
    int *srw_setnameIdleTime;  /* holds SRU/SRW life-time */
    int estimated_hit_count;   /* if hit count is estimated */
    int partial_resultset;     /* if result set is partial */
} bend_search_rr;
    </pre><p>
     The <code class="function">bend_search</code> handler is a fairly close
     approximation of a protocol Z39.50 Search Request - and Response PDUs
     The <code class="literal">setname</code> is the resultSetName from the protocol.
     You are required to establish a mapping between the set name and whatever
     your backend database likes to use.
     Similarly, the <code class="literal">replace_set</code> is a boolean value
     corresponding to the resultSetIndicator field in the protocol.
     <code class="literal">num_bases/basenames</code> is a length of/array of character
     pointers to the database names provided by the client.
     The <code class="literal">query</code> is the full query structure as defined in
     the protocol ASN.1 specification.
     It can be either of the possible query types, and it's up to you to
     determine if you can handle the provided query type.
     Rather than reproduce the C interface here, we'll refer you to the
     structure definitions in the file
     <code class="filename">include/yaz/z-core.h</code>. If you want to look at the
     attributeSetId OID of the RPN query, you can either match it against
     your own internal tables, or you can use the <a class="link" href="tools.oid.html" title="2.�Object Identifiers">
     OID tools</a>.
    </p><p>
     The structure contains a number of hits, and an
     <code class="literal">errcode/errstring</code> pair. If an error occurs
     during the search, or if you're unhappy with the request, you should
     set the errcode to a value from the BIB-1 diagnostic set. The value
     will then be returned to the user in a nonsurrogate diagnostic record
     in the response. The <code class="literal">errstring</code>, if provided, will
     go in the addinfo field. Look at the protocol definition for the
     defined error codes, and the suggested uses of the addinfo field.
    </p><p>
     The <code class="function">bend_search</code> handler is also called when
     the frontend server receives a SRU SearchRetrieveRequest.
     For SRU, a CQL query is usually provided by the client.
     The CQL query is available as part of <code class="literal">Z_Query</code>
     structure (note that CQL is now part of Z39.50 via an external).
     To support CQL in existing implementations that only do Type-1,
     we refer to the CQL-to-PQF tool described
     <a class="link" href="tools.html#cql.to.pqf" title="1.3.3.�CQL to PQF conversion">here</a>.
    </p><p>
     To maintain backwards compatibility, the frontend server
     of yaz always assume that error codes are BIB-1 diagnostics.
     For SRU operation, a Bib-1 diagnostic code is mapped to
     SRU diagnostic.
    </p><pre class="synopsis">
int (*bend_fetch) (void *handle, bend_fetch_rr *rr);

typedef struct bend_fetch_rr {
    char *setname;             /* set name */
    int number;                /* record number */
    Z_ReferenceId *referenceId;/* reference ID */
    Odr_oid *request_format;        /* format, transfer syntax (OID) */
    Z_RecordComposition *comp; /* Formatting instructions */
    ODR stream;                /* encoding stream - memory source if req */
    ODR print;                 /* printing stream */

    char *basename;            /* name of database that provided record */
    int len;                   /* length of record or -1 if structured */
    char *record;              /* record */
    int last_in_set;           /* is it?  */
    Odr_oid *output_format;        /* response format/syntax (OID) */
    int errcode;               /* 0==success */
    char *errstring;           /* system error string or NULL */
    int surrogate_flag;        /* surrogate diagnostic */
    char *schema;              /* string record schema input/output */
} bend_fetch_rr;
    </pre><p>
     The frontend server calls the <code class="function">bend_fetch</code> handler
     when it needs database records to fulfill a Z39.50 Search Request, a
     Z39.50 Present Request or a SRU SearchRetrieveRequest.
     The <code class="literal">setname</code> is simply the name of the result set
     that holds the reference to the desired record.
     The <code class="literal">number</code> is the offset into the set (with 1
     being the first record in the set). The <code class="literal">format</code> field
     is the record format requested by the client (See
     <a class="xref" href="tools.oid.html" title="2.�Object Identifiers">Section�2, &#8220;Object Identifiers&#8221;</a>).
     A value of NULL for <code class="literal">format</code> indicates that the
     client did not request a specific format.
     The <code class="literal">stream</code> argument is an <acronym class="acronym">ODR</acronym> stream which
     should be used for allocating space for structured data records.
     The stream will be reset when all records have been assembled, and
     the response package has been transmitted.
     For unstructured data, the backend is responsible for maintaining a
     static or dynamic buffer for the record between calls.
    </p><p>
     If a SRU SearchRetrieveRequest is received by the frontend server,
     the <code class="literal">referenceId</code> is NULL and the
     <code class="literal">format</code> (transfer syntax) is the OID for XML.
     The schema for SRU is stored in both the
     <code class="literal">Z_RecordComposition</code>
     structure and <code class="literal">schema</code> (simple string).
    </p><p>
     In the structure, the <code class="literal">basename</code> is the name of the
     database that holds the
     record. <code class="literal">len</code> is the length of the record returned, in
     bytes, and <code class="literal">record</code> is a pointer to the record.
     <code class="literal">last_in_set</code> should be nonzero only if the record
     returned is the last one in the given result set.
     <code class="literal">errcode</code> and <code class="literal">errstring</code>, if
     given, will be interpreted as a global error pertaining to the
     set, and will be returned in a non-surrogate-diagnostic.
     If you wish to return the error as a surrogate-diagnostic
     (local error) you can do this by setting
     <code class="literal">surrogate_flag</code> to 1 also.
    </p><p>
     If the <code class="literal">len</code> field has the value -1, then
     <code class="literal">record</code> is assumed to point to a constructed data
     type. The <code class="literal">format</code> field will be used to determine
     which encoder should be used to serialize the data.
    </p><div class="note" style="margin-left: 0.5in; margin-right: 0.5in;"><h3 class="title">Note</h3><p>
      If your backend generates structured records, it should use
      <code class="function">odr_malloc()</code> on the provided stream for allocating
      data: This allows the frontend server to keep track of the record sizes.
     </p></div><p>
     The <code class="literal">format</code> field is mapped to an object identifier
     in the direct reference of the resulting EXTERNAL representation
     of the record.
    </p><div class="note" style="margin-left: 0.5in; margin-right: 0.5in;"><h3 class="title">Note</h3><p>
      The current version of YAZ only supports the direct reference mode.
     </p></div><pre class="synopsis">
int (*bend_present) (void *handle, bend_present_rr *rr);

typedef struct {
    char *setname;             /* set name */
    int start;
    int number;                /* record number */
    Odr_oid *format;           /* format, transfer syntax (OID) */
    Z_ReferenceId *referenceId;/* reference ID */
    Z_RecordComposition *comp; /* Formatting instructions */
    ODR stream;                /* encoding stream - memory source if required */
    ODR print;                 /* printing stream */
    bend_request request;
    bend_association association;

    int hits;                  /* number of hits */
    int errcode;               /* 0==OK */
    char *errstring;           /* system error string or NULL */
} bend_present_rr;
    </pre><p>
     The <code class="function">bend_present</code> handler is called when
     the server receives a Z39.50 Present Request.
     The <code class="literal">setname</code>,
     <code class="literal">start</code> and <code class="literal">number</code> is the
     name of the result set - start position - and number of records to
     be retrieved respectively. <code class="literal">format</code> and
     <code class="literal">comp</code> is the preferred transfer syntax and element
     specifications of the present request.
    </p><p>
     Note that this is handler serves as a supplement for
     <code class="function">bend_fetch</code> and need not to be defined in order to
     support search - and retrieve. 
    </p></div><div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="server.delete"></a>5.3.�Delete</h3></div></div></div><p>
     For back-ends that supports delete of a result set only one handler
     must be defined.
    </p><pre class="synopsis">
int (*bend_delete)(void *handle, bend_delete_rr *rr);

typedef struct bend_delete_rr {
    int function;
    int num_setnames;
    char **setnames;
    Z_ReferenceId *referenceId;
    int delete_status;      /* status for the whole operation */
    int *statuses;          /* status each set - indexed as setnames */
    ODR stream;
    ODR print; 
} bend_delete_rr;
    </pre><div class="note" style="margin-left: 0.5in; margin-right: 0.5in;"><h3 class="title">Note</h3><p>
      The delete set function definition is rather primitive, mostly because
      we have had no practical need for it as of yet. If someone wants
      to provide a full delete service, we'd be happy to add the
      extra parameters that are required. Are there clients out there
      that will actually delete sets they no longer need?
     </p></div></div><div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="server.scan"></a>5.4.�Scan</h3></div></div></div><p>
     For servers that wish to offer the scan service one handler
     must be defined.
    </p><pre class="synopsis">
int (*bend_scan)(void *handle, bend_scan_rr *rr);

typedef enum {
    BEND_SCAN_SUCCESS,  /* ok */
    BEND_SCAN_PARTIAL   /* not all entries could be found */
} bend_scan_status;

typedef struct bend_scan_rr {
    int num_bases;      /* number of elements in databaselist */
    char **basenames;   /* databases to search */
    Odr_oid *attributeset;
    Z_ReferenceId *referenceId; /* reference ID */
    Z_AttributesPlusTerm *term;
    ODR stream;         /* encoding stream - memory source if required */
    ODR print;          /* printing stream */

    int *step_size;     /* step size */
    int term_position;  /* desired index of term in result list/returned */
    int num_entries;    /* number of entries requested/returned */

    /* scan term entries. The called handler does not have
       to allocate this. Size of entries is num_entries (see above) */
    struct scan_entry *entries;
    bend_scan_status status;
    int errcode;
    char *errstring;
    char *scanClause;   /* CQL scan clause */
    char *setname;      /* Scan in result set (NULL if omitted) */
} bend_scan_rr;
    </pre><p>
    This backend server handles both Z39.50 scan 
    and SRU scan. In order for a handler to distinguish between SRU (CQL) scan 
    Z39.50 Scan , it must check for a non-NULL value of 
    <code class="literal">scanClause</code>.
   </p><div class="note" style="margin-left: 0.5in; margin-right: 0.5in;"><h3 class="title">Note</h3><p>
     if designed today, it would be a choice using a union or similar,
     but that would break binary compatibility with existing servers.
    </p></div></div></div><div class="navfooter"><hr><table width="100%" summary="Navigation footer"><tr><td width="40%" align="left"><a accesskey="p" href="server.main.html">Prev</a>�</td><td width="20%" align="center"><a accesskey="u" href="server.html">Up</a></td><td width="40%" align="right">�<a accesskey="n" href="server.invocation.html">Next</a></td></tr><tr><td width="40%" align="left" valign="top">4.�Your main() Routine�</td><td width="20%" align="center"><a accesskey="h" href="index.html">Home</a></td><td width="40%" align="right" valign="top">�6.�Application Invocation</td></tr></table></div></body></html>