Introduction

By reading the title , you might think : “Wait a minute. Is there any Stupid SW?”. Please don’t think that, the idea of the post is to show you that there is type of software which aims to emulate Human Intelligence.

When it is time to build Intelligent SW?

Not all problems look alike. There are some problems that can be solved by implementing a set of steps. These kind of problems have an algorithmic solution. On the other hand we have problems that can’t be solve by an algorithmic solution. These are the ones that need Intelligent SW to solve them.
There is more than one Intelligent SW that can be build. Some of them are listed in the table below.

From all these, I will choose the Expert System  to compare with the Traditional Software.

Comparison between Traditional SW and Expert Systems

Some aspects need to be explained. The IDEAL methodology is based on the Spiral Model of the Software Engineering. With the difference that the IDEAL methodology considers the corrective maintenance of the knowledge base.

Another thing to keep in mind is that SW Engineering and the Knowledge Engineering complement with each other. Usually an Expert System is a module of a Software      Engineering project.

Conclusion

- Not all problems can be solved by an algorithmic solution.
-SW Engineering and the Knowledge Engineering can live together.

I hope it helps .

Short Approach…

It’s an excellent idea to combine 2 two technologies such as Drools and GWT to build Intelligent Web Applications. But there is a little bit of a problem at the moment to integrate them. Because Drools and GWT include the org.eclipse.jdt classes but with different JDT version. And when you run your application (mvn gwt:run) you will have an error like this:

Unable to parse module: com.google.gwt.user.User
java.lang.NoSuchMethodError: org.eclipse.jdt.internal.compiler.CompilationResult.getErrors()
[Lorg/eclipse/jdt/core/compiler/IProblem;
at com.google.gwt.dev.jdt.AbstractCompiler$ICompilerRequestorImpl.
acceptResult(AbstractCompiler.java:213)
at org.eclipse.jdt.internal.compiler.Compiler.compile
(Compiler.java:417)
...

Solution…

So to solve this problem you need to add an exclusion to your dependecy (that has the Drools-Core dependency) added in your Maven Gwt Application pom.xml. The exclusion in your pom should look like this:

<dependencies>
    [...]
<dependency>
           <groupId>com.wordpress.nicozan</groupId>
           <artifactId>dependency-with-drools-core</artifactId>
           <version>1.0</version>
           <exclusions>
                   <exclusion>
                           <groupId>org.eclipse.jdt.core.compiler</groupId>
                           <artifactId>ecj</artifactId>
                   </exclusion>
           </exclusions>
</dependency>
    [...]
</dependencies>

Short but helpful

As you might remember in previous posts I have talked about Knowledge Engineering, Expert Systems and Rule Based Systems. Today I’ll get back to those concepts and explain you the Protocol Analysis Method to do Knowledge Elicitation.

Protocol Analysis

Before we begin, I would like to highlight that there are other methods to elicit knowledge such as interviews, questionnaires and repertory grids.
This method have several steps, obviously lets start we the first one :

1- The Idea is to search and capture ,and then study, everything the expert says while he is solving a problem. That’s why we record the experts explanation with a tape recorder during his task. In other words, the expert have to explain what he is thinking.

2- After we record our experts explanation (Protocol),we have to write down the recorded audio and divide the text into segments. Please have a look at the next simple example:
Protocol: “As we can see the Porsche 911 is a very comfortable and fast car, so it is expensive”
Transcription:

In the example protocol,  the expert was explaining what makes a car expensive, thats this ob

3- Now it’s time to identify concepts, characteristics, values, relations and operators. Considering the Drools Expert tool: Concepts are facts, characteristics are the facts properties and values are the values of the properties.
The operators are elements use by the expert to move from a state of the problem to an other state closer to the final solution.
Let’s see the next classification table:

The states in our problem can be Concepts or Characteristics, but not both at the same time. In this case I’ll choose Concepts as states of the problem.
In the table that follows we’ll specify the explicit relations:

A value must be always related to a characteristic. If there is an explicit value in the text but there isn’t the explicit characteristic, we have to write the implicit one between parenthesis like the example above.
Now we represent the implicit relations, that are always between concepts.

After this schema, we draw, what is called,  a “Search Identification”:

4- Now that we have done our search identification it is time to write the rule associated to it. Obviously we’ll be using the DRL syntax of Drools Expert.

rule "It's an expensive car"
when
  $porsche : Porsche911( speed  == "Fast", comfort == “Very Comfortable” )
then
  System.out.println( “Car: ”  + $porsche.getName() + “ is an expensive car” );
end

Well, this short explanation would be enough for you to start your first knowledge elicitation and get closer to the knowledge engineering.

When you first create a GWT App, the project is divided ,usually, into three packages: client,shared and server. In this post we’ll consider the next packages names:
-com.wordpress.nicozan.client
-com.wordpress.nicozan.shared
-com.wordpress.nicozan.server

Refactoring Services

Let’s consider that in the package com.wordpress.nicozan.client we have the interface bankService and we have too the interface bankServiceAsync. This Async-interface help us to communicate with the server side of our application. The server side is in the package com.wordpress.nicozan.server and contains an implementation named bankServiceImpl.
Up to now everything seems nice and simple, but if your application starts to grow and improve, you’ll probably have many services. This means that your client package we’ll have several service interfaces mixed with your widgets and utility classes.
So to avoid having everything mixed up, you decide to create the next packages:
-com.wordpress.nicozan.client.util
-com.wordpress.nicozan.client.widgets
-com.wordpress.nicozan.client.services
This post will focus in the services package. Inside this package we’ll put the service interfaces that are related to the Async interfaces.
At the moment we compile (mvn clean install ), an error will appear. The error will say that the Async interfaces cannot be found. This problem is because by default the gwt-maven-plugin generates the Async interfaces from the service interfaces located in the client package, and it doesn’t look inside the client sub-packages. The way to solve this problem is by adding 2 tags to the plugin configuration inside the pom.xml:

...
<!-- GWT Maven Plugin -->
 <plugin>
       <groupId>org.codehaus.mojo</groupId>
       <artifactId>gwt-maven-plugin</artifactId>
       <version>2.1.0-1</version>
           <executions>
                 <execution>
                       <goals>
                             <goal>compile</goal>
                             <goal>test</goal>
                             <goal>i18n</goal>
                             <goal>generateAsync</goal>
                       </goals>
                 </execution>
           </executions>
       <!-- Plugin configuration. There are many available options, see
         gwt-maven-plugin documentation at codehaus.org -->
      <configuration>
         <runTarget>MyWebApp.html</runTarget>
         <hostedWebapp>${webappDirectory}</hostedWebapp>
          <i18nMessagesBundle>com.wordpress.nicozan.client.Messages</i18nMessagesBundle>  
         <servicePattern>**/client/services/*Service.java</servicePattern>
         <inplace>true</inplace>
       </configuration>
 </plugin>
...

In the code snippet above, the two important tags are servicePattern and inplace. In the first one, we specify a relative path to where service interfaces are. The second tag, specifies that the generated Async interface have to be located in the same package as its analog service interface.

Beginning with the concept, that data it is not information. A table full of rows (i.e. 1000 rows) it can be consider data, and you’ll agree with me that trying to find meaningful data (Information) from the table it’s going to be a tedious task. At this point of the reasoning is when we use Charts (i.e. Line Charts, Pie Charts, Scatter Charts, etc) to summarize the data from the table and in that way we obtain information to make a decision. GWT Visualization will help us to add Charts to our GWT webapp, by using its simple API.

Using the GWT Visualization API

If you are not familiarized with the GWT Framework, you need to have a look at its documentation or my post. Considering that you are using the Maven GWT Plugin, all you have to do is define the next dependency in the projects pom.xml.

<dependency>
  <groupId>com.google.gwt.google-apis</groupId>
  <artifactId>gwt-visualization</artifactId>
  <version>1.0.2</version>
</dependency>

<inherits name='com.google.gwt.visualization.Visualization'/>

If you want to see a basic example working go to this page: GWT Visualization Example.

Short Tip:

If you want to draw a Line Chart and you have dots or coordinates best thing, you should use a Scatter Chart and set the option ScatterChart.Option.setLineSize(1); . The line size has to be 1 or greater than 1.

You might be asking yourself, Why am I doing this post?, because you might think that adding a dependency in a GWT Project using the Maven-GWT-Plugin is just as simple as adding a dependency in a Regular Maven project. Sorry to disappoint but apart from that you have to do something else …

Concepts

Every gwt project has a gwt.xml file that represents the GWT-module. This file contains specific information related to the module, for example:
—Entry-point (The java class that represents the web page that is going to be displayed in the web browser)
—Inherits (External Modules that our GWT-Module uses)

These two elements shown above are represented by tags. These tags are child elements of the root element module . The next code snippet shows how the gwt.xml file is structured.
MyWebApp.gwt.xml

<?xml version="1.0" encoding="UTF-8"?>
<module rename-to='MyWebApp'>
 <!-- Inherit the core Web Toolkit stuff.                        -->
 <inherits name='com.google.gwt.user.User'/>
 <!-- Inherit the default GWT style sheet.  You can change       -->
 <!-- the theme of your GWT application by uncommenting          -->
 <!-- any one of the following lines.                            -->
 <inherits name='com.google.gwt.user.theme.standard.Standard'/>
 <!-- <inherits name='com.google.gwt.user.theme.chrome.Chrome'/> -->
 <!-- <inherits name='com.google.gwt.user.theme.dark.Dark'/>     -->

 <!-- Other module inherits                                      -->
 <inherits name='com.wordpress.nicozan.Model'/>

 <!-- Specify the app entry point class.                         -->
 <entry-point class='com.wordpress.nicozan.client.MyWebApp'/>

 <!-- Specify the paths for translatable code                    -->
 <source path='client'/>
 <source path='shared'/>
</module>

Let’s consider the MyWebApp.gwt.xml shown before and that we have a project with two sub modules : webapp and model. The project has the next directory structure:

parent-project/                                    
|- pom.xml
|
|- model/                                      (External JAR module:)
|  |- pom.xml
|  \- src/main/java/
|     \- com/wordpress/nicozan/
|        |- Model.gwt.xml
|        \- model/utils/Element1.java
|
\- webapp/                                      (GWT-Module)
 |- pom.xml
 \- src/
    |- main/java/
    |  \ -com/wordpress/nicozan/
    |     |- MyWebApp.gwt.xml
    |     \- client/MyWebApp.java
    \- main/webapp/
       \- WEB-INF/web.xml

<module>
<inherits name="com.google.gwt.user.User"/>
<source path="model"/>
</module>

<project xmlns="http://maven.apache.org/POM/4.0.0"
       xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
       xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd">
<modelVersion>4.0.0</modelVersion>

<parent>
  <groupId>com.wordpress.nicozan</groupId>
  <artifactId>parent-project</artifactId>
  <version>1.0-SNAPSHOT</version>
</parent>

<artifactId>model</artifactId>
<version>1.0-SNAPSHOT</version>
<packaging>jar</packaging>

<build>    
  <resources>
    <resource>
      <directory>src/main/java</directory>
      <includes>
        <include>**/*.java</include>
        <include>**/*.gwt.xml</include>
      </includes>
    </resource>
  </resources>
  <plugins>
        <plugin>
      <groupId>org.codehaus.mojo</groupId>
      <artifactId>gwt-maven-plugin</artifactId>
      <executions>
        <execution>
          <goals>
            <goal>resources</goal>
          </goals>
        </execution>
      </executions>
    </plugin>
  </plugins>
</build>
</project>

TIPS/NOTES:
- Don’t forget to add all the dependencies as you usually do in your common maven projects.
- Remember to add the maven-gwt-plugin to the pom.xml of the resource you want generate.
- You don’t need to do all the steps explained above if you are adding dependencies that are going to use on the server-side. In that case just add the dependency to the pom as usual.

* Container: is the top level interface wrapping a real physical container. Cargo supports Local and Remote containers. (In this explanation we’ll be using Local Containers). A Container is composed of a Configuration.
* Configuration: tells the Cargo how the container is to configured (logging, security, data sources, location where to put deployables, etc). A Configuration can be configured to install Deployables before the containers is started.
* Deployer: it is used to hot-deploy Deployables. Hot-deploy means when you deploy a Deployable into a running container.
* Deployables: are archives (WAR,EAR,etc) that can be deployed into the container.

MAVEN 2 Cargo Plugin:
The plugin wraps the Cargo JAVA API and from various types of use cases of it, we’ll explain how to start and stop a container, including deploying some deployables as it starts.
As we said before we’ll run an embedded container.The most basic container you can use in cargo is an Embedded Jetty 4x/5x/6x Container. The following maven 2 plugin definition will configure an embedded Jetty 6x container. Note the use of the embedded type element to specify an embedded container.

[...]
<build>
  <plugins>
     <plugin>
         <groupId>org.codehaus.cargo</groupId>
         <artifactId>cargo-maven2-plugin</artifactId>
         <version>1.0.6</version>
         <configuration>
             <container>
                   <containerId>jetty6x</containerId>
                   <type>embedded</type>
             </container>
         </configuration>
     </plugin>
  </plugins>
</build>
[...]

Now it is time to start deploying our deployables. The deployables are archives (i.e. EAR and WAR) that can be deployed in the container. The code snippet below shows how to deploy deployables in an embedded container, in this case jetty:

<dependencies>
[...]
   <dependency>
       <groupId>com.wordpress.nicozan</groupId>
       <artifactId>my-war</artifactId>
       <version>1.0.0</version>
       <packaging>war</packaging>
    </dependency>
[...]
</dependencies>
[...]
<build>
  <plugins>
     <plugin>
        <groupId>org.codehaus.cargo</groupId>
        <artifactId>cargo-maven2-plugin</artifactId>
        <version>1.0.6</version>
        <configuration>
             <container>
                   <containerId>jetty6x</containerId>
                   <type>embedded</type>
             </container>
            <configuration>
                      <type>embedded</type>
                      [...]
                      <deployables>
                            <deployable>
                                  <groupId>com.wordpress.nicozan</groupId>
                                   <artifactId>my-war</artifactId>
                                   <type>war</type>
                             </deployable>
                      </deployables>
            </configuration>
       </configuration>
     </plugin>
  </plugins>
</build>
[...]

When do we use Cargo?

Imagine that you have a Web App,in Java obviously using the maven archetype. This Web Application is divided in two modules: Client and Server. The hierarchical structure of the project would be like this:
MyWebApp (pom.xml)
—> Client-Module (pom.xml)
—> Server-Module (pom.xml)
Up to now we see a very common structure of a project, but cargo empowers the use of an extra module to start the Functional Testing. We’ll add the module Deployer to our project structure.
MyWebApp (pom.xml)
—> Client-Module (pom.xml)
—> Server-Module (pom.xml)
—> Deployer-Module (pom.xml)
In the Deployer-Module you have to modify its pom.xml and write a configuration similar to the one written in code snippets above, it should be something like this:

  
<dependencies>
[...]
<dependency>
  <groupId>com.wordpress.nicozan</groupId>
  <artifactId>Client-Module</artifactId>
  <version>1.0</version>
  <packaging>war</packaging>
</dependency>
<dependency>
  <groupId>com.wordpress.nicozan</groupId>
  <artifactId>Server-Module</artifactId>
  <version>1.0</version>
  <packaging>war</packaging>
</dependency>
[...]
</dependencies>
[...]
<build>
  <plugins>
    <plugin> 
         <groupId>org.codehaus.cargo</groupId>
         <artifactId>cargo-maven2-plugin</artifactId>
         <configuration>
             <container>
                   <containerId>jetty6x</containerId>
                   <type>embedded</type>
             </container>
             <configuration>
                  <type>embedded</type>
                  [...]
                  <deployables>
                            <deployable>
                                  <groupId>com.wordpress.nicozan</groupId>
                                   <artifactId>Client-Module</artifactId>
                                   <type>war</type>
                             </deployable>
                    <deployable>
                                  <groupId>com.wordpress.nicozan</groupId>
                                   <artifactId>Server-Module</artifactId>
                                   <type>war</type>
                             </deployable>
                  </deployables>
             </configuration>
         </configuration>
    </plugin>
  </plugins>
</build>
[...]

Drools-Guvnor has now the possibility to create, modify and delete Spring Context Files. This new feature allows you to define Drools Knowledge Bases, Knowledge Sessions, Knowledge Agents and Common Spring Beans inside your Spring Context File.

How to Create a Spring Context in Guvnor

You have to go to the Knowledge Bases Tag on the Left Menu and select:
Create New —> New Spring Context.
Like any other asset you will have to give it a name and set in which package it’ll be saved.

It is time to Edit our Spring Context

The next image shows the SpringContext Editor. You will be able to insert new tags in this XML file, by positioning your text cursor in the place where you would like to insert this new tag and then click on one of the options on the left palette. (KSession, KBase, Node, KAgent, Spring Bean)

Another feature of the SpringContext editor is that we can validate our XSD file against the XSD file implicitly referred in the Spring Context File. All you have to do is go to : Source—> Validate.

Adding New Buttons to our Palette

If you want to add new buttons to your palette, Drools Guvnor allows you to do this through a Properties File. The name of the file is springContextElements.properties, it’s located in the path:$GUVNOR_HOME/WEB-INF/Clases/springContextElements.properties.

Downloading The Spring Context Files

Each spring context is exposed through an URL. These URLs could be found at the bottom part of the Package editor where the context files are defined.

Stay tuned for updates related to Drools… , this new feature is now in the trunk, in Drools 5.2.0.M1.

On the client-side, we have 2 Interfaces that will be the key to our communication with the server-side.

BankClient.java

package com.wordpress.nicozan.client;
import com.google.gwt.user.client.rpc.RemoteService;
public interface BankClient extends RemoteService {
  public String askForLoan(String s);
}

BankClientAsync.java

package com.wordpress.nicozan.client;
public interface BankClientAsync {
   public void askForLoan(String s, AsyncCallback<String> callback);
}

The nature of asynchronous methods requires the caller to pass in a callback object that can be notified when an asynchronous call completes, since by definition the caller cannot be blocked until the call completes. For the same reason, asynchronous methods do not have return types; they generally return void. Should you wish to have more control over the state of a pending request, return Request instead. After an asynchronous call is made, all communication back to the caller is via the passed-in callback object.

On the server side we just have 1 class, that implements the methods of the BackClient interface.

Bank.java

package com.wordpress.nicozan.server;
import com.google.gwt.user.server.rpc.RemoteServiceServlet;
import com.wordpress.nicozan.client.BankClient;
public class Bank extends RemoteServiceServlet implements
    BankClient {
  	public String askForLoan(String s) {
			if (Integer.parseInt(s) <= 1000){
				System.out.println("granted");
				return new String("Loan Granted");	
		 	}else{
		 		System.out.println("Deny");
		 		return new String("Loan Denied");
		 	}

        }
}

Up to now we have defined all the necessary elements, but how should we use them?. Usually in common WebApps we have to define and map our servlet in the web.xml file:

...
<servlet>
   <servlet-name>bankServlet</servlet-name>
   <servlet-class>com.wordpress.nicozan.server.Bank</servlet-class>
   <load-on-startup>1</load-on-startup>    
</servlet>
  
<servlet-mapping>
    <servlet-name>bankServlet</servlet-name>
    <url-pattern>/bankServlet</url-pattern>  	
</servlet-mapping>
  	
<servlet-mapping>
   <servlet-name>bankServlet</servlet-name>
   <url-pattern>/com.wordpress.nicozan.Application/bankServlet</url-pattern>
</servlet-mapping>  	
...

Please remember that one servlet can be mapped in more than one URL, no the other way around. GWT needs an other definition of the servlet in the Module Configuration File,”Application.gwt.xml” :

…      
<servlet path="/bankServlet" class="com.wordpress.nicozan.server.Bank"/> 
...