Gateway Architecture


A Verity gateway is implemented as a Verity dynamic data access (DDA) driver. A DDA driver is an OS-independent mechanism that allows dynamic linking, sometimes called runtime binding, that provides portability of the access method across operating systems. The gateway driver is a set of C-language callback functions that the Verity engine invokes when it needs to access a repository.

The driver makes use of the following objects:

A driver object that encapsulates the DDA mechanism.

 

A session object that encapsulates the context for repository access; for example, the style files associated with the gateway and its collection.

 

A schema object that encapsulates the structure of the repository and identifies the fields (columns) that exist in the repository.

 

Stream objects that encapsulate the data within a document in a repository. The data can be accessed as a stream of tokens.

 

Field objects that encapsulate the field information within a repository.

 

An authentication object that encapsulates a user’s credentials and certificate.

 

These objects are created and freed by the Verity engine. You provide the logic within callback functions to create, manipulate, and free these objects. One sequence in which the Verity engine could call these functions, whose context is a single VDK session, is shown in the following flowchart.



In this scenario, security is not shown; neither are all of the call backs that the Verity engine can make shown. The following descriptions conform to the steps shown in the diagram above.

1. When the Verity engine attempts to open a collection or create a document source, it first checks to see if the gateway driver has been loaded. If not, it calls a function that you provide to initialize the driver.

2. The Verity engine then calls a function that you provide to initialize a session, in which you specify the data available to the session, such as style file settings and other information. The Verity engine can also call back to functions (not shown in the above diagram) that you provide to allow the Verity engine to obtain the information you stored in the session and to free the information when it is no longer needed.

3. The Verity engine next calls a function that you provide, which defines the repository’s schema.

4. If the Verity engine needs to read the contents of specific fields in the repository or if the Verity engine is indexing and the gateway’s style file contains a copy statement to create an internal field from a field stored in the repository (external field), the Verity engine calls a function that you provide to read fields.

5. The Verity engine next calls a function that you provide to release memory and other resources you used to provide the field information in Step 4.

6. After reading necessary fields, the Verity engine calls a function that you provide to create a stream of tokens for retrieval of the contents of the documents in the repository.

7. After the stream has been set up, the Verity engine calls a function that you provide to retrieve the next token. Your function reads one or more documents from your gateway’s repository and breaks the contents into tokens. After retrieving the entire contents, your function must return an end-of-file token so that the Verity engine recognizes that there are no more tokens to process.

8. After reading the tokens, the Verity engine calls a function that you provide to release memory and other resources you used to provide the tokens in Step 7.

9. After all tokens have been retrieved, the Verity engine calls a function that you provide to release memory and other resources you used to set up the stream in Step 6.

10. If the collection or document source is no longer needed and has been closed, the Verity engine calls a function that you provide to release memory and other resources you used to set up the schema in Step 3. If the collection or document source is still open, the Verity engine will either attempt read field information (see Step 4) or proceed to creating a new stream (see Step 6).

11. Afterwards, the Verity engine calls a function that you provide to release memory and other resources you used to set up the session in Step 2.

12. If the driver is no longer in use by the Verity engine, the Verity engine calls a function that you provide to release memory and other resources you used to set up the driver in Step 1.