Modules of the system

The most of the ReDaReS components are written in C language. These are: the ODBC Client, ODBC server, Manager, Prolog Generator, Prolog Interface and SQL Generator. The SQL Parser is a hybrid written as a set of rules for Flex. It contains regular expressions and C language code, which implements the parser. The scanner is automatically generated by Flex, the parser is provided by C language routines. The routines implement the FSM described in Section 10.5.

The External Matching, Program and Internal Matching data stores (see Figure 10.5) are dynamically created structures, which hold all the data necessary to assemble the Logic Program and launch the inference engine, including information about relation names and attributes, which will be used to store inferred data (Jelly Relations). The Complete Program is a data store, partially implemented as a dynamic data structure and partially as a file. The file part holds the Prolog Program, while the dynamic part holds the goals for creating the state of Jelly Views.

The Prolog Interface, which is written in C, uses so-called the Foreign Language Interface of SWI-Prolog to interact with the inference engine. The interface allows bi-directional communication using C language. It supports both predicates written in C, which are visible to the inference engine as they were written in Prolog, and calling goals with acquiring inferred data. In this way a C language function may launch the inference process stating a Prolog goal.

The SQL Generator creates the states of Jelly Views from the inferred data supplied by the Prolog Interface.

The ODBC Client and ODBC Server provide abstraction layer for communication with the database. All database operations, conducted by ReDaReS, are provided by the layer. This modular structure allows easy replacement of the ODBC protocol with another one if such a need arises.

There are two things changed comparing with Figure 10.5, regarding the implementation of the prototype system. Instead of using the ODBC for acquiring user queries, a regular text stream interface is used. The modification is applied to simplify the interface between the user and the database, in order to track down any problems and provide additional profiling feedback. For using in a productive environment the functionality of the ODBC Server will have to be restored, however for the prototype system the stream oriented text interface is sufficient.

The second modification concerns performance reasons. Figure 10.5 indicates, that the Prolog Interface uses the ODBC client abstraction layer to communicate with the database. This particular issue was addressed after the first performance tests. Originally, downloading Extensional Knowledge from the database was provided by a C language routine which was called by the inference engine using the foreign language interface. But SWI-Prolog provides its own ODBC capabilities, which allow to connect to any ODBC data source and use it for uploading or downloading knowledge. The efficiency of the native SWI-Prolog ODBC interface is better than the communication through the ODBC Client. Still, all C language routines use the ODBC Client. The SWI-Prolog ODBC interface is set up with the same parameters as the ODBC Client uses.

The resulting executable file incorporates all the modules and the inference engine. It uses the ODBC Library which is an external entity.