CONTENT="Modular DocBook HTML Stylesheet Version 1.76b+
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.
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 bend_init handler is passed in the call to statserv_start.
Unlike previous versions of YAZ, the bend_init also serves as a handler that defines the Z39.50 services that the backend wish to support. Pointers to all service handlers, including search - and fetch must be specified here in this handler.
The request - and result structures are defined as
In general, the server frontend expects that the bend_*result pointer that you return is valid at least until the next call to a bend_* function. 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.
The errcode should be zero if the initialization of the backend went well. Any other value will be interpreted as an error. The errstring isn't used in the current version, but one option would be to stick it in the initResponse as a VisibleString. The handle 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.
The auth member holds the authentication information part of the Z39.50 Initialize Request. Interpret this if your serves requires authentication.
The members peer_name, implementation_id, implementation_name and implementation_version holds DNS of client, ID of implementor, name of client (Z39.50) implementation - and version.
The bend_ - members are set to NULL when bend_init is called. Modify the pointers by setting them to point to backend functions.
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.
The bend_search handler is a fairly close approximation of a protocol Search Request - and Response PDUs The setname 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 replace_set is a boolean value corresponding to the resultSetIndicator field in the protocol. num_bases/basenames is a length of/array of character pointers to the database names provided by the client. The query 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 include/yaz/z-core.h. 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 oid_getentbyoid function provided by YAZ.
The structure contains a number of hits, and an errcode/errstring 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 errstring, 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.
The frontend server calls the bend_fetch handler when it needs database records to fulfill a Search Request or a Present Request. The setname is simply the name of the result set that holds the reference to the desired record. The number is the offset into the set (with 1 being the first record in the set). The format field is the record format requested by the client (See section Object Identifiers). The value VAL_NONE indicates that the client did not request a specific format. The stream argument is an ODR 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.
In the structure, the basename is the name of the database that holds the record. len is the length of the record returned, in bytes, and record is a pointer to the record. Last_in_set should be nonzero only if the record returned is the last one in the given result set. errcode and errstring, 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 surrogate_flag to 1 also.
If the len field has the value -1, then record is assumed to point to a constructed data type. The format field will be used to determine which encoder should be used to serialize the data.
The format field is mapped to an object identifier in the direct reference of the resulting EXTERNAL representation of the record.
The bend_present handler is called when the server receives a Present Request. The setname, start and number is the name of the result set - start position - and number of records to be retrieved respectively. format and comp is the preferred transfer syntax and element specifications of the present request.
Note that this is handler serves as a supplement for bend_fetch and need not to be defined in order to support search - and retrieve.
For back-ends that supports delete of a result set only one handler must be defined.
For servers that wish to offer the scan service one handler must be defined.