CHAPTER 4: ARCHITECTURE AND SYSTEM DESIGN OF PROPOSED EXPERT SYSTEM: ESOA Pages: From 49 to 64 This chapter presents the Architecture, frameworf^and system design of the we6-6ased expert system.
This chapter explains the architectural framework of the web based Expert System for Online Assessment (ESOA) of student learning. Since various types of learners are available in the ODL system, ESOA considers all the factors and constraints while conducting the assessment process. I have used a very popular expert system shell named JESS (Java Expert System Shell) in my research work. The system is designed in J2EE (Java 2 Enterprise Edition) environment using MVC (Model View Controller) paradigm. The system integrates an external relational database to store question dataset and academic/performance history of the students. The rule base of the system is designed in the form of XML files. 4.1 Rule Based System The designed expert system is a rule based system. An expert system shell is just the inference engine and other functional parts of an expert system with all the domain-specific knowledge removed. The working principles and the use of different expert system shells are discussed in Chapter 7. Most modern rule engines can be seen as more or less specialized expert system shells, with features to support operation in specific environments or programming in specific domains. A typical rule engine contains: (a) An inference engine (b) A rule base (c) A working memory The inference engine, in turn, consists of: (a) A pattern matcher Page 49
Chapter 4: Architecture and System Design of Proposed Expert System: ESOA (b) An agenda (c) An execution engine The above components are shown schematically in the figure 4.1 Figure 4.1: The architecture of a typical rule-based system. 4.1.1 The inference engine The primary function of a rule engine is to apply rules to data. Thus the inference engine is the core part of a rule engine.the inference engine controls the whole process of applying the rules to the working memory Page 50
to obtain the required outputs of the system. The inference engine works in some discrete cycles which can be explained as: (a) With the help of the pattern matcher, the rules are compared to working memory to decide which ones should be activated during this cycle. This unordered list of activated rules, together with any other rules activated in previous cycles, is called the conflict set. (b) Then the conflict set is ordered to form the agenda. The process of ordering the agenda is called conflict resolution. The conflict resolution strategy for a given rule engine will depend on many factors, only some of which will be under the programmer's control. Then the rules in the agenda are fired to complete the cycle. 4.1.1.1 The pattern matcher The function of the pattern matcher is to decide which rules to apply, given the current contents of the working memory. In general, this is a hard problem. If the working memory contains thousands of facts, and each rule has two or three premises, the pattern matcher might need to search through millions of combinations of facts to find those combinations that satisfy rules. Fortunately, a lot of researches have been done in this area, and very efficient ways of approaching the problem have been found. Still, for most rule-based programs, pattern matching is the most expensive part of the process. Beginning rule programmers often overlook this fact, expecting the procedural righthand sides of their rules to represent all the computational effort in their program. Often the pattern matching technique used by a particular rule engine will affect the kinds of rules we write for that Page 51
engine, either by limiting the possibilities or by encouraging us to write rules that would be particularly efficient. 4.1.1.2 The agenda Once the inference engine records out which rules should be fired, it still must decide which rule to fire first. The list of rules that could possibly fire is stored on the agenda. The agenda is responsible for using the conflict strategy to decide which of the rules, out of all those that apply, have the highest priority and should be fired first. Again, this is potentially a hard problem, and each rule engine has its own approach. Commonly, the conflict strategy might take into account the specificity or complexity of each rule and the relative age of the premises in the working memory. Rules may also have specific priorities attached to them, so that certain rules are more important and always fire first. 4.1.1.3 The execution engine Finally, once the rule engine decides what rule to fire, it has to execute that rule's action part. The execution engine is the component of a rule engine that fires the rules. In a classical production system, rules could do nothing but add, remove, and modify facts in the working memory. But in modern rule engines, firing a rule can have a wide range of effects. Some modern rule engines (like Jess) offer a complete programming language which we can use to define what happens when a given rule fires. The execution engine then represents the environment in which this programming language executes. For some Page 52
systems, the execution engine is a language interpreter; for others, it is a dispatcher that invokes compiled code. 4.1.2 The rule base The rule base contains all the rules of the system. The rules can be stored as strings of text, but most often a rule compiler processes them into some form that the inference engine can work with more efficiently. In addition, the rule compiler may add or rearrange the premises or conclusions of a rule, either to make it more efficient or to clarify its meaning for automatic execution. Depending on the particular rule engine, these changes may be invisible to the programmer. Some rule engines allow (or require) to store the rule base in an external relational database/text files or XML files and others have an integrated rule base. Storing rules in a relational database allows us to select rules to be included in a system based on criteria like date, time, and user access rights. JESS is a rule engine that supports this feature. 4.1.3 The working memory In a typical rule engine, the working memory, sometimes called the fact base, contains all the pieces of information the rule-based system is working with. The working memory can hold both the premises and the conclusions of the rules. Typically, the rule engine maintains one or more indexes, similar to those used in relational databases, to make searching operation in the working memory very fast. It's up to the designer of the rule engine to decide what kinds of things can be stored in working memory. Some working memories can hold
Chapter 4: Architecture and System Design of Proposed Expert System: ESOA only objects of a specific type, and others can include, for example, Java objects. 4.2 Web Based Expert System Architecture In chapter 2, we have reviewed the advantages and challenges of Web Based Expert Systems (WBES). WBES architectures may be characterized according to where the application knowledge base resides. Applications of both client and server-sided WBES architectures appear in the literature. There are three types of WBES architecture. Figure 4.2 shows a typical client-sided architecture where the web page comes with embedded expert system (ES) application code, that is, the knowledge base and any associated code for handling supported queries. This requires the client to have a suitable interpreter for the ES language used. In possession of both application code and interpreter, the client is able to handle user queries withoutfurther reference to the server. This is a fatclient thin-server WBES architecture. Server HTMLffleswIth embedded ES application code URL Request k-- Web Page Client ES Language Interpreter Figure 4.2: Client-sided WBES architecture. Page 54
Chapter 4: Architecture and System Design of Proposed Expert System: ESOA Figure 4.3 shows a typical server-sided architecture where both ES application code and interpreter reside at the server. The client must refer to the server in order to handle user queries. Figure 4.3: Server-sided WBES architecture. The server-sided approach has the benefit of being able to guarantee service regardless of whether or not the client browser has the necessary software enabling it to process the ES application code. However, the quality of service may be compromised by network load and latency problems. The client-sided processing approach is not effected by network issues (once the web page is loaded) but requires specialized software at the client, which may restrict the range of browsers and devices able to receive the service. This is a fat-server thin-client WBES architecture. The most commonly used technique to develop WBESs is to use Java Expert System Shell (JESS), which interprets a CLIPS-like language and utilizes the Rete inference algorithm. Applications are server-sided, requiring Java servlets and the Tomcat Servlet Engine. A more general Page 55
Chapter 4: Architecture and System Design of Proposed Expert System: ESOA server-sided technique is simply to use Common Gateway Interface (CGI) programs to deliver HTML form data to an expert system (with the ES application knowledge base and inference engine) residing at the server and send the response in HTML back to the client's browser. This more general depiction of the server-side approach is illustrated in Figure 4.4. Figure 4.4: Server-sided WBES architecture with CGI The CGI program can message the form data into an appropriate query to the ES as well as convert the response into a convenient form for viewing by the user in the client browser. In a JESS implementation, this is the job of the servlet. This WBES is also a fat-server thin-client architecture and in the design of ESOA, we have used this architecture. 4.3 Design & Methodologyof ESOA The development of most expert systems (Web based or not) embodies a number of challenges that must be surmounted like: domain expert's detection and persuasion for collaboration, knowledge acquisition and knowledge representation, programming, validation, verification etc. Page 56
Additionally, when it comes for Web based expert systems, the extra challenges that must be surmounted are related to design construction and maintain a fairly large and possibly complex Web site/application, which includes the expert system (Dokas, 2005). In the design & development of a Web based Expert system, the web engineering approach should be used. The proposed system named ESOA, uses JSP and Servlet technology along with JESS. The whole system is designed in MVC Paradigm. 4.4 MVC Paradigm MVC' is an architectural pattern used in software engineering. The pattern isolates "domain logic" (the application logic for the user) from input and presentation (GUI), permitting independent development, maintenance and testing of each. The Model: The M in MVC refers to the data object model. The View: The view is responsible for presentation issues. It handles how the client will see the application. The Control: The control part of the paradigm deals with the business logic of the application. It handles how and when a client interacting with the view is able to access the model (McGovern at el., 2004) The Figure 4.5 shows how the three different logical functional blocks work together: Page 57
Figure 4.5: MVC Architecture 4.5 J2EE Framework: The J2EE platform specifies the logical application components within a system and defines the roles played in the development process. J2EE, introduced in 1998, defines a multi-tier architecture for enterprise information systems (EIS). By defining the way in which multi-tier applications should be developed, J2EE reduces the costs, in both time and money, of developing large-scale enterprise systems (McGovern et al.) Four application components are defined within the J2EE platform. They are as follows: Application clients (Standalone Java clients): Clients are generally stand-alone applications written in Java. They run within a virtual machine and can use the J2EE standard services to access components located within another tier. Page 58
Applets (Java code which executes within a browser): Applets are similar to application clients, but execute within a Web browser. Initially applets garnered extensive attention, as they were seen as a means of making Web pages more dynamic. Web components (JSPs, Servlets): Web components are serverside components, generally used to provide the presentation layer to be returned to a client. Two types of Web components exist: Java Server Pages (JSPs) and Java servlets. Server components (EJBs, J2EE API implementations): Server components come in the form of Enterprise JavaBeans (EJBs). EJBs execute within a container that manages the runtime behaviour of the EJB. EJBs are usually where the business logic for an enterprise system resides. J2EE architecture maps onto the MVC nicely. Typically, entity beans are used to provide the model logic, while a mix of entity beans and session beans are used to provide the control logic, and web components are used to implement both control and presentation logic. In practice, however, the separation of the three types of logic is not as distinct, and additional patterns are often needed to support the development cycle. 4.6 Java Expert System Shell (JESS) JESS stands for Java Expert System Shell. It is a rule engine and scripting environment written by Ernest Friedman-Hill in Java language at Sandia National Laboratories, Livermore, Canada. JESS is not an open source product but it is free for academic/research use worldwide. It is written in Java and supports Java APIs.
A program written in JESS may consist of rules, facts and objects. The inference engine decides which rules should be executed and when. A rule based expert system written in JESS is a data-driven program where the facts, and objects if desired, are the data that stimulate execution via the inference engine. (Menken, 2002) JESS provides support for the modular development and execution of knowledge bases with the defmodule construct. JESS modules allow a set of constructs to be grouped together such that explicit control can be maintained over restricting the access of the constructs by other modules. (Menken, 2002) Besides helping us to manage large numbers of rules, modules also provide a control mechanism: the rules in a module will fire only when that module has the focus, and only one module can be in focus at a time. (Menken, 2002). The details of JESS is explained in Chapter 7. For a rule-based expert system, facts and rules are mandatory to make decisions/inferences/results. In ESOA, facts and rules are generated dynamically according to the student's parameters and subject/paper about which the assessment will be conducted. In JESS, facts can be stored in the working memory in three forms: (a) ordered facts (b) unordered facts and (c) shadow facts. Our proposed system uses shadow facts. Shadow facts are just unordered facts that serve as "bridges" to Java objects. Shadow facts are useful as because using this Java objects can be put into the working memory of JESS. The facts for our system will be of two types: (a) student academic/performance history (student facts), (b) questions tagged Page 60
with different levels of toughness (question facts). All these facts are stored in MySQL database. The main reason for not storing the facts directly into the working memory of JESS is that if we do so, the facts will be static for the system. Using JSP and Servlet technology, we will integrate MySql database with JESS and generate some dynamic facts and load into the working memory of JESS. Here JavaBeans are used to implement the shadow facts. A Jess rule is something like an "if... then" statement in a procedural language, but it is not used in a procedural way. While "if... then" statements are executed at a specific time and in a specific order, according to how the programmer writes them, Jess rules are executed whenever their if parts (their left-hand-sides or LHSs) are satisfied, given only that the rule engine is running. This makes Jess rules less deterministic than a typical procedural program. In our system, the rule data are stored externally in XML files. Rules can be generated dynamically from XML files and loaded into the rule base of JESS. 4.7 Architecture of ESOA The ESOA architecture includes mainly five components: Apache Web Server: listens for web page request. «Tomcat Servlet Engine: serves dynamically generated web page using JSP and Servlet technology.
Chapter 4: Architecture and System Design of Proposed Expert System: ESOA MySQL Database: stores the student information and the question bank of various courses. XML: files for external Rule Base. JESS Engine: for online assessment. ESOA Figure 4.6: Architecture of ESOA Working Principle of ESOA: When the online assessment for a particular subject/paper of a programme is needed to start, the administrator will log-in through web-browser. The administrator will then request to start the pre-assessment processes with required/related inputs through web-browser. The servlet will handle the request and sends it to JSP which inturn instantiates JavaBeans for retrieving question fact data from Page 62
MySQL and rules from XML files and then passes them to JESS Engine. JESS Engine then loads the question facts, rules into its working memory, rule base and informs the administrator.» A student will have to log-in and request for the online assessment on the particular subject/paper of a programme through web-browser. The servlet again will handle the request and sends it to JSP which in-turn instantiates JavaBeans for retrieving student fact data and passes to JESS Engine. JESS Engine then loads the student facts into its working memory and rules into its rule base/knowledge base.» The JESS Engine then generates questions for the student based on the student academic/performance history and instantiate JavaBean to store this question set with the student identification information into MySQL database and frees memory, held by the generated question set, from the working memory. The JESS Engine then call JSP to view the question set to the student to answer and keep track of his/her answers. When the student completed his/her examination, JSP will instantiate JavaBean to load the question set given to the student and his/her respective answers from MySQL database to working memory of the JESS Engine and tells the JESS Engine to processes the assessment result. - The JESS Engine, after processing the assessment result, generates some feedbacks and instantiate JavaBean to store the Page 63
student's performance/given feedbacks into the MySQL database and send the result/feedbacks to JSP for the student to view. - The JESS Engine then frees the memory held by the student academic/performance history from its working memory. Pa^e 64