- Programming New Components
In the informer/requester IM, there is one constraint to be satisfied: query(X1). The constraint simply defines what function needs to take place at this point in the interaction; it does not provide any particular implementation of this function. OpenKnowledge components provide this implementation and there may be many implementations for any particular interaction model.

For the Java version of OpenKnowledge, implementations of constraints are provided in the form Java code wrapped into a Java Archive (JAR) file. These files are shared on the network and contain the code to run when a constraint needs to be satisfied by the model.

Preparing the code to do this has been made as simple a task as possible.

Components must implement a specific (empty) interface that is defined as part of the OpenKnowledge core software. However, they do not need to implement any specific methods other than those required for the constraint satisfaction. In Java, what this means is that the class you write to provide the implementation for the constraints must implement the interface org.openk.core.OKC.OKCFacade. This interface actually defines some methods, so to make programming of components as easy as possible, an implementation of these has been provided in the class org.openk.core.OKC.impl.OKCFacadeImpl. You should extend this class to create your OpenKnowledge component.

Code Listing 1.1. gives the skeleton for an OpenKnowledge Component.

package myokc;
import org.openk.core.OKC.OKCFacadeImpl;

public class MyOKC extends OKCFacadeImpl
{
}

Listing 1.1. Skeleton Class for OpenKnowledge Components

You can see that there is nothing more to creating an OpenKnowledge Component than to extend OKCFacadeImpl.

To make it even easier, the interaction model defines the method signature that you must implement. Because the library works by using reflection on you OpenKnowledge Component classes, you just need to implement the constraints as methods.

Your methods for the constraints should return boolean values; this represents whether the constraint was satisfied or not. You methods can throw exceptions and this will be considered as a constraint failure by the system.

Listing 1.2. shows an example of a full implementation of the stock checker OpenKnowledge component.

package myokc;
import org.openk.core.OKC.OKCFacadeImpl;

public class StockCheckerOKC extends OKCFacadeImpl
{
	/**
	 *   Solve the validItem(X) constraint
	 *   Succeeds if X is a valid item number
	 *
	 *   @param X The item identifier
	 *   @return TRUE if X is a valid identifier,
	 *           FALSE otherwise
	 */
	public boolean validItem( Argument X )
	{
		String itemID = X.getValue();    
		if( StockChecker.validItem( itemID ) )
			return true;
		return false;
	}

	/**
	 *   Solve the inStock(X) constraint. Returns 
	 *   the number of items of X in stock in N.
	 *
	 *   @param X The item identifier
	 *   @param N The number of items in stock
	 *   @return Always returns TRUE
	 */
	public boolean inStock( Argument X, Argument N )
	{
		String itemID = X.getValue();
		N.setValue( StockChecker.checkStock( itemID ) );

		return true;
	} 
}

Listing 1.2. Stock Checker OpenKnowledge Component

The arguments that are passed to your constraint methods match those that are defined in the interaction model. You can use Argument.getValue() and Argument.setValue() to change the interaction's state.

- Creating Component JAR Files
In OpenKnowledge, components can be shared across the network, so that other users can download your component and run it on their machine; that is, they can assume a certain role in an interaction by using your code for that role. The components are shared using a Java Archive, which is similar to a zip file. The easiest way to create these components is by using the tool built into the default user interface.

First you need to publish the interaction model for which you have a component. Once published, search for it on the network. If it is already published on the network, then you can simply search for it.

Expand the role-list for the interaction model in the results table, and click on the role for which you have a component. The button "Create New OKC For Role" becomes available. When you click this button a window will appear that will let you create the component JAR.

- Loading in Local Components
If you have created some OpenKnowledge components in JAR files that you have stored locally on a disc, you can load these into the local state of your peer. To do this, use access the File menu and select "Import OKC". You will be presented with a dialog box from which you can select the OKC JAR file.

Note that restoring OKCs from disc into the state of your local peer will not subscribe your peer to any role; to do this, read section Publishing Components below. The component you have loaded will appear under the "Local Components" under 'My Peer'.

- Publishing Components
Publishing components is very easy from the user interface. Once a component has been loaded into the local state of your peer (see section Loading in Local Components above) you can select that component from `My Peer' (it will be listed under 'Local Components'). Once selected click the 'Share Component' button; this will send a copy of the component to the network where it can be retrieved by other parties and used by them.

-- Programming a New Visualisation
Visualisations are small user interface modules that are used to satisfy constraints in an interaction model. They are entirely distinct from the user interface, but the user interface is responsible for providing a means for displaying them on the screen (see section on Providing Alternate User Interfaces).

Visualisation described how visualisations are incorporated into interaction models. They utilise the visual(,) operation. The LCC below shows as example of the visualisation introduced earlier.

visual(getMyName(N), qask("Please enter your name",N))                  (1.14)

The first part of the visualisation definition is the interaction model constraint (getMyName(N)), and the second part is the visual term (qask("Please enter your name",N)).

The visual term does not specify how the visualisation will be realised, it only provides a hook for providing implementations. This means that a peer may have many implementations for a particular visual term, while also allowing different devices to have different implementations. For example, an image viewer on a mobile phone will be different to that on a desktop PC. There are a number of visual term implementations built-in to the kernel; see Visual Constraints for a list.