University of Mining and Metallurgy Faculty of Electrical Engineering ...

mexicanmorningΔιαχείριση Δεδομένων

16 Δεκ 2012 (πριν από 4 χρόνια και 8 μήνες)

1.281 εμφανίσεις

University of Mining and Metallurgy

Faculty of Electrical Engineering, Automatics,

Computer Science and Electronics

Department of Automatics and Robotics










Marcin Pączek


Implementation and design of a simple

Rule
-
Based system for the object
-

relati
onal
databases






M.A Thesis

under the guidance of

prof. dr. hab. inż. Antoni Ligęza





Cracow 2002






University o
f Mining and Metallurgy, faculty of EAIiE, department of Automatics & Robotics

„Implementation and design of a simple Rule
-
Based system for the object
-
relational databases”

Author: Marcin Pączek
Marcin.Paczek
@comarch.pl

2

Table of contents

1

PREFACE

................................
................................
................................
.............

5

2

THE GOAL OF THE PROJ
ECT

................................
................................
............

6

3

PROBLEM OUTLINE

................................
................................
............................

7

3.1

Introduction to database platforms

................................
.............................

7

3.1.1

Short introduction to Oracle DBMS

................................
............................

7

3.1.2

Short introduction to PostgreSQL DBMS

................................
.................

10

3.1.3

Su
mmary

................................
................................
................................
.

11

3.2

Limitations

................................
................................
................................
...

11

4

RULE
-
BASED SYSTEMS

................................
................................
...................

14

4.1

Introduction

................................
................................
................................
.

14

4.2

Knowledge representation language

................................
.........................

16

4.2.1

General description

................................
................................
.................

16

4.2.2

Rules description language

................................
................................
.....

17

4.3

Rule execution mechanism

................................
................................
........

18

4.4

Inference algorithm

................................
................................
.....................

19

4.4.1

Rule
-
Bas
ed system
-

inference specification

................................
...........

19

4.4.2

Inference in Rule
-
Based server (current project)

................................
.....

20

4.4.3

Inference strategy used in Rule
-
Based server

................................
.........

20

4.4.4

Forward chai
ning in Rule
-
Based server

................................
...................

22

4.5 Knowledge
-
base specification

................................
................................
...

23

4.5.1

Input space definition

................................
................................
...............

23

4.5.2

Output space definition

................................
................................
............

24

4.5.
3

Rule
-
Base dictionary

................................
................................
...............

24

4.5.4

Dependency rules

................................
................................
....................

25

4.5.5

Rule
-
Base procedural knowledge

................................
............................

25

5

RULE
-
BASED SYSTEM APPLICA
TION EXAMPLES

................................
.......

27

6

SH
ORT INTRODUCTION TO
KHEOPS

................................
.............................

29

6.1

KHEOPS main features

................................
................................
...............

29

6.1.1

The KHEOPS knowledge base

................................
...............................

29




University o
f Mining and Metallurgy, faculty of EAIiE, department of Automatics & Robotics

„Implementation and design of a simple Rule
-
Based system for the object
-
relational databases”

Author: Marcin Pączek
Marcin.Paczek
@comarch.pl

3

7

PROJECT DESIGN & IMP
LEMENTATION

................................
........................

30

7.1

Rule b
ased engine

................................
................................
.......................

30

7.1.1

Main configuration file (rulebase.conf)

................................
.....................

30

7.1.2

Database driver configuration file (ruledrv.conf)

................................
......

33

7.1.3

Database service name file ( ruledsn.con
f )

................................
............

34

7.2

Shell scripts

................................
................................
................................
.

37

7.2.1

Starting / Stopping Rule
-
Based server

................................
....................

37

7.3

Rule
-
Based architecture implementation

................................
..................

38

7.3.1

Rule
-
Base cli
ent
-
server architecture

................................
........................

38

7.3.2

Rule
-
Base monitor (EngineCL program)

................................
.................

39

7.3.3

Rule monitor (program parameters description)

................................
......

40

7.4

Utility programs X Window implementat
ion (Qt libraries)

.......................

42

7.4.1

Rule Guide (GUI rule build utility)

................................
............................

42

7.4.2

SQL Guide (database query utility)

................................
..........................

44

8

RULES FILE PARSER (I
MPLEMENTATION SKETCH
)

................................
....

47

8.1

Bison parser generator

................................
................................
...............

49

8.2

Rules grammar syntax language

................................
...............................

49

8.3

Lexical analyser implementation

................................
...............................

54

8.4

Rule
-
Based server
-

rules definition file

................................
....................

58

9

ORACLE DATABASE ACCE
SS
-

INTERFACE DESCRIPTIO
N

.......................

61

9.1 Oracle driver initialisation

................................
................................
..........

62

9.2

Opening connection with Oracle via driver

................................
...............

65

10

DYNAMIC LIBRARY LOAD
ING (DLOPEN)

................................
.......................

68

11

SYSTEM CONFIGURATION

AND ARCHITECTURE
................................
.........

71

11.1

Setting up the environment

................................
................................
........

71

11.2

Configuring the database environment

................................
.....................

71

11.3

Configuring the database dependent configuration files

........................

73

12

PROJECT PORTABILITY
& SCALABILITY

................................
......................

74




University o
f Mining and Metallurgy, faculty of EAIiE, department of Automatics & Robotics

„Implementation and design of a simple Rule
-
Based system for the object
-
relational databases”

Author: Marcin Pączek
Marcin.Paczek
@comarch.pl

4

13

MODIFICATION HISTORY

................................
................................
.................

79

14

LITERA
TURE

................................
................................
................................
......

80

15

APPENDIX

................................
................................
................................
..........

82

15.1

Supplement A

................................
................................
..............................

82

15.2

Supplement B

................................
................................
..............................

83

15.3

Supplement C

................................
................................
..............................

84

15.4

Supplement D

................................
................................
..............................

84

16

GENERAL RULE
-
BASED SERVER DESIGN
SCHEME

................................
....

85





University o
f Mining and Metallurgy, faculty of EAIiE, department of Automatics & Robotics

„Implementation and design of a simple Rule
-
Based system for the object
-
relational databases”

Author: Marcin Pączek
Marcin.Paczek
@comarch.pl

5

1

Preface


This documentation encompasses the general description of design and
implementation of the simple Rule
-
Based system. Section 3.1 presented in thi
s
document refers in short to KHEOPS
1

specification layout.

The Thesis project was implemented and developed from the beginning,
basing on some of KHEOPS facilities. The idea of constructing common rule
interpreter has just been inherited from KHEOPS.

The
project presented here is very pioneering and conceptual. It is also
very complex and combines many technical aspects that require time to be
finished.

Many goals touched by this project were put into life with smaller and
bigger success. Some goals could
not be obviously completed due to lack of
time. Anyway, this project is currently open for any enhancements and can be
developed by anyone that has enough programming skills and knowledge
about Rule
-
Based systems. The starting version of this project is 1.
0.




1

KHEOPS version: C
-
2.5.

Based on the KHEOPS User’s Guide by Jean
-
Paul Gouyon, January 28
th

1997




University o
f Mining and Metallurgy, faculty of EAIiE, department of Automatics & Robotics

„Implementation and design of a simple Rule
-
Based system for the object
-
relational databases”

Author: Marcin Pączek
Marcin.Paczek
@comarch.pl

6

2

The goal of the project


The general goal of this project was to develop a database platform
-
independent Rule
-
Based system that would interact between user and a database.
The general assumption was to build an independent Rule
-
Based engine pre
-
proces
sor that could help user in his decisions. The decision, which is at first sight
the problem description or an algorithm, can then be simply put into technical
language by means of rules. To think of rules it is strongly desired to have a look at
the Rule
-
Based models first.

Rule
-
based
2

models consists one of the most popular paradigm for modelling
complex systems behaviour and control, where symbolic, qualitative, relation
-
based,
etc. representation of knowledge is necessary. Basically, any rule
-
based syst
em is
composed of a set of rules defining actions or conclusions in case specific conditions
hold and an inference control mechanism determining the way and order of rules
execution. Rule
-
based systems are probably the most general and most popular tool
of

Artificial Intelligence. In case of supervision system they can be applied for:




process monitoring



situation assessment



misbehaviour and fault detection



diagnosis



meta
-
level control



reasoning about System State and characteristics, decision support, etc.









2

See monograph on the web site: http://eia.udg.es/~iitap/monografia/arl4_8.html




University o
f Mining and Metallurgy, faculty of EAIiE, department of Automatics & Robotics

„Implementation and design of a simple Rule
-
Based system for the object
-
relational databases”

Author: Marcin Pączek
Marcin.Paczek
@comarch.pl

7

3

Problem outline

3.1

Introduction to database platforms

Nowadays object
-
relational databases like PostgreSQL, Oracle support many
programming languages like PL/SQL
3
, ProC/C++ and many others, including
embedded SQL query language, which is today a standar
d for the respecting DBMS
servers. The most popular, commercial and object
-
relational database is with no
exception Oracle. Oracle DBMS is largely known and used worldwide by many
institutes and companies as a leading database server. This project (especia
lly Rule
-
Based server) assumes using only Oracle, as a destined database server.
PostgreSQL database server is only mentioned here but the author did not focused
on using it.


3.1.1

Short introduction to Oracle DBMS

Oracle the database for Internet computing, ch
anges the way information is
managed and accessed to meet the demands of the Internet age, while providing
significant new features for traditional online transaction processing (OLTP
4
) and
data warehouse applications. It provides advanced tools to manage
all types of data
in Web sites, and it also delivers the performance, scalability, and availability
necessary to support very large database (VLDB
5
) and mission
-
critical applications.
Oracle

introduces database resource management. This gives DBAs the abil
ity to
control the processing resources allocated to a user or group of users.

Oracle
8i
is designed to access and manage all your data using the style and
infrastructure of the Internet. Oracle

is the most complete and comprehensive
platform for building,
deploying, and managing Internet and traditional applications.





3

PL/SQL is an embedded Oracle language, allowing user to combine SQL statements with a high
-
level
pr
ocedural language similar to Pascal. It supports procedures, functions, exceptions handling, etc.

4

OLTP abbr. for
O
n
L
ine
T
ransaction
P
rocessing

5

VLDB abbr. for
V
ery
L
arge
D
ata
B
ase




University o
f Mining and Metallurgy, faculty of EAIiE, department of Automatics & Robotics

„Implementation and design of a simple Rule
-
Based system for the object
-
relational databases”

Author: Marcin Pączek
Marcin.Paczek
@comarch.pl

8


Oracle
8i
simplifies the development of applications.


Oracle
8i
simplifies the management of Internet content.


Oracle
8i
simplifies the deployment of applications.

Oracle
8i
provides the lowest cost platform for developing and deploying applications
on t
he Internet.


SQL language
-

short description


Structured Query Language

(SQL
6
) is the set of statements with which all
programs and users access data in an Oracle database. Application programs and
Oracle tools often allow users access to the database wi
thout using SQL directly, but
these applications in turn must use SQL when executing the user’s request.

Technically speaking, SQL is a data sub
-
language. The purpose of SQL is to provide
an interface to a relational database such as Oracle, and all SQL st
atements are
instructions to the database.


Among the features of SQL are the following:


It processes sets of data as groups rather than as individual units.


It provides automatic navigation to the data.


It uses statements that are complex and powerf
ul individually


SQL provides statements for a variety of tasks, including:


Querying data


Inserting, updating, and deleting rows in a table


Creating, replacing, altering, and dropping objects








6

The latest SQL standard is SQL
-
99 that replaced previous standard SQL
-
92
. However the core of SQL
-
99 is a
superset of SQL
-
92 entry level specification.




University o
f Mining and Metallurgy, faculty of EAIiE, department of Automatics & Robotics

„Implementation and design of a simple Rule
-
Based system for the object
-
relational databases”

Author: Marcin Pączek
Marcin.Paczek
@comarch.pl

9

The simplest SQL statement (Oracle convention) is depi
cted below:

Listing 3.1

SELECT

user, uid, sysdate, ‘Hello, world’


FROM

dual;


More complex SQL query might look like:

Listing 3.2

SELECT

table_name


FROM

dba_tables


WHERE

owner = (
SELECT

user
FROM

dual )


ORDER BY
1;


PL/SQL language
-

short descripti
on



PL/SQL is a high
-
level database embedded programming language supporting
Oracle data processing, database communication, database storage handling, etc. It
offers user great deal of functionality by means of widely used packages.
A
package
is an encap
sulated collection of related program objects stored together in a
database.

Program objects are procedures, functions, variables, constants, cursors, and
exceptions. Packages have many advantages over stand
-
alone procedures and
functions.


The simple PL/S
QL code is show below
7
:

Listing 3.3

CREATE PACKAGE

foo_package
AS


FUNCTION

foo1(name
VARCHAR2
, job
VARCHAR2
);

END

foo_package;








7

This is normally the PL/SQL package specification code




University o
f Mining and Metallurgy, faculty of EAIiE, department of Automatics & Robotics

„Implementation and design of a simple Rule
-
Based system for the object
-
relational databases”

Author: Marcin Pączek
Marcin.Paczek
@comarch.pl

10

Continuation
8
:

Listing 3.4

CREATE PACKAGE BODY
foo_package

AS


FUNCTION
foo1(name
VARCHAR2
, job
VARCHAR2
)
RETURN NUMBER IS


id
NUMBER
;


BEGIN



SELECT
foo_seq.
nextval INTO
id
FROM
dual;


INSERT INTO
foo
VALUES
( id, name, job );


RETURN

id;


END
;

END

foo_package;


3.1.2

Short introduction to PostgreSQL DBMS

PostgreSQL is an object
-
relational database management system O
RDBMS
based on POSTGRES, ver. 4.2.1, developed at the University of California at
Berkeley Computer Science Department.
POSTGRES pioneered many of the object
-
relational concepts now becoming available in some commercial databases.
Traditional relational da
tabase management systems RDBMS support a data model
consisting of a collection of named relations, containing attributes of a specific type.
In current commercial systems, possible types include floating point numbers,
integers, character strings, money,
and dates. It is commonly recognised that this
model is inadequate for future data
-
processing applications. The relational model
successfully replaced previous models in part because of its “Spartan simplicity”.
However, this simplicity makes the implement
ation of certain applications very
difficult.


The sample SQL code in PostgreSQL:

Listing 3.5

SELECT

*


FROM

weather
LEFT OUTER JOIN
cities
ON

(weather.city =


cities.name);





8

Respectively this is a PL/SQL package body code, corresponding to the package specification




University o
f Mining and Metallurgy, faculty of EAIiE, department of Automatics & Robotics

„Implementation and design of a simple Rule
-
Based system for the object
-
relational databases”

Author: Marcin Pączek
Marcin.Paczek
@comarch.pl

11

3.1.3

Summary

The attempt to design a
nd implement the Rule
-
Based system can be a good
example of how to use the database, together with a user’s application. To be more
convinced whether to stick to Oracle or PostgreSQL; the question has to be obtained
first: “
What real database aspects are g
oing to be focused on?
”. Choosing
PostgreSQL can be a good solution, especially for small companies. Anyway, non
-
commercial DBMSs are developed by standalone programmers (affiliated onto many
leading technical Universities all over the world) rather then l
eading software
corporations. Features offered by non
-
commercial database servers are still under
construction and development; hence top companies still prefer to use the
commercial DBMSs, despite of rising costs.

The Rule Based system that is going to be

implemented will support both
Oracle and PostgreSQL facility.


The table below shows the comparison between Oracle and PostgreSQL:

Table 3.1

Oracle


PostgreSQL comparison

Oracle

PostgreSQL

1

Object
-
relational DBMS

1

Object
-
relational DBMS

2

Supports
transactions

2

Yes

3

Supports triggers

3

Yes

4

Supports constraints (primary keys
foreign keys, unique keys)

3

Simple mechanism of constraints

5

Supports PLSQL language

4

Supports PLSQL (simplified form)

6

Supports SQL
-
99/SQL
-
92 standard

5

Yes

3.2

Limitat
ions

When writing Rule
-
Based systems much effort has to be put on reducing
limitations that may appear in correlation with object
-
relational databases.




University o
f Mining and Metallurgy, faculty of EAIiE, department of Automatics & Robotics

„Implementation and design of a simple Rule
-
Based system for the object
-
relational databases”

Author: Marcin Pączek
Marcin.Paczek
@comarch.pl

12

The limitations on Rule
-
Based systems can strongly be depending on the
database choice, hence the genera
l idea of implementing the RB server, was to
dispatch from the database as far as it is possible. The common SQL query language
offers many facilities when querying the database, assuming stiff syntax of the query.
This brings naturally hard limitations on

the shape of the query, particularly when it is
required to be a bit complex. Rule
-
Based systems come here with the solution for
this. It will be possible to separate the logic of query from the data to be queried from
database. The programmer will now ha
ve to code the rules that will be evaluated by
the Rule
-
Based engine. This will drastically decrease the time of constructing the
query by itself, letting this job to be done by Rule
-
Based server.

Technically speaking, rules will help an expert to indirect
ly use queries to a
database, using well
-
known SQL language. This will let an expert to focus on the
logical part of the query rather then wasting time for building SQLs.

Picture presented below shows the general assumption on using Rule
-
Based
system in co
rrelation with a database server.
















Figure 3.1
Rule
-
Based system in correlation with a database


QUERY LOGIC




QUERY DATA


DATABASE




University o
f Mining and Metallurgy, faculty of EAIiE, department of Automatics & Robotics

„Implementation and design of a simple Rule
-
Based system for the object
-
relational databases”

Author: Marcin Pączek
Marcin.Paczek
@comarch.pl

13

Someone might ask;
“Why not to code rules using e.g. PL/SQL embedded
language?”

The typical answer could be like:

“Coding rules using e.g. PL/
SQL violates flexibility and portability of the code”
.
Rules are kept in a well
-
known database (here: Oracle) forcing programmer to use
just this kind of DBMS server. This is not a good solution, because of cyclical
compilation of the code, just when the
rule predicates are to be changed. This might
be obviously not, what had been expected.

Generally speaking, rules must be handled independently from the currently
running database. More over, they must be declared externally (somewhere in a
database table
or in a start
-
up program file). This is exactly, how professional Rule
-
Based systems should look like. The next sections give an answer on how to build
Rule
-
Based systems, basing on the current Thesis project implementation.




University o
f Mining and Metallurgy, faculty of EAIiE, department of Automatics & Robotics

„Implementation and design of a simple Rule
-
Based system for the object
-
relational databases”

Author: Marcin Pączek
Marcin.Paczek
@comarch.pl

14

4

Rule
-
Based systems

4.1

Introductio
n

Rule

Based System is a computer program (self
-
standing module or a remote
application) usually consisting of three, physically independent co
-
operating parts:



Knowledge base



Mechanism of conclusion



User interface


The other alternative division of Rule
-
B
ased systems distinguishes of two main parts:



Knowledge base



Rule interpreter mechanism (simply called:
Interface engine)


Rules normally define various behaviour variants, while the rule interface
controlling mechanism cares of rules choice and execution
.

The goal of every Rule
-
Based system is to help out an expert with his specific
knowledge area. To the most important tasks of the RB system, we might
incorporate:




storing the expertise of one or more experts



using expertise for solving complex problems
in a definite way



solving the problem by fetching up answers not the data



providing explanations of how the solution was obtained



performing the following:



advising



analysing



classifying



learning



planning



prediction




University o
f Mining and Metallurgy, faculty of EAIiE, department of Automatics & Robotics

„Implementation and design of a simple Rule
-
Based system for the object
-
relational databases”

Author: Marcin Pączek
Marcin.Paczek
@comarch.pl

15



identification



testing

Here there are th
e most visible differences between Rule
-
Based system and
common one.


Table 4.1

The differences between common and the Rule
-
Based systems

1

Expert system uses its knowledge not the data, when solving the complicated
and large problems. First and foremost
expert systems use heuristics instead of
common well
-
known sophisticated algorithms.

2

In expert systems (RB systems) the knowledge is encoded and kept as an
important element (module) of the whole system. More exactly, the knowledge is
treated to be inde
pendent from the rest of the system and is automatically
separated from the controlling program. The knowledge is not even compiled into
the user’s executable program. Various knowledge bases, separated from the
controlling program create something like a
shell that acts like a mediator when
solving problems. Such an approach has got an extra one big asset. It makes the
expert systems to be designed and implemented more easily then ever before.
This assures program modularity and portability, which is toda
y very desired.

3

Expert systems strictly co
-
operate with the conclusion mechanisms. They explain
how the individual conclusions were obtained and how the information was used
during consultation.

4

RB systems commonly use the symbolic knowledge represe
ntation:

-

rules

-

semantic networks

-

frames

The inference is performed by using symbolic computation that is similar to the
natural language manipulation. The exceptions are only the neural networks.

5

The Expert systems draw the conclusions from the meta
-
kno
wledge (the
knowledge about themselves). They posses the mechanism of learning.




University o
f Mining and Metallurgy, faculty of EAIiE, department of Automatics & Robotics

„Implementation and design of a simple Rule
-
Based system for the object
-
relational databases”

Author: Marcin Pączek
Marcin.Paczek
@comarch.pl

16

4.2

Knowledge representation language

4.2.1

General description

Talking about the knowledge representation language, there has to be
distinguished the following division into two catego
ries:



facts



way of representing facts

Theses two categories determine the general way of constructing the knowledge
base for the Rule
-
Based systems. Generally speaking, facts are trusted statements
that are true in the reality. The simples fact can be des
cribed e.g. by the following
sentence: “
Today is Friday.”
or

“Water boils at 100 degrees centigrade.”.
Summarising, facts belong to the specific knowledge domain. The second category
encompasses relationship between facts and their representation. An answe
r can be
given. “
How rules are constructed and how they are processed when solving various
problems?
”. From the technical point of view, facts are nothing else like symbols.
Each symbol may correspond to one fact. When the conclusion mechanism is on,
symb
ols are substituted by appropriate facts; thus acting like a mediators between
the outer world and the Rule
-
Based system.


The typical knowledge representation system should match the following
requirements:



should posses the ability for knowledge represen
tation



should posses the ability for conclusion



should assure conclusion effectiveness



should assure knowledge acquisition


Recalling to the current project implementation, facts will be kept externally in a
database tables, to be obtained later by engine

interpreter when chaining rules.





University o
f Mining and Metallurgy, faculty of EAIiE, department of Automatics & Robotics

„Implementation and design of a simple Rule
-
Based system for the object
-
relational databases”

Author: Marcin Pączek
Marcin.Paczek
@comarch.pl

17

4.2.2

Rules description language

Many respecting Rule
-
Based systems support generic formula for
representing rules in a system. The underneath statement is the most commonly
used:


Listing 4.1

IF <condition> THEN <conclusion1>
ELSE <conclusion2>
9


The above rule definition syntax is considered to be an inference, reasoning or a
production rule. In practice such rule is equivalent to logical implication and is called:
if
-
then
-
else

rule. There are of course many exceptions from ru
les in overriding the
general
if
-
then
-
else

syntax; thus the basic concept of the
if
-
then
-
else

is not changed,
only the conclusion mechanism differs. The current project implementation uses just
this kind of rule definition language. Not to be groundless th
e underneath code shows
the sample rule definition:

Listing 4.2


IF

( wart > 10
OR

podatek < 15 )
THEN


ACTION

RULE

R1



In the above example, the condition statement corresponds to:

wart

> 10
OR
podatek

< 15


Respectively, conclusion statements points to
the statement:

ACTION RULE
R1


It tells the rule interpreter to match rule condition first. If it is satisfied, the action is
performed. In this example the next rule
R1

is to be fired. The conclusion statement
can have another form as show below:




9

In practice, the simpli
fied form is used: IF <condition> THEN <conclusion>. Thus the conclusion section is
syntactically more complex, allowing for RHS (Right Hand Side) rule assignments.




University o
f Mining and Metallurgy, faculty of EAIiE, department of Automatics & Robotics

„Implementation and design of a simple Rule
-
Based system for the object
-
relational databases”

Author: Marcin Pączek
Marcin.Paczek
@comarch.pl

18

Listing
4.3

IF

( wart > 10
OR

podatek < 15 )
THEN


ACTION RETURN

wynik = wart + podatek


As it was presented above, the conclusion statement is given as:

ACTION RETURN
wynik

=
wart

+
podatek

4.3

Rule execution mechanism

Rules are executed one after another by rule In
terpreter engine. All space
variables encountered in a rule, denote parameters to be instantiated before the rule
is deployed. Any input variable can be used in many rules to satisfy the pre
-
conditions. The algorithm for execution the rules, used by Rule
-
Based server (more
exactly by rule interpreter) is show below:


Figure 4.1

Rule
-
Based

algorithm for rules execution

Draw the
conclusion

START

Take a rule from
the list

Is rule
condition
satisfied ?

Apply control
action

Substitute values
for attributes

Y

N

Return control to
inference
control
mechanism

Is end of
processing
?

N

Y

STOP

Return

result




University o
f Mining and Metallurgy, faculty of EAIiE, department of Automatics & Robotics

„Implementation and design of a simple Rule
-
Based system for the object
-
relational databases”

Author: Marcin Pączek
Marcin.Paczek
@comarch.pl

19

4.4

Inference algorithm

Inference in Rule
-
Based systems is based on logic. The check for precondition
satisfaction is a specific case of pattern

matching. This section concerns more
advanced aspects of Rule
-
Based inference. The problem of so
-
called
conflict
-
resolution

may exist, when handling with more than one potentially applicable rule.


Rule
-
Based system always has its own definite execution
state. This state
determines the system’s current behaviour.


Let’s assume a dynamic system composed of
n
rules. As it was described in
former section, each rule may consist of
<condition>

and/or
<action>

statement.
Now, having had these
n
rules, only sing
le rule has to be applied within current
System State
-

using reasoning mechanism. The
conflict
-
resolution
problem occurs if
more than one rule can be applied for some state. Normally, deterministic systems
choose single rule to be applied by checking, whe
ther the rule matches condition
criteria. The problem occurs if there is more than one applicable rule. System must
somehow know the precedence of rules execution. Anyway, two inference
formulations can be distinguished: basic formulation and an advanced o
ne.


4.4.1

Rule
-
Based system
-

inference specification

Let’s assume once again the following system S (r
1
, r
2,
r
3,
r
4, ...
r
N
) consisting of
n
linearly ordered rules. The
conflict
-
resolution
problem appears now in selecting
exactly single rule, applicable in the

current state. The selected rule should be
applied and the process is to be repeated from the beginning. The basic strategies
for approaching the mentioned problem may vary, depending on system specification
and application.


BASIC INFERENCE STRATEGIES




R
ule appropriate for achieving the currently desired goal is selected first and next
an attempt to satisfy its preconditions is undertaken; this approach is mostly
applied in planning systems.




University o
f Mining and Metallurgy, faculty of EAIiE, department of Automatics & Robotics

„Implementation and design of a simple Rule
-
Based system for the object
-
relational databases”

Author: Marcin Pączek
Marcin.Paczek
@comarch.pl

20



Rules are sequentially tested for satisfaction of their precondi
tions, only the first
one with satisfied preconditions is selected and executed.


ADVANCED INFERENCE STRATEGIES
10




Rules are ordered linearly and satisfiability of their preconditions is tested
sequentially in a closed loop; rule
i

is followed by a rule num
ber
i+1
, which is
tested and possibly executed; after rule
n

rule
1

is taken into account (linear
execution).



Hierarchy among rules is assumed; rules are tested sequentially according to
their hierarchy until one with satisfied preconditions is found
-

the
n the rule is
executed and the process is resumed from rule
1

(hierarchical execution),




A subset of the set of initial rules is preselected and reordered according to same
priorities (stability or dependence on current context); rules are then inspected
w
ith respect to any of the two above schemes.


4.4.2

Inference in Rule
-
Based server (current project)

Inference strategy implemented in Rule
-
Based server is not so complex as it might
look like. It relies on the basic strategy. Rule
-
Based server processes rules
a
ccordingly to definition time order. It assumes firstly encountered rule to be checked
against its preconditions. If preconditions match given requirements, rule action is
performed, or the next rule from the list is examined. The whole process may appear
cyclically, starting from the first up to the last rule.


4.4.3

Inference strategy used in Rule
-
Based server

The following inference strategies for
conflict
-
resolution

have been specified.
They were gathered in the table below:






10

Materials come from monograph: http://eia.udg.es/~iitap/monografia/arl4_8.html




University o
f Mining and Metallurgy, faculty of EAIiE, department of Automatics & Robotics

„Implementation and design of a simple Rule
-
Based system for the object
-
relational databases”

Author: Marcin Pączek
Marcin.Paczek
@comarch.pl

21

Table 4.2

Inference strategies
for
conflict
-
resolution

rule ordering

Rule that appeared earlier has a higher priority than a
subsequent one;

data ordering

A rule with the highest priority assigned to its conditions
has the highest priority;

size ordering

A rule with longest list of c
onstraining conditions has the
highest priority;

specificity ordering

Arrange rules whose conditions are superset of another
rule;

context limiting

Involves usually the group of rules to which the conflict
-
resolution occurred. This strategy refers to sem
antics of
the process, and it used to reduce the number of rules in a
conflict set;


Rule
-
Based server uses (so far) the first mentioned inference strategy, which is
rule
ordering.
The underneath fragment of a rule program file shows the meaning of rule
o
rdering:


Listing 4.4

...


R1:
IF

(value > 10)
AND

(podatek <= 22)
THEN


ACTION

RULE

R2;


R2:
IF

(value > 10
OR

podatek < 15 )
THEN


ACTION

RULE

R3;


...


Rule

R1

appeared earlier in the system from the rule interpreter’s point of
view. Rule
R1

is as
sumed to be processed earlier, before
R2

rule respectfully. The
depths of condition sets of both rules are the same.
Rule ordering is t
he strategy
used in above example.




University o
f Mining and Metallurgy, faculty of EAIiE, department of Automatics & Robotics

„Implementation and design of a simple Rule
-
Based system for the object
-
relational databases”

Author: Marcin Pączek
Marcin.Paczek
@comarch.pl

22

4.4.4

Forward chaining in Rule
-
Based server

The forward chaining
11

inference can be applied p
ractically in any case. It is
useful if there are relatively few initial facts, new facts should be produced, the goal is
loosely specified or unspecified at all, etc. forward chaining normally produces well
-
defined ground facts. Forward chaining determine
s the execution semantics
associated with the set of rules. There are many pre
-
defined models for interpreting
the rules in a set.


The known models used in Rule
-
Based systems are:



linear execution



hierarchical interpretation



linear execution with rule sw
itching



linear examination with context switching

Rule
-
Based server uses simply the third mentioned model, which is the
linear
execution with rule switching
.

This model is presented below:


Figure 4.2

Model of linear execution with rule switching used by
Rule
-
Based server




11

Forwar
d chaining is commonly used in Rule
-
Based systems. Unlike to forward chaining, backward chaining has
been defined. E.g. Prolog uses backward chaining to compute his rules.

Rule

1

Rule

2

...

Rule

i

...

Rule n




University o
f Mining and Metallurgy, faculty of EAIiE, department of Automatics & Robotics

„Implementation and design of a simple Rule
-
Based system for the object
-
relational databases”

Author: Marcin Pączek
Marcin.Paczek
@comarch.pl

2
3

4.5

Knowledge
-
base specification

A Rule
-
Base server knowledge representation is almost like in KHEOPS
system. It bases on the same assumptions involving the rules description and
definition. The knowledge base consists of many declaration ru
les, which are
normally stored in an input file (rule base program). The KB (
Knowledge Base)
is
divided into the following spaces: INPUT and OUTPUT space


4.5.1

Input space definition

The input space is declared in the Rule
-
Base server’s input file by using the
following
statement:


Listing 4.5

...

SPACE


IN
: <attribute_list>;

...


It is possible to group attributes of an INPUT space, directly into one statement or
they can be specified each in a separate statement. This is shown below:


Listing 4.6

...

SPACE


I
N
: attr1, attr2, attrN;

...


Listing 4.7

...

SPACE


IN
: attr1;


IN
: attr2;

IN
: attrN;

...




University o
f Mining and Metallurgy, faculty of EAIiE, department of Automatics & Robotics

„Implementation and design of a simple Rule
-
Based system for the object
-
relational databases”

Author: Marcin Pączek
Marcin.Paczek
@comarch.pl

24

4.5.2

Output space definition

Similarly as in case of INPUT space it is possible to declare an OUTPUT space
attributes that participate between the “internal knowledge” and

the “external world”.
The general statement defining the OUTPUT space is show below:


Listing 4.8

...

SPACE


OUT
: <attribute_list>;

...


It is possible to group the attributes of an OUTPUT space, directly into one statement
or they can be specified each i
n the separate statement. This is show below:


Listing 4.9

...

SPACE


OUT
: external1, external2, externalN;

...


Listing 4.10

...

SPACE


OUT
: external1;


OUT
: external2;

OUT
: externalN;

...


4.5.3

Rule
-
Base dictionary

The dictionary is created dynamically, while

processing rules from the input file.
More exactly, dictionary is a data structure describing attributes that are needed to
find a solution. Data dictionary is constructed either by single variables or by values
returned by the user
-
defined functions. Suc
h dictionary is called simply the stack. It



University o
f Mining and Metallurgy, faculty of EAIiE, department of Automatics & Robotics

„Implementation and design of a simple Rule
-
Based system for the object
-
relational databases”

Author: Marcin Pączek
Marcin.Paczek
@comarch.pl

25

holds the runtime attribute values, which can either be resulted from reduced rules or
via chaining.

The dictionary may also hold the set of user
-
included “
plugin
” libraries storing
user
-
predefined functions. At
present only two shared libraries are supported. One of
them holds simple math functions whereas the other one holds the financial routines
(like computing VAT etc.). User will have a possibility to plug its own library with his
own defined functions and t
hen use them in a rule program file.


4.5.4

Dependency rules

Dependency rules enable to express relationship between input variables, in
order to restrict the input space to the feasible domain. If e.g. the result of testing the
rules succeeds, the dependent rul
e is fired and so forth. Otherwise the next rule from
the list is chained. Only input states, which meet the dependency constraints, need to
be tested for consistency of the rule base. The syntax for defining the dependent
rules is show below:


Listing 4.1
1

...

RULES

<rule_name_i>:

IF

( <condition> )
THEN







ACTION RULE

<rule_name_j>;

...


The above code might be translated to:


If rule <
rule_name_i>
satisfies the condition
<condition>,

then fire the relevant rule
<
rule_name_j>



4.5.5

Rule
-
Base procedural kn
owledge

The procedural knowledge base involves specifying the action rule that is
executed each time it matches the condition. The relevant statement of a Rule
Interpreter is presented below:




University o
f Mining and Metallurgy, faculty of EAIiE, department of Automatics & Robotics

„Implementation and design of a simple Rule
-
Based system for the object
-
relational databases”

Author: Marcin Pączek
Marcin.Paczek
@comarch.pl

26

Listing 4.12

...

RULES

<rule_name_i>:

IF

( <condition> )
THEN







ACTION RETURN
<action_k>;

...


It will be possible to call the function, assign its returned value to the output
space attribute and then return this attribute via the “RETURN” clause. The detailed
description of the rule grammar syntax, and the input

file content is described in
section 5
.




University o
f Mining and Metallurgy, faculty of EAIiE, department of Automatics & Robotics

„Implementation and design of a simple Rule
-
Based system for the object
-
relational databases”

Author: Marcin Pączek
Marcin.Paczek
@comarch.pl

27

5

Rule
-
Based system application examples


Rule
-
Based systems are used by engineers in large number of areas
(
medicine, telecommunication, industry, etc.
), especially there, where the reasoning
and decision takes place
. With no doubt, the most powerful use of Rule
-
Based
systems is achieved in telecommunication branch; the following applications are the
most relevant:



Interconnect billing (accounting takes place either in case of wireline or
wireless carriers).



Integrate
d billing systems (here, many sophisticated algorithms are used
for tarrification, invoicing, vindication, etc. to generate billing for a
customer)

It is a good time to examine the use of Rule
-
Based system when handling with an
interconnect billing.


Fig
ure 5.1

Carriers in a connection topology

It is commonly known that billing invoicing bases on the number of dialled impulses.
Each connection set between two carriers is normally logged on the switch site as a
single billing record (CDR
Call Detailed Reco
rd)
. It consists of many parameters
required by switch to determine where the connection came from and so forth. Billing
record can be an analogy to the IP header, keeping an information about the peer
hosts and port numbers. This enables the communication
. The same situation takes
place in setting up a connection between two or more autonomous carrier networks.

Carrier 1

Carrier 2

Carrier 3




University o
f Mining and Metallurgy, faculty of EAIiE, department of Automatics & Robotics

„Implementation and design of a simple Rule
-
Based system for the object
-
relational databases”

Author: Marcin Pączek
Marcin.Paczek
@comarch.pl

28

The process of creating a billing record is known as pre
-
processing. Generally, one
billing record holds the following information (data):


Table 5
.1

Subscriber A


number

Subscriber A


category

Subscriber B


country number

Time of execution of connection (year, month, day)

Subscriber B


request time (hour, minute, second)

Conversation duration time (in seconds)

Connection type (incoming, o
utgoing, etc.)

...


The information stored in a billing record can be used e.g. by a specific rule
interpreter algorithm to perform an action onto this billing. The decision can be
obtained whether to invoice this billing or not, basing on well
-
known tar
iff
configuration. Rule
-
Based system might use the following information when
examining his rules in a decision algorithm problem:




Is subscriber active or not?



Does subscriber (customer) posse golden or a silver number?



What tariff plan is used for the ta
riff
-
generation process?



What kind of service associated with the billing is used?



Should invoice algorithm rely on recurring or non
-
recurring services?



What connection type is used, incoming, outgoing, internal, transit?


This decision information can be
encoded in rules to build a simple “not to end” Rule
-
Based system, which will facilitate handling with billing records, when performing e.g.
an invoicing.









University o
f Mining and Metallurgy, faculty of EAIiE, department of Automatics & Robotics

„Implementation and design of a simple Rule
-
Based system for the object
-
relational databases”

Author: Marcin Pączek
Marcin.Paczek
@comarch.pl

29

6

Short introduction to KHEOPS


KHEOPS
12

is a development environment intended for Rule
-
Based syste
ms
that consists both of rule inference processor and a “C” object destined compiler
13
.
KHEOPS uses so
-
called backward chaining algorithm for compiling its rules.
KHEOPS development environment is particularly suited to be used in the real
-
time
application
s, because of its upper
-
bound response of the system. The KHEOPS
knowledge representation relies on a finite set of prepositional variables (or
attributes) that take their values either over domains or can be compared. KHEOPS
application bases on knowledge

written in an extended prepositional logic, which
defines a consistent mapping from the input space to the output space.

6.1

KHEOPS main features

A KHEOPS program can be distinguished of both declarative and procedural
knowledge. Declarative knowledge corresp
onds to KHEOPS rules in the KHEOPS
knowledge base. Procedural knowledge may also appear in the action part of some
KHEOPS rules as evaluation of the C expressions. Those may include calls to “C”
functions, either from the standard C libraries or user
-
provi
ded.


6.1.1

The KHEOPS knowledge base

A KHEOPS knowledge base is made up of a set of declarations and
production rules. Declarations basically allow defining attribute functions. KHEOPS
dictionary is a data structure describing attributes. It is constructed by a
nalysing a
KHEOPS rule base in order to determine the followings:



the function of the attribute (can be INPUT, OUTPUT or INTERMEDIATE);



the type which is string, boolean, integer or real;



the set of relevant values used while attribute comparison;




12

Version C
-
2.5 of KHEOPS is mentioned

13

The compiler used in KHEOPS bases on ANSI C

standard, it runs on the Unix systems (Solaris, SunOS, Linux)




University o
f Mining and Metallurgy, faculty of EAIiE, department of Automatics & Robotics

„Implementation and design of a simple Rule
-
Based system for the object
-
relational databases”

Author: Marcin Pączek
Marcin.Paczek
@comarch.pl

30

7

Project
design & implementation

7.1

Rule based engine

7.1.1

Main configuration file (rulebase.conf)

When starting the Rule
-
Based server an appropriate initial configuration file
rulebase.conf is read. This file should normally be placed in the Cfg directory of the
engine in
stallation tree. The table below shows the precedence of searching for the
configuration file by the Rule
-
Based server:


Table 7.1

Precedence

Location of the rulebase.conf file

1

Cfg (directory of the server installation tree)

2

Current working director
y, from which the server was executed

3

/etc (system configuration directory)


If no configuration file is found, server responds with the specific error
descriptive message, breaking down the execution process. This file is strictly need
to be able to r
un the server. It specifies a lot of necessary options that change or may
change the behaviour of the server. Some options should be set
-
up with a bit of
carefulness.

The short table below presents all of the parameters that can be manipulated by user
when

handling with the Rule
-
Based server.


PARAMETERS OF RULEBASE.CONF CONFIGURATION FILE:


Table 7.2

No.

Parameter name

Explanation

Sup.

1

rulebase_home_path

Indicates the base path for the Rule
-
Base
server. Server needs this information to
Yes




University o
f Mining and Metallurgy, faculty of EAIiE, department of Automatics & Robotics

„Implementation and design of a simple Rule
-
Based system for the object
-
relational databases”

Author: Marcin Pączek
Marcin.Paczek
@comarch.pl

31

read his configu
ration files.

2

trace_level

The level for the tracing. This is normally a
numerical value indicating the depth of
tracing.

Yes

3

debug_level

Similarly as trace_level option, indicates
the level for debugging.


Yes

4

rule_trace_path

Path indicating t
he server where to store
the trace files.

Yes

5

rule_debug_path

Path indicating the server where to store
the debug files.

Yes

6

service_test_port

Port number for detecting the server in the
network. This port is an optional port
number for the UDP packa
ges. It can be
used by a client application to test the
server’s existence.

No

7

service_rule_port

TCP port number used for connection to
the server. Client applications connect to
the server on this port. Program EngineCL

does this.

Yes

8

notify_remote
_host

-

No

9

max_spawn_services

-

No

10

max_tcp_listen

This option is obligatory for the
connection. It identifies the listening queue
for the incoming client requests. The
normal value for this parameter should
oscillate around 5. The low
-
level system
c
all
listen()
expects this parameter.

Yes

11

shm_size

Size of the shared memory segment for
the server. This memory segment is
created every time the Rule
-
Base server is
Yes




University o
f Mining and Metallurgy, faculty of EAIiE, department of Automatics & Robotics

„Implementation and design of a simple Rule
-
Based system for the object
-
relational databases”

Author: Marcin Pączek
Marcin.Paczek
@comarch.pl

32

executed. It is strongly used by the clients
that connect to the server via network.
M
ore over the
SHM

region keeps the
server’s knowledge base that is initially
read from the database.

12

rule_library_path

Auxiliary path telling the server where to
search the program required libraries.

Yes

13

plugin_path

Path for keeping server plug
ins (shared
libraries)

Yes

14

creation_mask

Value of the mask for the created
directories by the server.

Yes

15

auth_remote_user

-

No

16

auth_local_user

-

No

17

dsn_config_file

Path to the DSN configuration file.

Yes

18

driver_config_file

Path to the
database driver configuration
file.

Yes


Sample configuration file is listed below:


Listing 7.1

# Configuration file for the Rule Based Engine Program

# Paths are given relative to the $PR_MAG variable

# If $PR_MAG is not set then the paths are assumed t
o

# be searched within the current working directory


rulebase_home_path
=~/Projects/Praca_magisterska/Engine

trace_level
=3

debug_level
=2


rule_trace_path
=Log/rule_engine.log

rule_debug_path
=Log/rule_engine.log

service_test_port
=9991

service_rule_port
=9992

; server connection port


notify_remote_host
=on

max_spawn_services
=25


; max_allowed=30




University o
f Mining and Metallurgy, faculty of EAIiE, department of Automatics & Robotics

„Implementation and design of a simple Rule
-
Based system for the object
-
relational databases”

Author: Marcin Pączek
Marcin.Paczek
@comarch.pl

33

max_tcp_listen
=5

shm_size
=40960 ; 4096 * 10 multiple of 4096 (PAGE_SIZE)


rule_library_path
=Libs

; path to the server libraries

plugin_path
=Plugins


; path to the serv
er plugins


creation_mask
=0700

auth_remote_user
=true

auth_local_user
=exclusive


dsn_config_file
=Cfg/ruledsn.conf


; DSN config file

driver_config_file
=Cfg/ruledrv.conf ; DB driver file


7.1.2

Database driver configuration file (ruledrv.conf)

Apart from the main

configuration file, there is yet another configuration file
keeping information about the server database driver. File ‘
ruledrv.conf
’ holds just
this information and is extremely need by server to be executed properly.


Sample content of this file might l
ook like:


Listing 7.2

# Driver specification file


use_driver
=Oracle ;points the section in 'ruledsn.conf'

#use_driver=Postgres

driver_log_path
=Log/driver


To be able to run Rule
-
Base server, a valid database driver must be chosen.
The parameter
use_drive
r

enables that. This parameter expects the name of the
database driver description section. In other words, the value of this parameter
should point to valid section defined in ‘
ruledsn.conf
’ file. If no valid driver is specified,
the server will not star
t and the appropriate message will be displayed on the
standard output. It is strongly suggested to name the section due to the database
name; if e.g. section name was named ‘Oracle’, the same name should appear as a
value for
use_driver

parameter.





University o
f Mining and Metallurgy, faculty of EAIiE, department of Automatics & Robotics

„Implementation and design of a simple Rule
-
Based system for the object
-
relational databases”

Author: Marcin Pączek
Marcin.Paczek
@comarch.pl

34

7.1.3

Databa
se service name file ( ruledsn.conf )

The abbreviation DSN
14

simply stands for the
Database Specification Name.
Rule
-
Base server first searches this file on the start. This file consists of many user
-
defined sections
-

each with separate database driver de
scription. Initially this file in
parsed to satisfy the syntactic and semantic rules. If no errors are reported, the
server goes forward with his execution, otherwise a notification message is thrown to
notify about problem existed.


Below there is a sampl
e listing of that file:


Listing 7.3

# Database driver configuration file


Oracle(


port
= 1521


host
=192.168.5.210


sid
=science


library
= /opt/oracle/OraHome1/lib/libclntsh.so


pass
= tytan


user
= tytan

)


Postgres(


port
= 5432


host
= localhost


db
name
= template1


user
= job


pass
= job01


library
=/usr/local/pgsql/lib/libpq.so

)


Dummy(


port
=


host
=


dbname
=


user
= nobody


pass
= nobody


library
=/lib/lib.so.1

)




14

The naming convention DSN is popular when handling with this kind of database configuration files




University o
f Mining and Metallurgy, faculty of EAIiE, department of Automatics & Robotics

„Implementation and design of a simple Rule
-
Based system for the object
-
relational databases”

Author: Marcin Pączek
Marcin.Paczek
@comarch.pl

35


Oracle_informatyk(


port
= 1521


host
= informatyk.edu.pl


sid
= polihymn.informa
tyk.edu.pl


user
= polihymnia


pass
=polihymnia


library
= /opt/oracle/OraHome1/lib/libclntsh.so

)


PostgreSQL2 (


port
= 5432


host
= localhost


dbname
=


user
=


pass
=


library
=/usr/local/pgsql/lib/libpq.so

)


The syntax of the section is shown below:


Listing 7.4

<
section_name
> (


<
parameter1
> = <
value1
>


...


<
parameterN
> = <
valueN
>

)


The only valid parameters supported by this configuration are gathered in the table
below:


Table 7.3

Parameter

Type

Description

port

NUMBER

Specifies the listening po
rt for the database server

host

STRING

Defines the host name, where the database server
is running

dbname

STRING

Specifies the name of the database to connect to.
This parameter is only desired when using the



University o
f Mining and Metallurgy, faculty of EAIiE, department of Automatics & Robotics

„Implementation and design of a simple Rule
-
Based system for the object
-
relational databases”

Author: Marcin Pączek
Marcin.Paczek
@comarch.pl

36

PostgreSQL database

Sid

STRING

This paramet
er is needed when defining the Oracle
section. It keeps the name of the connection link.
This name is almost always corresponding to the
name of the section defined in ‘
tnsnames.ora


file.
The file ‘tnsnames.ora’ will be described later,
because it is the
only file, the client needs to
connect to Oracle

user

STRING

Specifies a valid database user. The user must be
an existing user in a database. For the purpose of
this project, such user ‘
rule’
was created

pass

STRING

Defines the user password required f
or connection

library

STRING

This parameter is one of the most important and
specifies the name of the database driver file, which
is normally the shared library. Normally when
installing any database server, such library must
exist either within the data
base installation tree or
somewhere in system (e.g. in /lib or /usr/lib
directory). The library enables clients to connect to
the server by using server’s database interface
facility. Each respecting DBMS supports its own
server connection interface. In ca
se of Oracle the
OCI (Oracle Call Library) is supported.


When defining the section the appropriate parameters must be used. Any mistake in
the file will be detected by server while execution.








University o
f Mining and Metallurgy, faculty of EAIiE, department of Automatics & Robotics

„Implementation and design of a simple Rule
-
Based system for the object
-
relational databases”

Author: Marcin Pączek
Marcin.Paczek
@comarch.pl

37

7.2

Shell scripts

7.2.1

Starting / Stopping Rule
-
Based server


Fig
ure 7.1

Starting Rule
-
Based server



Figure 7.2

Stopping Rule
-
Based server




University o
f Mining and Metallurgy, faculty of EAIiE, department of Automatics & Robotics

„Implementation and design of a simple Rule
-
Based system for the object
-
relational databases”

Author: Marcin Pączek
Marcin.Paczek
@comarch.pl

38

7.3

Rule
-
Based architecture implementation

7.3.1

Rule
-
Base client
-
server architecture

The general idea of coding the Rule
-
Based server is to enable the powerfulness
of the client
-
server arch
itecture that is offered by various UNIX systems
15
. Generally
Rule
-
Based server is assigned to act like a typical UNIX server daemon
16

that listens
on a well
-
known TCP port, allowing client applications for connections. The testing
client application has als
o been written. Its name is
EngineCL.
This simple program
is used to connect to the server. It uses the socket layer API to do that. The client
program resembles a simple monitor application used for processing various server’s
commands. It can be used eit
her for testing server connectivity or for rules
processing.

This monitor is something for Rule
-
Based server as e.g.
sqlplus
for Oracle
database. The underneath draft shows the general sketch of the client’s position in
the Rule
-
Based server background:




Figure 7.3
Relationship between client and server RB programs




15

Good example can be: Sun Solaris, SunOS sparc, Linux, Compaq DEC, HP
-
UX and other...

16

Daem
ons are standalone UNIX programs, designed to work as server by doing their job in a background. They
may or not
-

posses the controlling terminal.


Rule
-
Base

server
deamon

Rule
monitor

Rule
monitor

Rule
monitor

Network




University o
f Mining and Metallurgy, faculty of EAIiE, department of Automatics & Robotics

„Implementation and design of a simple Rule
-
Based system for the object
-
relational databases”

Author: Marcin Pączek
Marcin.Paczek
@comarch.pl

39

7.3.2

Rule
-
Base monitor (EngineCL program)

Rule
-
Based monitor program has been presented below in sample scenarios:


Listing 7.5

[root@ciacho]# EngineCL

h 192.168.5.210

p 9992

Connecting to the re
mote host 192.168.5.210 on port 9992...


Opening session to the Rule
-
Base engine server...

OK. Session opened.

--------------------------------------------


Rule
-
Base interactive client utility.


Released ver. 1.0 Copyright(c) 2002

------------------------
--------------------

RuleMonitor>


Listing 7.6

[root@ciacho]# EngineCL

h 192.168.5.210

p 9992

Connecting to the remote host 192.168.5.210 on port 9992...


Opening session to the Rule
-
Base engine server...

OK. Session opened.

-----------------------------
---------------

Rule
-
Base interactive client utility.


Released ver. 1.0 Copyright(c) 2002

--------------------------------------------


RuleMonitor> help

Available commands:

------------------------------------

close sendprog

!(shell)

clear


status

ls

ve
r


querydrv

help










University o
f Mining and Metallurgy, faculty of EAIiE, department of Automatics & Robotics

„Implementation and design of a simple Rule
-
Based system for the object
-
relational databases”

Author: Marcin Pączek
Marcin.Paczek
@comarch.pl

40

Listing 7.7

RuleMonitor> status

Querying server for status. Wait... OK.

-----------------------------------------------------

Engine server name

: ciacho (192.168.210.5)

Listening port


: 9992

Operating system

: (Linux ciacho 2.2.18
)

-----------------------------------------------------

RuleMonitor>



Listing 7.8

RuleMonitor> status

Querying server for status. Wait... OK.

-----------------------------------------------------

Engine server name

: ciacho (192.168.210.5)

Listening port


: 9992

Operating system

: (Linux ciacho 2.2.18)

-----------------------------------------------------

RuleMonitor> ls

EngineCL

libDriverRB.a

restart_engine.sh

EngineRB

libDriverRB.so

start_engine.sh



Listing 7.9

RuleMonitor> close

Connection closed with

server.


[root@ciacho]#


7.3.3

Rule monitor (program parameters description)

Rule monitor supports many easy to set up start
-
up parameters. These
parameters are put into client’s environment through the shell.



The listing below shows all possible, adjustable
rule monitor parameters:





University o
f Mining and Metallurgy, faculty of EAIiE, department of Automatics & Robotics

„Implementation and design of a simple Rule
-
Based system for the object
-
relational databases”

Author: Marcin Pączek
Marcin.Paczek
@comarch.pl

41

Listing 7.10

[root@ciacho]# EngineCL

h

Rule
-
Base client engine utility. v. 1.1

Usage:


EngineCL [options]

Options:


-
v,
-
V

: show version


-
H


: show help


-
h <host>

: specify host name (IP) to connect


-
p <port>

: remote port nu
mber for connection


-
P <host>

: detect Rule
-
Base Engine server (UDP ping)


-
n <pkt>

: number of UDP packets to send


-
f <prog>

: file with rules to be sent to the RB engine server


-
d


: turns on/off debugging

Examples:


EngineCL

h 192.168.5.210

p 9992


f prog01.rb

d


EngineCL

P ciacho.ds5.agh.edu.pl

p 9991

n 10


When client connects to the server the separate process is created to handle
the request. In UNIX system this is normally done by using
fork()

function. It spawns
a new process (child) to
handle the client’s request. If the connection is going to be
broken, the separate server process is detached from the client, causing the
allocated resources to be freed. It is possible for multiple connections to the server.
This is simply done by using
the low
-
level “system call”
17

select().


Figure 7.4
Rule monitor connection scenario




17

System calls are built
-
in routines in UNIX kernel. Sample well
-
known system calls are read, write, select,

etc.

S
erver is

listening
on port
9992

clien
t

connect

accept


fork

parent

Exit

Exit


Service
process


child

active
connection




University o
f Mining and Metallurgy, faculty of EAIiE, department of Automatics & Robotics

„Implementation and design of a simple Rule
-
Based system for the object
-
relational databases”

Author: Marcin Pączek
Marcin.Paczek
@comarch.pl

42

7.4

Utility programs X Window implementation (Qt libraries)

7.4.1

Rule Guide (GUI rule build utility)

Rule Guide is a very simple user
-
friendly GUI environment that helps user to
cr
eate its own rules predicates. This program offers something like a simple editor
layout for drawing rules and the dependency between them. The destined action for
the Rule Guide is to generate file with rule predicates corresponding to the
constructed rul
e dependency graph. This GUI environment is still under construction.
So far some of existing GUI functionality has been presented in the following
screenshots:

















Figure 7.5

This screenshot presents Rule Guide GUI front panel





University o
f Mining and Metallurgy, faculty of EAIiE, department of Automatics & Robotics

„Implementation and design of a simple Rule
-
Based system for the object
-
relational databases”

Author: Marcin Pączek
Marcin.Paczek
@comarch.pl

43















Figure 7.6
this screenshot presents Rule Guide
-

rule editor dialog
















Figure 7.7
This screenshot presents the rule definition panel




University o
f Mining and Metallurgy, faculty of EAIiE, department of Automatics & Robotics

„Implementation and design of a simple Rule
-
Based system for the object
-
relational databases”

Author: Marcin Pączek
Marcin.Paczek
@comarch.pl

44















Figure 7.8
this screenshot presents Rule Guide editor layout


7.4.2

SQL Guide (database query utilit
y)

To improve the usage and the powerfulness of the Oracle database, the
appropriate graphical utility has been created. It has been written in C++ using
Qt

library
18
. This simple program which is the SQL Guide had been intended to help
administrator or any

user to perform the SQL queries on database. By using this
utility we can easily and fast perform any query (here select the contents of the Rule
-
Based server tables). Generally this application was developed to work
independently of any Oracle database.
SQL Guide uses so called OCI interface to
communicate with a database. More about OCI and interfaces in next sections.
Some of the SQL Guide screenshots have been presented below. First screenshot
shows the connection panel:

The user needs to specify the c
onnection parameters such as username, password
and a database link name. The connection starts after pressing “
Connect
” button.




18

Qt library is a set of C++ classes, enabling programmer to develop his own GUI applications. Qt is a pioneering
project developed and supported by Trolltech company. More on the web site: www.trolltech.org




University o
f Mining and Metallurgy, faculty of EAIiE, department of Automatics & Robotics

„Implementation and design of a simple Rule
-
Based system for the object
-
relational databases”

Author: Marcin Pączek
Marcin.Paczek
@comarch.pl

45


Figure 7.9
SQL Guide connection panel


Figure 7.10
established connection to the database, and a simple select