Organization of Flexible User Interface
for Policy Management Systems
Supporting Different Rule Abstraction Levels
Ph.D. Dissertation
Author:
Bartosz Kwolek
Supervisor:
Prof. Krzysztof Zieliński
Organizacja elastycznego interfejsu użytkownika
w systemach zarządzania politykami
wspierającego różne poziomy abstrakcji reguł
Rozprawa doktorska
Autor:
Bartosz Kwolek
Promotor:
Prof. dr hab. inż. Krzysztof Zieliński
I would like to express my gratitude to my supervisor, Professor Krzysztof Zieliński, for his support and assistance in carrying out the research described in this dissertation. Special thanks to all those who kept on saying “you will do it ”.
Acknowledgments i List of Tables v List of Figures vi Listings viii Typographic Conventions ix Trademarks x 1 Introduction 1 1.1 Motivation . . . 2 1.2 Thesis Statement . . . 3 1.3 Research Challenges . . . 4 1.4 Research Contribution . . . 4 1.5 Dissertation Organization . . . 5 2 Related Work 7 2.1 Knowledge of Systems . . . 8 2.1.1 Knowledge . . . 8 2.1.2 Types of Knowledge . . . 8 2.1.3 Knowledge-Based Systems . . . 9
2.1.4 Knowledge Representation – Policies and Rules . . . 10
2.2 Policy- and Rule-based Systems . . . 12
2.2.1 Knowledge in Traditional Systems . . . 12
2.2.2 Anatomy of Separated System Knowledge . . . 14
2.2.3 Policy-based Management . . . 15
2.3 Production Rule Systems . . . 16
2.3.1 Anatomy of a Production Rule System . . . 17
2.3.2 Business Rule Platforms . . . 18
2.4 Business Rule Management Systems . . . 18
2.4.1 BRMS Functionality . . . 19
2.4.2 BRMS Platforms . . . 20
2.5 Policies and Rules Transformation Aspects . . . 22
2.5.1 Policy-level Transformation Reasons . . . 22
2.5.2 Rule-level Transformation Reasons . . . 24
2.5.3 Conclusions . . . 27
2.6 Abstraction Levels . . . 28
2.6.1 Abstraction Level Definition . . . 28
2.6.2 Business Level vs. Technical Level . . . 30
2.6.3 Conclusions . . . 30
2.7 Rule Translation . . . 31
2.7.1 Manifestations of Rule Relations . . . 32
2.7.2 Horizontal and Vertical Translations . . . 36
2.7.3 Conclusions . . . 39
2.8 Critical Overview . . . 39
2.9 Chapter Summary . . . 40
3 Concept and Model of Inter-level Rule Translation 41 3.1 System Objectives . . . 42
3.2 System Requirements and Assumptions . . . 42
3.3 Basic Terms . . . 45
3.3.1 Modelling of Rule Templates and Rule Instances . . . 45
3.3.2 Modelling of Levels of Abstraction . . . 48
3.4 Formal Model of System Mechanisms . . . 50
3.4.1 Elements of Rule Instantiation Mechanism . . . 50
3.4.2 Elements of Inter-Level Translation Mechanism . . . 53
3.4.3 Concept Model Summary . . . 57
3.5 Chapter Summary . . . 57
4 Mechanism of Knowledge-based Translation 59 4.1 Representation of Rule Templates . . . 59
4.2 Realisation of Rule Translation Mechanism . . . 62
4.2.1 Translation Engine Overview . . . 62
4.2.2 Translation Engine Anatomy . . . 64
4.3 Representation of Inter-level Meta-knowledge . . . 66
4.4 Rule Change Scenario . . . 68
4.5 Chapter Summary . . . 70 5 Implementation Details 71 5.1 Tool Architecture . . . 71 5.1.1 Rule Manager . . . 73 5.1.2 Translation Manager . . . 74 5.1.3 User Interface . . . 75 5.2 Technological Aspects . . . 78
5.2.1 Production Rule System . . . 78
5.2.2 Flexible User Interface Technology . . . 79
5.2.3 Integration Mechanism . . . 80
5.3 Chapter Summary . . . 80
6 Evaluation of Vertical Policy Translation Tool 82 6.1 Problem Domain . . . 83
6.1.1 Monitoring Policy Diversification . . . 83
6.2 Evaluation of the Policy Translator Functionality . . . 90
6.2.1 Policy Structure Definition . . . 90
6.2.2 Tool Usage Philosophy . . . 94
6.2.3 Tool Capability Demonstrations . . . 98
6.3 Chapter Summary . . . 107
7 Conclusions 108 7.1 Thesis Verification . . . 108
7.2 Novel Concepts . . . 109
7.3 Future Work . . . 110
A Token-based Rule Template Notation 111
B Meta-knowledge definition 114
C Rule Tokens Types 118
D Integration of Flex UI with Java Back-end 119
Acronyms 122
2.1 The knowledge categorization . . . 9
4.1 The distinguished token types . . . 61
4.2 The phases of vertical translation of rules . . . 63
4.3 The change rule scenario phases . . . 70
6.1 Exemplary scenarios for global strategy creation . . . 87
6.2 Exemplary strategy definitions for two scenarios . . . 88
2.1 The Data, Information, Knowledge, and Wisdom pyramid . . . 8
2.2 The architecture of a Knowledge-based system . . . 10
2.3 Three layer system architecture . . . 13
2.4 The IETF/DMTF Policy Architecture . . . 14
2.5 Three layer system architecture with separated policy governance . . . . 15
2.6 Control loop of a Managed Element . . . 15
2.7 Rule Engines, Expert Systems and Produciton Rule Systems relation . . 16
2.8 Production Rule System anatomy . . . 17
2.9 Rule concepts and languages at different levels of abstraction [47] . . . . 29
2.10 Policy Refinement and Policy Interoperability with joins via IL [52] . . . 35
2.11 Horizontal translation method leveraging XSLT and RIF / RuleML [39] 38 3.1 Multi-level policy view and vertical translation concept . . . 42
3.2 The scope of interest and types of user of the created solution . . . 44
3.3 Elements of a rule - conditions and actions . . . 45
3.4 Rule conditions and actions represented with help of defined parameters 46 3.5 Rule template structure . . . 47
3.6 The significance of a rule formatting function . . . 47
3.7 An output rule formula generated by a formatting function . . . 48
3.8 Inter-level knowledge binds templates from different levels of abstraction 48 3.9 Creation of rule instances at different abstraction levels . . . 49
3.10 A policy mapping vs. the proposed knowledge-based rule translation . 50 3.11 The aspects of inter-level translation function . . . 55
3.12 The whole mechanism summary scheme . . . 57
4.1 A rule as a list of tokens . . . 60
4.2 An example of dependencies in a set of rules . . . 62
4.3 The vertical translation process with the use of a production rule system 63 4.4 The translation anatomy - the basic elements . . . 64
4.5 The translation process flow (upper to lower level) . . . 65
4.6 The translation mechanism – fact types awareness . . . 66
5.1 Functional elements of the tool . . . 72
5.2 Components interaction diagram . . . 73
5.3 User interface anatomy . . . 76
5.5 The rule dependency visualization . . . 77
5.6 Integration of the employed technologies . . . 78
6.1 The changes of conditions at different river sections . . . 83
6.2 River sections characteristics . . . 84
6.3 Multi-level approach to the fluvial security system . . . 85
6.4 A sample of knowledge-based translation of a level 1 rule to a level 2 rules 86 6.5 Relations of thread levels and alarm levels for different strategy approaches 87 6.6 Exemplary rule based on template 2 - level 1 view . . . 89
6.7 Exemplary rule based on template 2 - level 2 view . . . 89
6.8 Instatiation of two rules based on provided templates . . . 95
6.9 Listing of instantiated and translated rules . . . 95
6.10 Tree visualization of rule hierarchy . . . 96
6.11 Circular visualization of rule hierarchy, version 1 . . . 97
6.12 Circular visualization of rule hierarchy, version 2 . . . 97
6.13 Plain rule mapping scenario . . . 100
6.14 Rule context check scenario (translation for clay dikes) . . . 101
6.15 Translation context check scenario (translation for concrete dikes) . . . 102
6.16 Rule merging example . . . 103
6.17 Multiple-level rule correlation . . . 104
6.18 Original translation before the rule update . . . 105
6.19 Translation outcome after the rule update . . . 105
6.20 River warning and alert levels calculated for equal dike heights . . . 106
6.21 River warning and alert levels calculated for varied dike heights . . . 106
7.1 The scope of interest of the work within the functionality of CPMP . . . 110
4.1 A general meaning of a metarule . . . 67
A.1 A fragment of policy structure definition including examples of token-based notation of templates in XML form . . . 111
B.1 Exemplary meta-rules definitions . . . 114
D.1 Flex RemoteObject definition . . . 119
D.2 Java endpoint – RemoteRuleManagerServiceHandler class . . . 120 D.3 Java remoting configuration of BlazeDS application – remoting-config.xml121
ACRO Acronyms are typed with slightly smaller font. When mentioned first time, full name of the acronym is given, and the short name in brack-ets. Following occurrences of the acronym are written in short form only. Well known acronyms, such as HTTPorIDE, are not explained inline. If required, in several places full name of the acronym is re-peated despite its previous definition.
Definition Definitions of the important terms and parts that should be empha-sised are typed in italics.
source code Source code is typed in courier font and put inside a frame. Terms connected with the source code in text are also typed in courier font.
Trademark names that appear in this dissertation are the property of their respective owners. Rather than use a “trademark” TM, “registered” , or “copyright” cR symbol
with every occurrence of a trademarked name, author uses the names only in an editorial fashion and to the benefit of the trademark owner, with no intention of infringement of the trademark.
Introduction
Policy/rule-based system architectures gained a lot of interest in the past years. They owe it mostly to the philosophy of the separation of business knowledge from the hard-coded system logic and also the growing usability of knowledge management systems. The comfort of use of a rule-based system is tightly related to its management mech-anisms. In this investigation the author will concentrate on methods of improving the usability of interface for rule supervision by introducing rule dependencies and abstrac-tion level support.
The introduction of the techniques of extraction and separation of a system business knowledge from the system operation logic has been one of the most significant break-through in the software engineering. Such approach considerably alleviates the design and maintenance aspects of computer systems. The concept has evolved and has been applied to an abundant plethora of knowledge-based solutions of different kinds and scale, such as decision supporting systems or adaptive SOA components. In the same way as in a real life, one of the many ways of representing knowledge of computer systems are policies, simply written down as sets of rules.
In recent years, rule-based systems have become increasingly popular [72]. The scale of the increased interest reflects in the number of technologies being developed and the frequency in which they appear. In particular, the amount of platforms implemented (e.g. Oracle Business Rules [115], Drools [107], Jess [110]) as well as the various speci-fications related to rule expression and enactment (e.g. RuleML [131], RIF [123]) have rendered the rule technological landscape quite complex.
However, this evolution can be attributed not only to the better separation of concerns between the knowledge and its implementation logic in contrast to a hard-coded ap-proach; but also to the development of rule repositories that increase the visibility and readability of the knowledge, as well as to better graphical user interfaces that render rules more usable while bridging the gap between users (e.g. domain experts) and IT specialists.
The development of modules that support management of assembled knowledge, in particular Business Rule Management Systems (BRMSs) [85], is a logical consequence of the growing popularity of rule-based solutions. However, the progress in this field is not
that aggressive. Graphical user interface for rule management is not a common feature of policy environments (e.g. Drools Guvnor [119], WebSphere ILOG JRules [111] and Visual Rules [118]). Not all frameworks provide it and stages of advancement differ noticeably.
On the other hand, the process of policy construction is becoming more and more com-plex task. Rule notations vary. Rule bases are becoming more and more sophisticated and lengthy. Rules can form more complicated relations in qualitative and quantitative sense. It is therefore becoming increasingly difficult to comprehend and manage huge rule sets. Indeed, policy authoring and presentation methods as well as coherence con-trol have become a new challenge in the implementation of business logic. The described work presents the possibility to provide an enhancement of policy authoring process.
1.1
Motivation
The usability of a knowledge-based system reflects in the usability of its knowledge management mechanisms. A comprehensive BRMS should lead an end user through all phases of a policy lifecycle [13]: creation (knowledge extraction, rules creation, edition), testing (conflict analysis, transformation), distribution (storage), and enforcement. This thesis focuses on efficient rule creation and categorization, which result in effective policy maintenance.
In the field of rule authoring tools very different approaches may be pointed. For in-stance, ILOG JRules platform uses external documents created in MSWord and then parsed by the platform. Drools Guvnor provides a set of editors for different types of rules (e.g. DRL or BRL markup, decision tables etc). Finally, Visual Rules, provides graph-based decision modelling UI. Created diagrams are automatically translated into policies and thus a user is not faced with semantic issues of rule notation. This approach resembles Business Process Modelling Notation (BPMN) and represents rather a decision workflow than a policy.
The usability of a policy-based system is also tightly related to the ease of use by different actors taking part in the policy management process. The diversity of roles, special-izations, skills etc. should be reflected in knowledge assembling process as introduced in [13] [52].
However, what was mostly put into practice, was dividing the users of a policy-oriented system into two groups: ‘experts’ and ’non-experts’ or ’technicians’ and ’business users’. Some rule creators are capable of providing business logic and the others can translate them into specific configuration parameters of devices or arguments for services. This dichotomy is also visible in the notation approaches. For domain experts it is often easier to express rules through their natural language or graphical diagram, but a majority of academic and commercial solutions concentrate on abstract notation (e.g. RIF [123], RuleML [131], SWRL [133]), which require learning.
User classification to some extent reflects in the definition of policy abstraction. RFC 3198 “Terminology for Policy-Based Management” [6] states that “policy can be
rep-resented at different levels, ranging from business goals to device-specific configuration parameters”. Also the definition of policy translation does not limit transformation of
The dichotomy of user classification results in defining only two basic abstraction layers: higher (HL) and lower (LL). But what if more fields of interest can be depicted?
1.2
Thesis Statement
The author’s main point of interest is the user-centric approach to a rule-based system in order to find features that could mitigate the management of big amount of rules. The main emphasis is put on aspects of rule authoring, rule organization and rule transformation.
The previous section emphasised three interesting issues. Firstly, the stage of develop-ment of rule managedevelop-ment systems does not follow the progress in the rule technologies and the approach to the question is not unified. Secondly, the prevalent dichotomy of rule-based systems users was distinguished. Thirdly, the concept of policy abstraction levels was referred and, resulting from the mentioned dichotomy, the acknowledgement of only two levels was pointed out. It raises a question, if presenting a policy at multiple levels of abstraction could give a diverse insight into the substance of the policy (e.g. for different user types).
While investigating the current state of research, the author did not find a suitable framework that provided management of multiple levels of abstraction. Also, handling of rule dependencies is not fully supported1. Still there is a place for extendingBRMSs
functionality and improving policy authoring mechanisms by investigating and providing new tools. Thus, a new approach is proposed and examined.
This dissertation provides a comprehensive study of current works on rule relations and dependencies. Also, the area of policy abstraction levels utilization in the policy creation process is explored. A detailed study of the existing works in the mentioned areas led to the following thesis statement, which should be investigated:
Creation of a flexible user interface that provides various abstraction levels for rules makes it possible to augment a usage domain of a rule management system.
The augmentation of the usage domain is understood as a significant extension of the standard functionality model, that can be found in existing rule management systems. The improvement bases on adding new features related to the management of policy abstraction levels as well as the introduction of resultant new methods of policy author-ing.
The flexibility of the user interface refers to its open character, i.e. the solution is domain agnostic and can be adopted for any policy field of interest. The dissertation presents the specification of the mentioned interface as well as its prototype implementation, which finally verifies the stated thesis.
The work does not intend to create whole new rule management system, but only build and evaluate a tool providing the features described above. The author does not claim that the solution is the final answer for policy authoring demands or that it is suitable for the creation of every policy. He rather tries to investigate new paths of rule management systems development.
1
1.3
Research Challenges
Flexibility and usability of BRMS graphical user interfaces are limited by insufficient transformation and rule organization support. In response to the aforementioned short-comings the author proposes new concepts for improving existing solutions. These ideas are presented below as the research challenges addressed by this dissertation:
1. providing methods for the specification of a policy abstraction levels and easy rule browsing throughout those levels,
2. providing methods for correlating rules throughout abstraction levels and main-taining information on such rules dependencies,
3. enabling easy inter-level rules translation, based on rule dependencies; in effect a modification of one business rule could affect another rule(s), change it or even deactivate it,
4. providing comprehensive view of gathered knowledge (rules hierarchy
visualiza-tion), with the capability of rule dependency overview,
5. design of an open framework architecture that provides the goals mentioned above and meets ergonomic criteria [57] for user interface design.
One of the clue elements of the dissertation is translation of rules between policy ab-straction levels. However, it is not the goal of this work to provide any semantic-based rule translation. There is no platform so far that provides easy rule translation between different notations. Research on rule engine interoperability via rule interchangeability covering semantic rule translation started only in recent years [39]. Some aspects of the dissertation field of interest resemble a concept called policy refinement [73] [33] [34]. More detailed survey can be found in Chapter 2.
A minor aim of the dissertation is also to investigate methods of building interfaces of Rich Internet Application (RIA) and testing the graphical freedom that they offer to a
GUI designer of rule management systems.
1.4
Research Contribution
The innovative aspect of the dissertation lies in the creation of a open framework with a GUIthat supports rule management by providing end users with different abstraction levels control and enables translations of rules between them based on defined rule interrelations. It can introduceBRMSsto a next stage by creating a flexible maintenance tool that i) unifies policy management for end users representing various domains of interest or different degrees of granularity within one field of interest, and ii) enables better organization of assembled knowledge. The specification of rule correlations can enable easy and dynamic rule rephrasing.
The main achievements of this dissertation are as follows:
• an extended survey into the policy-based approach in computer system design with the main stress put on the current research into rule dependencies perception and policy translation, as shown in Chapter 2;
• the introduction of a notation agnostic, token-based model of a rule and rule
de-pendencies, that enables representation of rules and rule templates regardless their
original format; the approach leaves the rule semantic issues outside of the scope of the work; it eliminates the necessity of notation translations as well as enables any type of rule notation transitions; the approach is open for further functional extensions;
• the formulation of the concept of the knowledge-based vertical rule translation, that enables translating higher level rules into lower level ones with reference to the defined translation context (e.g. global environment or already created rule set); such approach can result in different translation results for different translation conditions;
• providing of policy verification methods (for both created and translated rules) based on the translation mechanism knowledge; the method of meta-knowledge formulation enables including robust mechanisms of, for instance, rule coherence or contradiction check;
• the definition of the necessary domain expert support, i.e. the specification a domain knowledge used by the translating mechanism, including description of a policy characteristics (e.g. rule templates) as well as the domain specific data that propel the translation process; the methodology of gathering and testing the domain expert knowledge is out of the scope of this dissertation and it is taken for granted that, for a specific scenario, the metaknowledge is already prepared; • a proof of concept by a prototype implementation of an open, domain agnostic
framework that supports rule creation, browsing, translation and policy depen-dency visualization; the prototype implementation proves the thesis stated in sec-tion 1.2;
• the presentation of the use of the multi-level policy authoring methodology and verification of its functionality by using it in a real life case study concerning a river dikes monitoring scenario, as shown in Chapter 6.
1.5
Dissertation Organization
In what follows, the organization of the dissertation is outlined.
In Chapter 2, the author presents the extensive background of introducing rule-based solutions into computer systems. Starting from the basic concepts of knowledge, the chapter aims at showing the crucial aspects of policy structuring. In particular, many issues related to policy translations and rule dependencies are studied.
Chapter 3 aims to present a new approach to policy structuring and maintenance based on concepts of rule abstraction levels and vertical rule translation. Having defined the main goals of the system concept, the chapter thoroughly defines the formal models of essential mechanisms - rule instantiation and vertical rule translation.
Chapter 4 demonstrates the anatomy of the mechanisms that propel knowledge-based vertical policy translation, created on the base of the ideas given in Chapter 3. Among other things, the chapter describes the token representation of rules and rule interre-lations as well as the novel approach to translating engine. The further details of the mechanisms implementations are explained in depth in Chapter 5.
Evaluation and verification of the thesis are performed in Chapter 6. The chapter presents a Case Study that relates to authoring as well as visualizing policies for a river dikes monitoring system. It also widely presents the capabilities of the implemented tool.
The dissertation ends with a summary and further work described in Chapter 7. The chapter discusses the achieved results and shows possible ways of enhancing the created solution with additional functionalities.
Related Work
This chapter aims to introduce the issues relating to governance of policies through-out multiple levels of abstraction. It begins with the basic concepts of knowledge, its representation in the form of policies and its position in computer systems. In further sections, production rule systems and corresponding rule management systems are pre-sented. Finally, multiple aspects of policy structure and its governance are discussed.
Before presenting the issues relating to governance of policies throughout multiple lev-els of abstraction, this chapter summarizes the fundamental concepts related to this area. Background analysis begins with introducing the basic terms and continues with presentation of the development of concepts.
Firstly the very fundamental ideas of knowledge, its classification and representation, especially in the form of policies are discussed. The stress is put on the evolutionary impact that the separation of knowledge has brought into the computer systems con-struction. Systems that can provide separated knowledge based on policies and the usability of corresponding rule management systems are presented in the next part of the chapter.
The main part of the chapter shows crucial aspects related to policy structuring. This analysis touches upon various aspects that are the base for policy transformations (e.g. the existance of various relations between rules). The survey examines policy-based and rule-based transformation reasons. Finally, attempts of multi-layered and hierarchical approach to policies are presented and the usage of the concept of policy abstraction levels in various works is studied.
In sections 2.1 and 2.2 repsectively, knowledge definition, its types and its application in computer systems are discussed. The influence of policies utilization on system design is shown in section 2.2. Section 2.3 describes modern production rule platforms while section 2.4 shows tools for rule management. In section 2.5 backgrounds and reasons for rule transformations are discussed. The concept of policy abstraction levels is presented in section 2.6. Finally, in section 2.7 rule translation types related to existing rule dependencies are discussed. Conclusions are drawn in section 2.8.
2.1
Knowledge of Systems
Any computer system in order to operate needs to know how to act. At the most basic level its capabilities base on a programmed sequence of behaviours – hardcoded or not, but specific to a system. With the progress of information techniques, machine thinking evolves – computer systems become more and more capable of using provided data in more and more sophisticated ways. In 1965 John McCarthy coined the term Artificial Intelligence (AI) [97] defining it as “the science and engineering of making intelligent
machines” [98]. Eventually it turned out that machines could have knowledge.
2.1.1 Knowledge
The concept of knowledge has been discussed for centuries. The ancient Greek philoso-phers (Plato, Aristotle)assumed that it originates only with people. In the modern Western philosophy knowledge is perceived as a stand-alone artefact (i.e. a physical record) that could be captured in technology.
The academic community has spent years discussing and clarifying what constitutes data, information and knowledge [96] [67]. Worthington [68] gives a definition that is close to the computer science understanding – Knowledge is “a physical, mental, or
electronic record of relationships believed to exist between real or imaginary entities, forces, and phenomena.”
The Data Information Knowledge Wisdom (DIKW) pyramid [69] [19] presents an inter-esting concept of the relationships between Data, Information, Knowledge, and Wisdom (also known as Intelligence). Data as its base, followed in the hierarchy by Information, then Knowledge, with Wisdom at the top (Figure 2.1).
DATA INFORMATION KNOWLEDGE WISDOM Adding value: contextualised, categorized, calculated, corrected, condensed Adding value: comparison, consequence, connections, conversations Adding value: action-oriented measurable efficiency wiser decisions
collective application of knowledge in action
experience, values, context applied to a message
a message meant to change receiver’s perception
discrete, objective facts about an event
Fig. 2.1: The Data, Information, Knowledge, and Wisdom pyramid
Knowledge differs from data or information in that new knowledge may be created from existing knowledge using logical inference. If information is data plus meaning then knowledge is information plus processing. A common form of knowledge, e.g. in a Prolog program, is a collection of facts and rules about some subject.
2.1.2 Types of Knowledge
Knowledge may originate from different sources, may be formed or composed in various manners, may be applied to diverse objectives etc. Therefore, attempts of knowledge
categorization were taken, e.g. one shown in Table 2.1 (source: [11]). Type of knowledge Characteristics
Domain knowledge Domain knowledge is valid knowledge for a spec-ified domain. Specialists and experts develop their own domain knowledge and use it for prob-lem solving.
Meta knowledge Meta knowledge can be defined as knowledge about knowledge.
Common-sense knowledge Common sense knowledge is a general purpose knowledge expected to be present in every nor-mal human being. Common-sense ideas tend to relate to events within human experience. Heuristic knowledge Heuristic is a specific rule-of-thumb or argument
derived from experience.
Explicit knowledge Explicit knowledge can be easily expressed in words/numbers and shared in the form of data, scientific formulae, product specifications, man-uals, and universal principles. It is more formal and systematic.
Tacit knowledge Tacit knowledge is the knowledge stored in sub-conscious mind of experts and not easy to doc-ument. It is highly personal and hard to for-malize, and hence difficult to represent formally in system. Subjective insights, intuitions, emo-tions, mental models, values.
Table 2.1: The knowledge categorization
The presented definitions (in particular domain knowledge, meta knowledge) will be referenced in the following parts of this work.
2.1.3 Knowledge-Based Systems
Knowledge-Based Systems (KBSs) form the major family members of theAI group [16]. It goes beyond the decision support philosophy by transferring the expert system tech-nology into the decision making frameworks. The term Expert System (ES) [15] is normally used to refer to a highly domain-specific type of KBS used for a specialised purpose such as medical diagnosis, while KBS refers to a system for extending and/or querying a collection of knowledge codification [10]. Thus, KBS can use and generate knowledge from data, information and knowledge (DIKWpyramid). What distinguishes these systems from the traditional computer systems is the capability of understanding the residing information/knowledge and taking decision based on it, whereas the regular systems do not comprehend the data/information they process. [11]
Knowledge-Based Systems take advantage of new artificial intelligences, as well as neural networks [63], fuzzy logic [70], genetic algorithms [71], and soft system methodology [18]. However, the crucial feature of such systems is the separation of the knowledge it consumes, which enables changeability and reuse of this knowledge.
• knowledge base,
• acquisition mechanisms, • inference mechanisms.
A Knowledge Base is used as a repository of knowledge in various forms, e.g. facts and rules about some subject [66]. It may also include an empty Workspace to store temporary results and pieces of information. Knowledge Base (KB) and a search program called Inference Engine (IE) constitute the main part of a KBS. The IE is a software program, which infers the knowledge available in KB.
A separate subfield ofAI concerned with designing and using systems for storing knowl-edge is Knowlknowl-edge Representation. A body of formally represented knowlknowl-edge is based on a conceptualisation - an abstract view of the world that we wish to represent. In order to manipulate this knowledge we must specify how the abstract conceptualisation is represented as a concrete data structure. An ontology is an explicit specification of a conceptualisation. One of the technology options for modelling knowledge are rule engines [96] that will be widely discussed in section 2.3.
Explanation Reasoning
Knowledge Base
Inference Engine
Self LearningUser Interface
Fig. 2.2: The architecture of a Knowledge-based system
The creditability of aKBSalso depends on the Explanation and Reasoning of the decision
made or suggested by the system and the simulation of such learning process is essential
KBS component. The updates may be either manual or automatical (machine learn-ing). Ideally, the basic frame of a KBS rarely needs to be modified. Abovementioned components are shown in Figure 2.2.
2.1.4 Knowledge Representation – Policies and Rules
In the real world various regulations are met and the concepts of rules and policies are commonly used for describing them. Thus, as it was already mentioned in the previous section, rules and policies constitute a common (but not the only) representation of knowledge.
In fact, the concept was adopted into the computer science ground in the latter century. First works in this area – authorisation policies, obligation policies, were related to the issues of access control, Quality of Service (QoS) (Differentiated Services (DiffServ), Integrated Services (IntServ)) and Internet Protocol Security (IPsec). In the information systems context, “policies are rules governing the choices in behaviour of a (software)
The report of the REWERSE project “Rule-based Policy Specification: State of the Art and Future Work” [84] that provides an overview of the existing approaches to logic and rule-based system behaviour specifications states:
“Here are some of the potential advantages of representing policies with explicit rule-based representations of their semantics. Writing rules is usually faster and cheaper than writing imperative or OO code. The level of abstraction of rules facilitates their expression in user-friendly languages such as controlled natural language. Rules are more concise and easier to understand, share and maintain, especially in a global open environment such as the web, where self-documenting specifications are one of the current approaches to enabling interoperability.”
Formal definitions are included in RFC 3198 “Terminology for Policy-Based Manage-ment” [6] (November 2001). The policy rule is formally defined as:
“A basic building block of a policy-based system. It is the binding of a set of actions to a set of conditions - where the conditions are evaluated to determine whether the actions are performed.”
In the same document RFC 3198 [6] policy is defined from two perspectives that are not contradictory since individual rules may be defined in support of business goals:
• A definite goal, course or method of action to guide and determine present
and future decisions. ‘Policies’ are implemented or executed within a particular context (such as policies defined within a business unit).
• Policies as a set of rules to administer, manage, and control access to
network resources (RFC 3060 [4]).
RFC 3060 “Policy Core Information Model” [4] was published at the beginning of 2001. The Policy Core Information Model (PCIM) and PCIM extended (PCIMe) (PCIM ex-tended) (RFC 3460 [7]) were developed jointly by Internet Engineering Task Force (IETF) and Distributed Management Task Force (DMTF) groups - the two organizations that have been at the forefront of policy standardization. The PCIM declares an object model representing policy information as an extension to the Common Information Model (CIM) [104].
The PCIM defines “the policy classes and associations that are sufficiently generic to
allow them to represent policies related to anything”. However, the initial application
was to represent policies related to QoSand IPsec. The RFC specifies the characteristic, the target and the method of use of policies and rules in a clear manner:
(. . . ) policy is applied using a set of policy rules. Each policy rule consists of a set of conditions and a set of actions. Policy rules may be aggregated into policy groups. These groups may be nested, to represent a hierarchy of policies. The set of conditions associated with a policy rule specifies when the policy rule is applicable. The set of conditions can be expressed as either an ORed set of ANDed sets of condition statements or an ANDed set of ORed sets of statements. Individual condition statements can also be negated. These com-binations are termed, respectively, Disjunctive Normal Form and Conjunctive Normal Form for the conditions.
If the set of conditions associated with a policy rule evaluates to TRUE, then a set of actions that either maintain the current state of the object or transition the object to a new state may be executed.
This fragment points the fundamental assumptions of the most widespread structure and functionality of policy rules: “if-condition-then-action construction”. It represents Condition-Action information model, but it needs mentioning that another approaches has been created (cf. section 2.5.2).
RFC 3060 specifies also some additional features of policy rules that augment the model presented above. For instance options of rule grouping, rule actions execution ordering or rule prioritization:
For the set of actions associated with a policy rule, it is possible to specify an order of execution, as well as an indication of whether the order is required or merely recommended. It is also possible to indicate that the order in which the actions are executed does not matter.
Policy rules themselves can be prioritized. One common reason for doing this is to express an overall policy that has a general case with a few specific excep-tions.
Policies can either be used in a stand-alone fashion or aggregated into policy groups to perform more elaborate functions. Stand-alone policies are called policy rules. Policy groups are aggregations of policy rules, or aggregations of policy groups, but not both. Policy groups can model intricate interactions between objects that have complex interdependencies.
These features (and many more) are selectively implemented in different policy frame-works and policy rule notations. A policy language survey will be presented in section 2.5.2.
In the above sections formal definitions of policies and rules were presented. In the following sections the anatomy of their application to computer system in order to create policy-based systems.
2.2
Policy- and Rule-based Systems
Policy-based systems are autonomic (self-managing) in a way that they autonomously determine which policies must be applied to a certain management situation [31]. There-fore, from the emergence of the idea policies gained wide interest and instantly be-came a popular approach to cope with the increasing complexity of system management (e.g. [29] [103] [2]).
In this section it is discussed how the knowledge separation influenced system architec-tures and motivated the evolution of policy-based systems.
2.2.1 Knowledge in Traditional Systems
A computer system must be provided with business logic unique for an organisation to function, e.g. a single algorithm enclosed in a running program can be perceived as a
representation of the knowledge of this program. At the most abstract level, the logical architecture view of any system can be considered as a set of cooperating components grouped into layers [30]. The most prevalent software architecture and design pattern is the three-tier model [65] [22] [101] (see Figure 2.3):
Presentation layer implements functionality for managing user oriented interaction with the system and provides a bridge between user interface elements and actions and the core business logic processes.
Business layer contains business components that encapsulate the system business logic. This layer coordinates the system, makes logical decisions and evaluations, performs calculations etc. It also provides a transport means between the two surrounding layers.
Data layer provides access to data hosted within the system (e.g. databases) or ex-posed by other systems (i.e. accessed through services).
PRESENTATION LAYER BUSINESS LAYER
DATA LAYER
Fig. 2.3: Three layer system architecture
In fact, in traditional systems it is implied that business components implement the knowledge of the system [20]. Therefore the business knowledge is:
• expressed in a programming language (e.g. Java), • mixed with other functions (e.g. database access), • frequently scattered throughout the system. This causes a series of problems in different fields [14]:
• reusability problems - three layers of a system tend to be tightly interlinked and it is not easy to extract business logic to use it elsewhere,
• audit and control problems - business knowledge tends to be hidden in code is hard to browse or revise,
• collaboration problems - domain experts and technical experts literally speak dif-ferent languages,
• updating problems - business layer is hard to change without unexpected side-effects.
Therefore a new need emerged – to specify, represent and manipulate system knowledge independently from the authoring of system components to enable dynamic change of system policies and reuse of these components.
2.2.2 Anatomy of Separated System Knowledge
The extraction and separation of business knowledge from its implementation signifi-cantly alleviates the design and maintenance aspects of knowledge-based systems [39]. As a generic architecture for such systems a reference model called IETF/DMTF Policy Architecture is found [13]. Even though this architecture is not put out in any of the official documents from the two organisations, it can be found in many Request for Comment (e.g. RFC 2904, RFC 2753) regarding the use of policies in computer communication networks. Policy Enforcement Point (PEP) Policy Decision Point (PDP) Policy Administration Point (PAP) Policy Repository
Fig. 2.4: The IETF/DMTF Policy Architecture
This policy architecture consists of four components as shown in Figure 2.4:
Policy Decision Point (PDP) - evaluates and issues decisions, i.e. examines the poli-cies stored in repository that would be applicable in given circumstance and de-termine what needs to be done to comply with those politics,
Policy Enforcement Point (PEP) - enforces the outcome of those policy decisions,
Policy Management Tool or Policy Administration Point (PAP) - provides a user interface for the creation and further control of policies,
Policy Repository - provides mechanisms for storing policies and retrieving them as needed by the PDP.
Similar elements and terminology are used in [3] or [102]. However, some additional elements that are not considered in the abovementioned model can be found:
Policy Retrieval Point (PRP) - retrieves policies from a policy repository,
Policy Information Point (PIP) - provides external information (e.g. Lightweight
Given such assumptions of policy utilization processes the basic three layer application model that was introduced in Figure 2.3 can be augmented. As seen in Figure 2.5 the essential layers were enriched in modules exposing mechanisms for policy management, enactment and storing.
PRESENTATION LAYER KNOWLEDGE MANAGEMENT BUSINESS LAYER KNOWLEDGE (RULES/POLICIES) DATA LAYER RULE REPOSITORY PRESENTATION LAYER KNOWLEDGE MANAGEMENT BUSINESS LAYER KNOWLEDGE (RULES/POLICIES) DATA LAYER RULE REPOSITORY
Fig. 2.5: Three layer system architecture with separated policy governance
The most important change takes place in the business logic layer. Here not only new policy-related components must be added, but the existing system components must be enriched in two sets of functionalities:
• interfaces that make possible the use of provided separated knowledge, • mechanisms for enforcing the decisions taken by the knowledge module.
Such assumptions radically influence the software construction of a policy-based system, but on the other hand they significantly facilitate dynamic modification of a system be-haviour, without altering the enriched knowledge-enabled system entities that interpret and enforce policies. In effect, rule and policy driven systems are becoming increasingly popular over the past years.
2.2.3 Policy-based Management
Policy-based management is an administrative approach that aims to improve the man-agement tasks by establishing policies to deal with situations that are likely to occur. It can be perceived at various granularity levels, e.g. an overall system (coarse granu-larity level) and a system component (fine granugranu-larity level). A higher level example of policy-based management is Policy Based Access Control framework [102] that provides a strategy for managing user access to systems.
MANAGED ELEMENT
(COMPONENT/SYSTEM)
POLICY CONTROL
SENSORS EFFECTORS
At lower level, by providing policy enactment methods a single component may be augmented to a policy-based managed entity. Moreover, following control theory prin-ciples [23], if the decisions concerning the element behaviour are made based on its current state, the control loop is closed (cf. Figure 2.6), making the element autonomic (self-managing). Such improvement surpasses the basic concepts of management and enters the field of Autonomic Computing [105].
2.3
Production Rule Systems
There are various types of mechanisms that support computer systems with function-alities related to knowledge utilization, e.g. planners (e.g. Drools Planner [107]), pro-cess/workflow managers (e.g. jBPM [121]), complex event processors (e.g. Esper [122]) etc. A separate class of such systems that gained a lot of interest recently are Rule Engines that use the rule based approach to implement an Expert System and are more correctly classified as a Production Rule Systems [113].
The term Rule Engine is quite ambiguous in that it can be any system that uses rules, in any form, that can be applied to data to produce outcomes; which includes simple systems like form validation and dynamic expression engines. While a Production Rule System is a kind of Rule Engine and also an Expert System, the validation and expression evaluation Rule Engines are not Expert Systems.
A Production Rule System is Turing complete with a focus on knowledge rep-resentation to express propositional and first order logic in a concise, non am-biguous and declarative manner.
The above categorization identifies Production Rule Systems as a subset of Expert Systems and also Rule Engines at the same time. Thus it locates PRSs within the intersection of the two mentioned system categories as shown in Figure 2.7.
Expert Systems
Rule Engines Production Rule Systems
Fig. 2.7: Rule Engines, Expert Systems and Produciton Rule Systems relation
Production-System Models have their roots in the formalisms of computer science and mathematics of the forties of 20th century [62]. They were inspired by the logical modus
ponens that says: If A implies B, and we know A, then we can deduce B.
The early production-system models were not implemented on a computer and required “hand simulation” in order to determine their consequences. The first running produc-tion system appears to have been Waterman´s (1970) poker-playing program [64] and a Newell’s works [87] [88]. The approach begun popular in another areas such as human problem-solving [86] and modelling of human cognition [12].
2.3.1 Anatomy of a Production Rule System
The structure of a production rule system is shown in Figure 2.8. The main components are [113] Inference Engine, Working Memory and Production Memory.
The brain of a Production Rules System is an Inference Engine that is able to scale to a large number of rules and facts. The Inference Engine performs Pattern Matching i.e. matches facts and data, against Production Rules (also called Productions or just Rules), to infer conclusions which result in actions.
Inference Engine (ReteOO/Leaps) Pattern Matcher Agenda Production Memory Working Memory RULES FACTS
Fig. 2.8: Production Rule System anatomy
A Production Rule is a two-part structure using First Order Logic for knowledge representation: when <conditions>then <actions>. The Rules are stored in the Pro-duction Memory and the facts that the Inference Engine matches against the Working Memory. Facts are asserted into the Working Memory where they may then be mod-ified or retracted.
A system with a large number of rules and facts may result in many rules being true for the same fact assertion, these rules are said to be in conflict. The Agenda manages the execution order of these conflicting rules using a Conflict Resolution strategy that may make use of e.g. priority relations between rules ( [27], [28]). A production rule system’s Inference Engine is stateful and able to enforce truthfulness - called Truth Maintenance [113].
There are two methods of execution for a Production Rule Systems: a data-driven
Forward Chaining, and a goal-driven Backward Chaining. Systems that implement both are called Hybrid Production Rule Systems. Forward chaining process is easier and more widespread among the existing platforms.
There are a number of algorithms used for Forward Chaining Pattern Matching by Inference Engines including Linear, Rete, Treat, Leaps. Most of the solutions are based on Charles Forgy’s RETE algorithm [90] [92]. They implement and extend the algorithm (e.g. Drools [107] implementation is ReteOO, signifying that it is optimized for Object Oriented systems) [24]. The algorithm has been mathematically proven to be faster and more scalable than more traditional handcoded if... then... solutions [14].
The basic principle of RETE is to take a set of conditions and convert them to nodes. Rules that match on the same exact condition reuse existing nodes in the RETE network. The nodes are then joined to other conditions. At the end of the conditions is a terminal node.
The real benefit of such approach is that the performance is not affected by the number of rules deployed. RETE matches each data instance once for all rules [59]. In case of coding the business logic rules in C/C++/Java, the performance decreases when the number of rules or dataset rises. Moreover, in some solutions (e.g. JESS [110], ILOG JRules [111] and Blaze Advisor [117]), it is possible to deploy and undeploy rules dynamically, what significantly increases their usability.
For accessing a rule engine from a Java Platform, the Java Specification Request for a Java Rules Engine API (JSR-94) [120], was defined. However, it specifies only how to call rule engine, not the rules themselves, because it does not define or favour any rule standard.
What is the result? The Forrester Inc.’s “Market Overview: Business Rules Platforms 2011” [124] concludes with an interesting recommendation: “Stop Coding All Your Business Rules In Java , C#, COBOL , ET AL” stating that
“business rules platforms are better than code for creating and managing de-cision and policy logic, and they belong in your application development and delivery strategy.”
2.3.2 Business Rule Platforms
Over the years diverse technological platforms and frameworks were developed, e.g. WebSphere Operational Decision Management ( [112], previously: ILOG JRules [111]), JBoss Drools (or Drools.Net for .Net) [107], Java JESS programming language [110], Or-acle Business Rules [115], Blaze Advisor [117], Microsoft BizTalk Server [108], Apache Jena Framework [109], OpenRules [114], Pega Business Rules [116]. The business rule platforms market is continuously evaluating and changing, showing vendors consolida-tions, expansions, and/or retrenchments.
2.4
Business Rule Management Systems
The logical consequence in the growing popularity [72] of rule-based systems is the ap-pearance of modules supporting the management of assembled knowledge, in particular Business Rule Management System (BRMS) [85]. Such systems build additional value on top of a general purpose Rule Engines by providing business user focused sys-tems for rule creation, management, deployment, collaboration, analysis and end user tools.
One of the factors that increased popularity ofBRMS was providing graphical interfaces that could alleviate policy management, in particular editing rules, significantly aug-menting the range of potential users. BRMSshelp to deal with two basic problems that policy managers are often faced with:
• great number of rules – in a real life system the number of rules may be significant, which results in policy complexity and makes it difficult to comprehend the whole of the assembled knowledge,
• diverse rule notations – for domain-experts (as opposed to technical experts) it is often easier to express rules through their natural language or a graphical diagram,
while a majority of academic and commercial solutions concentrate on abstract proprietary notations (e.g. RIF [123], RuleML [32], eXtensible Access Control Markup Language (XACML) [102], Semantic Web Rule Language (SWRL) [133], DroolsML [107], Jess [110]).
This issues apply to a system using one production rule system platform. However, in multilayered heterogenic systems different components may depend on different rule engine solutions. In this case governance and policies coherence renders troublesome. Moreover, not much work is done in this field [41] [38].
2.4.1 BRMS Functionality
A Business Rules Management System, as any system, obviously needs to fulfil func-tional and non-funcfunc-tional requirements leveraging on possibly friendly user interfaces. Generally speaking the main goal is to allow managing rules in multi user environment, providing single point of access.
Since there is a granted lifecycle of a policy [95], the most methodical way to describe its management interface is to refer to the lifecycle phases. The successive stages of the rule existence during the application runtime present as follows [13]:
1. creation, 2. transformation, 3. storage, 4. merging (analysis), 5. adaptation to environment, 6. expiration time.
The subsequent analysis of the rule management interface adheres to the phases listed above. The detailed analysis of a policy generation process is not the main goal of this work, but it is examined for the sake of the following study of augmenting the policy treatment.
Rule management (creation and transformation phase)
The rule creation phase target at both the various ways of articulating rule as well as different notation formats (a spoken language, a specific rule mark-up language, a decision table). Another story is providing the abstract data model for the rule domain, including templates, constraints etc. and then the way of casting them into the rules created. These issues address uncountable details of rule editors implementation, text or graphical alike. Policies also need documentation for their future treatment and proper making use of (e.g. information on author and creation date, modifications, transformations).
Rule storage (storage phase)
A BRMS facilitates access to a policy repository. In order to ease the comprehension of the knowledge gathered, it should provide some ways of knowledge aggregation and segregation, for instance packages that allow grouping different knowledge bases in sep-arate assemblies together with its model (fact types), business and technical rules (of different categories), tests and so on. A rule repository also provides some functionality for convenient data access, e.g. access control, versioning (database snapshots), easy browsing (by asset status, category etc.) and filtering including personalized user views (i.e. business user view showing only a subset of rules).
Rule validation (merging/analysis phase)
Rule validation is an extensive question. When there are many authors managing op-erating behaviours, conflicts may arise not only during the rule definition phase, but also at run-time. Hence, BRMS should provide tools for tracing inconsistencies, solving conflicts (i.e. with rule prioritizing). The action may employ dedicated self-healing or self-protection policies, but also provide help in policy modification in for its optimiza-tion purposes (i.e. merging similar rules).
Rule activity control (deployment and expiration phases)
The issues of this stage include building rule packages, its distribution and deployment, but also logging of policy evaluation actions. Various schemes may be available for the user, such as dedicated scripts, common repository in a system or publish-subscribe messaging scheme [13].
A technologically advanced feature is a runtime access to a working memory for com-prehension of the system state or a user’s interference (i.e. removing facts in the real time etc.). The last question is visualization of policy deactivation (by user’s action) or expiration (according to policy timing settings)that can be accompanied with a report or a choice of possible actions to be taken ( e.g. reactivation, modification or deletion).
2.4.2 BRMS Platforms
MostBRMSvendors have evolved from rule engine vendors to provide development lifecy-cle solutions for business-usable software that takes advantage of declarative definitions of business rules executed in their own rule engine. Some vendors come up with dif-ferent approaches as well, e.g. they map decision trees or graphs (called ruleflows) to executable code.
In the context of the rule creation and authoring, three general groups of rules editing methods in BRMSs can be distinguished:
• verbal (e.g. JESS, OpenRules),
• verbal supported with graphical editors or wizards (e.g. Drools Guvnor), • graphical (e.g. Visual Rules, ILOG JRules).
Some products, come out with their proprietary authoring solution, but others take advantage of existing, well known editing mechanisms. For instance, for rule creation OpenRules leverages on graphical interfaces of MS Word and Excel and for collaborative rule management – on Google Docs (e.g. OpenRules [114]). Similarly Drools makes use of MS Excel for defining decision tables.
Some solutions (i.e. Drools, ILOG JRules) utilize Eclipse IDE as well. Rule Studio – rules and ruleflows editing mechanism of ILOG JRules is Eclipse-based end leverages on Graphical Editing Framework (GEF), Eclipse Modeling Framework (EMF) Runtime and Charting and Reporting plug-ins. Rule Studio allows integrated co-editing and debugging of Java code and rules and enables collaboration with business rule authors through integration with Rule Team Server.
Newest releases come out with more and more advanced graphical features. However, Forrester Inc.’s BRMS market overview of year 2011 [Forrester2011-1] states that
“the functional differences between the business rules platforms matter less and less to clients. Most of the products have matured to the point where they share a similar set of features now: a set of developer tools, authoring tools for business experts, execution engines, integration points, and administration and management tools.”
In fact, the correspondence is not that obvious in case of BRMSs. Comparison of two systems – Drools Guvnor [119] (a popular widely used open solution) and Visual Rules Suite [118] (an advanced business product) – brings the conclusion that such management systems may vary in a significant way.
The mentioned systems represent different classes of frameworks with huge functionality gap and diametrical disparity in approach. Not only the methods for rule defining are different, but in result ways of their deployment vary as well. The storage issues may be developed in unlike ways, nevertheless, in this area similar functionality is defined and achieved (i.e. rule database access operations).
Drools Guvnor alleviates writing rules in DroolML notation or using domain-specific, higher-level set of phrases. It also provides mechanisms for converting them into knowl-edge packages and then storing or making them accessible for rule engine. Visual Rules base on fully graphical modelling of ruleflows and then converting them into ordinary Java libraries. Transitional notation is not needed, which makes the rule authoring stage much more available for a business-level user. Technical level rules are not distinguished. The divergence in rule editing approaches and advancement of tooling mechanisms de-rives, in great extent, from the systems characteristics (open project vs. business prod-uct). Nevertheless, the mentioend examples show the trends in BRMSs’ development directions.
2.4.3 Conclusions
Two further paths of the progress of rule management systems could be distinguished. On the one hand further improvement of functionality is expected (i.e. easiness and comprehensiveness of knowledge acquisition and management). This includes adapta-tion of various types of knowledge assets (ruleflows, decision tables, DSL rules etc) and is obviously followed by designing more and more sophisticated user interface for creat-ing, reviscreat-ing, deploycreat-ing, storing rules. On the other hand, taking into account available
production systems technologies, widening of the interoperability of policy- and rule-oriented systems, as well as BRMSs is required. This assumption must result in solving diverse issues of policies and rules transformations.
2.5
Policies and Rules Transformation Aspects
The abundance of BRM technologies and products can be beneficial as different ap-proaches attempt to address a variety of problems. However, it greatly impacts the cooperation of systems that utilize different production rules technologies or the usabil-ity of distributed systems that are built upon components using different technologies to specify their behaviours.
After selecting a production rule platform and defining the business knowledge in the way that the platform imposes, the organisation should have the system implemented successfully. However, the organisation may be faced with the necessity of not only changing (i.e. updating), but also transforming the system knowledge. For instance, according to some political or business decisions the organisation may be forced to transition to another production rule system or begin cooperating with organisation that utilizes different rule system technology.
In case of distributed systems the situation is alike. As far as the system is homogeneous from the point of view of the utilized business rules technology, the knowledge governance does not face problems of policies transformations. The situation complicates when various rule technologies are used. Indeed, the behavioural and functional complexities reduced by rules and policies at the component level translate into management and interoperability issues at the distributed application plane.
Considering such heterogeneity many reasons for carrying transformations of policies or rules are to be taken into account. Mostly they derive from the needs of components cooperation or knowledge unification. The issues can be investigated at both policies and rules levels:
• policy-level: refinement, interoperability, interchange, integration of policies, • rule-level: fields of applications, models, notations, abstraction levels of rules. These aspects will be discussed in the following paragraphs.
2.5.1 Policy-level Transformation Reasons
These issues consider transformation of policies as a whole, i.e. as an entire set of rules. The reasons for carrying such transformations may be different, e.g. clarifying the policy, reducing a number of rules, integrating various policies for cooperation or easy governance purposes. Hence, the purposes of such process are global, but actually they base on modifications of component rules. In following paragraphs policy refinement, interchange and integration issues will be introduced.
Policy refinement
The process of deriving of low-level enforceable policies from high-level administrative guidelines is called policy refinement [73]. It remains one of the most ambitious goals in policy-based security management because it aims to automate the realization of high-level requirements in executable implementations [36].
Early studies (e.g. [37]) highlighted some of the specific issues of the policy refinement and attempted to address them in a very restricted way. There has been renewed inter-est in this problem in recent years [33], [73], [34], which address subsets of the problem such as goal decomposition for refinement or transforming specifications using prede-fined mappings. First solid work [33] proposed a goal-oriented requirements engineering Goal-oriented Requirements Engineering (GORE) method in the field of policy based approaches to network and systems management. Loyola et al. [73] present policy re-finement framework as the result of more methodological approach.
Policy interoperability and interchange
Interoperability refers to the ability of diverse systems and organizations to work to-gether thanks to the capabilities of sharing data or communicating. In policy plane that means the exchange and reuse of policies by different systems or components.
Rosenberg and Dustdar [42] present an idea of Service-Oriented Business Rule Broker. Using it under common Web Service layer allows exposing accumulated knowledge to distant components via so called rule web services. Service consumers have no conscious-ness of exact rule engine existence. The exposed knowledge is actually accumulated within a number of rule engines and also mechanism are provided to exchange gathered rule sets between them.
Above authors [43] presented also a way to incorporate business rules managed by dif-ferent engines into one process-oriented composition depicted by Business Process Exe-cution Language (BPEL). Business Rule Broker service plugged into Enterprise Service Bus (ESB), provided a unified access to the shared knowledge through a dedicated Web service interface.
Mayer [44] presented an extension to the IETF´s basic model to address system-to-system interaction in an inter-domain environment. In order to allow exchange of policy information by multiple domains, Policy Exchange Interface is added to basic Policy Based Enterprise Management (PBEM), facilitating a distributed PBEM. Many aspects are considered, including Policy Exchange, Synchronization and Negotiation.
Facing the abundance of technologies implemented, de Leusse and Kwolek proposed an integration platform for multi-rule-engine distributed systems leveraging on different products (Drools, Jess) [41] [39]. The authors presented a web-based common interface along with supporting tools that allow discovering rule engines in a distributed envi-ronment, retrieving from and registering rules to them and finally interchanging rules between them by providing unique translation utility between different rule notations. As can be seen different approaches for exchanging politics between systems have been presented. The problem has been noticed, but no final concise solution has emerged so far. In fact, the issue is not trival as it incorporates not only transfer of rules from one system to another (e.g. translation, exchange and synchronization questions), but also control of policy correspondence (e.g. negotiations, precedence and conflicts solving).
Knowledge integration
Integration refers to combining basic entities into an integral and unified whole. Police integration process brings together basic policies into one unified policy for sake of gaining the global perspective that can alleviate a unified policy governance. The process is somehow contrary to policy refinement that aims in creating lower-level policies based on higher-level assumptions. It needs to be mentioned that the knowledge integration process covers not only syntax issues, but it can be faced with ontological otherness questions. However, the ontological aspect is not investigated in this work.
Not many works can be found in literature in this area. De Leusse [38] proposed a frame-work for an integration platform for governing policies throughout multi-rule-engine dis-tributed systems that leverage on different products (i.e. Drools, Jess). The system en-ables extracting of basic knowledge artefacts from different policies and combining them into common knowledge items that can be globally managed. In further works [40] such approach is applied in the field of global governance of cross-cloud applications.
2.5.2 Rule-level Transformation Reasons
As opposed to the policy-level, the rule-level transformations focus on a single rule conversion issues. They aim at changing the way of expressing a rule, e.g. for the sake of whole policy transformation or inter-engine rules transfer. Hence, the purposes of such processes are rather local, but actually they constitute the base for transformations of entire policies.
The rule level transformation reasons base on the abundance of rule expression methods. In the following paragraphs the aspects that constitute the fundamental source of such rule diversity (e.g. fields of interest, rules models and notations) will be introduced.
Policy information models and rule categorization
Two approaches to rules classifications are presented in this section. Rule information model emphasises the structure of a rule and categorization bases on a rule purpose. Agrawal et al. [13] specifies three common rule information models:
Condition-Action Information Model – the the most widespread model in pro-duction systems. It distinguishes two parts: condition and action. A rule forms statement: WHEN condition C is true THEN execute action A.
Event-Condition-Action (ECA) Information Model – an extension of the above type that incorporates the concept of event and is useful in situations when the policy evaluation happens asynchronously. A rule forms statement: UPON
occur-rence of event E, IF condition C is true THEN execute action A
Mode-Subject-Action-Target Information Model – the model that bases on modal logic sentences (e.g. deontic or alethic), expressing obligation, possibility, permis-sion, necessity etc. (e.g. Subject S is authorized to action A, Subject S is obliged
to perform action A etc.).
