Web Trading
Implementation details of the Web Trading
In the delvelopment of the SOLERES system we have started focussing on the implementation of the Web Trading Agent. The first step has been to create an example application that offers the possibility to test the communication process between the trading agent and an user interacting with our system.
This subsystem application follows the "Query-Searching/Recovery-Response" model and has two main roles: the server and the client. The first role represents the system mediation component and will be waiting the reception of query messages sent by client; the second one reffers to users interacting with our system. Next, we show some implementation details of the example application architecture, emphasizing the Web Trading agent and the user interface agent.
The client and the server roles have been developed like agents objects. The client one is called "AppletApgentQI" and the server agent is the "TraderAgent" class. The first is created from the "ClientContainer" class and the second from the "ServerContainer". Both classes are subclasses of "AgentContainer" class (type of the JADE platform) and are created by the launcher classes "QIApplet" and "Trader" respectively.
Apart from these classes, in the example exit the "SPARQLParser" (interface queries translator to SPARQL language agent), the interface "Lookup" (that represents one of the interfaces that the trader must implement) and the EID (a OWL repository containing the metadata intformation).
For the execution of the implemented example is necessary to follow the next steps. First, we must execute the server process on the computer containing the hosting service. This process will create the agent into an agent container of the JADE platform and the agent (“TraderAgent”) will initialize his behaviour that starts waiting for response sub-behaviour for the query messages.
On the other hand, each client user will access to our application through a web page. This web page will initialize an applet that represents the user interface. The applet is the responsible for the interface agent creation and then, this agent will add his behaviour that starts waiting for the query send confirmation.
Once we have launched both processes, both agents are created living in a JADE Platform and contained in an independent container. This feature allows testing the communication between users executing the application in different places, sending and receiving messages from autonomous containers and JADE Platform.
The communication query process of the web trading agent, since the client user or the client user group establish the query in the user interface to results are shown is performed by two main agents, an interface agent (“AppletQIAgent”) and a mediation agent (“TradeAgent”) using the Lookup ontology to establish the communication.
For the communication ontology (Lookup) implementation, we have made use of the XML format, so the client fills the necessary fields with the correspondent information before send the message. The server (trader) will receive the XML content file and will extract the data from the fields it needs. These operations have been possible making use of the Jdom, Saxon, and other XML libraries.
It is available the lookup.xml file and also the ontology class (Lookup_ontology.java) used for the correct information filling and recovering.
We must remember that the SOLERES system keeps (as a whole) the environmental information distributed in different OWL repositories of two levels; some containing environmental metadata (EIM repositories) and others containing metadata from the first ones (EID repositories). The trader manages an EID repository.
The next image shows a data ontology from an EID repository. Let us remember that the application domain to be modelled here is the ecological information domain (one type of environmental information): cartographical maps and satellite images. The SOLERES system is intended to include advanced algorithms based on neuronal networks to find a correlation between satellite information and cartographical information. These algorithms are being developed by members of the SOLERES workteam.
For the calculation of this correlation, it is necessary a previous treatment of the satellite images and cartographical maps (an image classifcation, Clasification). A cartographical map stores its information in layers (Layer), each of which is identifed by a set of variables (Variable). For instance, in our project we are using cartographical maps classifed into 4 layers (climatology, litology, geomorphology and soils) having more than a hundred of variables (i.e., scrubland surface, pasture land surface, the average rainfall, among others). Something similar happens with satellite images. The information is also stored in layers, but here they are called bands. An example of satellite image are the LAND-SAT images, which have 7 bands (and no variables stored here). Finally, both the cartographical and satellite classi cation have geographical information associated and this one (Classification) is carried out at a given moment (Time) by a technician or group of technicians (Technician). As a complement and formalization for graphs and metamodel, the next table shows the complete assertions of the eight ontologies entities.
The OWL file representing the data ontology is available in the next link: eid.owl
For the extraction of the information from the OWL document representing the data ontology, we make use of the library of the library AgentOWL developed by Michal Laclavik (http://agentowl.sourceforge.net/). At the initialization of the trading agent, we must create a new server port for the communication and specify the name of the configuration file for the creation of the model representing the data contained on the OWL file.
Once the trading agent receives the query and wants to execute it to the OWL file, it must recovers its model and use the "Query", "QueryExecution", "QuerySolution" and "ResulSet" classes to obtain the desired information like we can see in the next code:
The trader agent has the response of the user messages main task. It has been divided in four sub trasks corresponding with four sub behaviours we have implemented for the agent. Next image shows a finite state machine diagram representing the behaviour transitions.
For the implementation of the trader agent behaviour, we use the JADE class named "FSMBehaviour". This class implements a composite behaviour that schedules its children according to a finite state machine (FSM). The "FSMBehaviour" class provides methods to register sub behaviours as FSM states and to register transitions between states. The whole behaviour terminates when a termination state is reached and fully executed. The trader agent behaviour is described in the next code:
4.2. Trader implementation details
Paying attention to the class diagram, the Trader class is the server launcher, the TraderAgent is the agent created by the server and is the responder of the clients queries. The answer task is resolved by the agent behaviour which is implemented in the TraderAgentBehaviourFSM class. The code of this classes is available at the next links:
Trader.java
TraderAgent.java
TraderAgentBehaviourFSM.java
To explain the sub behaviours we offer the class code for each one:
TraderAgentBehaviourFSM_WaitingBehaviour.java
TraderAgentBehaviourFSM_ObtainBehaviour.java
TraderAgentBehaviourFSM_ExecuteBehaviour.java
TraderAgentBehaviourFSM_SendBehaviour.java
The image shows the query user interface window. We have made the choice of a query tree ("Tree Model") to show the data we can query for, as well as to elements we have just added to the current query ("QueryTree").
We can make queries in two ways: manual or supervising. The manual way allows the user to write directly the query into he query section. The supervision one makes possible to buid the query selecting the variables, vuales and operators in the interface.
5.2. Interface Agent Behaviour
The interface agent has the task to recover the query from the user interface and send it to the agent who can solve it. Later, the agent will obtain the query result and show it to the user. This complex behaviuor is divided in seven sub behaviours like is shown in next figure:
Like we have explained in the Trader Agent Behaviour section, for the implementation of the interface agent behaviour, we use the JADE class named "FSMBehaviour". Next, we can see the behaviour class code:
Such as the class diagram shows, QIApplet is the client launcher, the AppletAgentQI is the agent created by the client and is ask environmental information manager. The qurey task is resolved by the agent behaviour which is implemented in the AppletAgentQIBehaviourFSM class. The code of this classes is available at the next links:
QIApplet.java
AppletAgentQI.java
AppletAgentQIBehaviourFSM.java