SEAGENT is a framework which facilities development of Multi-agent Systems in the semantic web environment.
WoDQA is a federated linked data query engine which can be used to query the datasets in Linked Open Data Cloud or in enterprise linked data clouds.
Ege University Linked Open Data Portal is the first Linked Open Data attempt in Turkey, which is initiated by SEAGENT research group.

Contents

  1. Introduction

  2. Modeling a Simple E-Commerce Organization

  3. Implementing the Customer Side

  4. Implementing the Seller Side

  5. Running the Example

1.Introduction

Communication is probably the m ost fundamental feature of agents. Agents are capable of messaging asynchronously, and they isolate the developers from the communication layer by providing communication using agent names directly. FIPA describes an Agent Communication Language (ACL) and SEAGENT agents communicate with each other using an implementation of FIPA ACL. In agent platforms, like JADE [1], agent developer prepares and reads the messages that conform to the ACL. In SEAGENT, those messages are not programmed by the developer. Communication of SEAGENT agents is programmed within HTN plans by indicating the required parameters, and ACL message is prepared and read automatically by agents.

FIPA describes some interaction protocols for agent communication. These protocols indicate the structure of message passing. SEAGENT Development Environment provides usage of these protocols and also developing new protocols for an agent organization. Plans which include communication must be developed according to protocols to ensure correct messaging. SEAGENT Development Environment helps developer by creating template plans according to protocols. Also, it checks that the plans are compatible with the protocol. A working example is explained in this tutorial to demonstrate the agent communication in an agent organization and usage of protocols in the development of an organization. This tutorial assumes that you have completed the SEAGENT IDE Starter Guide.

2.Modeling a Simple E-Commerce Organization

In this tutorial, a simple e-commerce organization is designed and implemented using SEAGENT. Open a SEAGENT project SimpleECommerce . In an e-commerce organization, providing information to customers about goods is a goal of the organization. Put a complex goal onto the diagram and name it InformCustomerAboutPrices . (see Figure 1)

The goal InformCustomerAboutPrices can be refined to sub goals. Someone query about the prices of goods ( QueryPrices ) and someone replies the query( InformAboutPrices ). (see Figure 2) These are two perform goals, and agents which achieve those goals execute plans directly for them. An and refinement is applied to this goal because both of goals must be performed to make InformCustomerAboutPrices be achieved. Put an and refinement node and connect InformCustomerAboutPrices to the refinement via Complex Goal Refinement . Then construct Refinement Assignment links between and node and perform goals. (see Figure 3)

Figure 1. InformAboutPrices complex goal.

Figure 2. InformAboutPrices and QueryPrice perform goals.

Two conspicuous roles are Seller and Customer as seen below. Perform goals are assigned to roles as individual goals that contribute to achieve the complex goal.  Complex goals and goal refinements are early analysis elements and do not appear at run-time. (See Figure 3) They provide a mechanism for goal oriented analysis of the system [2].

Figure 3. And refinement for complex goal, and Seller and Customer roles

To specify the communication for achievement of goal InformCustomerAboutPrices , we define which protocol will be used between agents. Although it is possible to define a new protocol, the query and reply process represented by the goal InformCustomerAboutPrices conforms to the Query protocol of FIPA. For this reason, Query protocol which is a predefined protocol in the SAEGENT Development Environment can be imported to the organization. To do this, right click to the organization diagram and select Load Query Protocol from the context menu. (See Figure 4) This operation puts a protocol into the organization diagram. (See Figure 5)

When double-clicked to the protocol QueryProtocol , it can be seen that two roles, Initiator and Participant , and messages of the protocol is specified. Agreement part is removed from protocols because it is handled automatically by the agent. Agents in current version can refuse the communication request if it does not have the same organization knowledge. After removing agreement, the protocol contains Query , Inform and Failure performatives. (see Figure 6)

Figure 4. ‘Load Query Protocol’ in context menu

Figure 5. Query Protocol loaded to the organization

The protocol QueryProtocol is assigned to the goal InformCustomerAboutPrices by constructing a Protocol Assignment , which can be found under Links part of the palette, from the goal to the protocol. This determines that plans which achieve perform goal must be compatible with the messages of the protocol. A protocol assignment also specifies which role is the initiator and which one is the participant of the protocol. According to the direction of the communication, we set the role CustomerRole as the initiator and the role SellerRole as the participant of the protocol from the properties view. (See Figure 7 )

Figure 6 . Query Protocol

Figure 7. Protocol Assignment to InformCustomerAboutPrices complex goal

Lastly, create QueryPricePlan plan and ReplyQueryPricePlan plan and construct the Plan Assignment from perform goals to plans as seen in the figure below.

Figure 8 . Complete E-Commerce Organization Model

3.Implementing the Customer Side

QueryPrice goal of the Customer role is implemented with the BHQueryPrice behavior. After the organization model is constructed, when the QueryPricePlan is double-clicked, a template plan which sends and receives messages according to the protocol is created and opened. (See Figure 9)

Figure 9. Auto-generated QueryPricePlan

This behavior, firstly, sends a Query message to the Seller and then waits for the reply. The reply can be Inform or Failure according to the protocol. Sample provisions and outcomes are added to the actions. This template plan can be adapted for the requirements. New parameters can be added to the actions and types of the parameters can be changed. You can drag and drop new actions to the plan and connect them to the flow of the plan with suitable links.

A point to note that is activationClassName property of an HTN action indicates the Java class which will perform the job of the action. From the HTN editor, these action classes can be generated. For the tutorial, we place the action classes of customer side into a package which is named ‘com.simpleecommerce.customer’. Thus, write activation class name of the actions in the plan as qualified with this package name. Right click on the ‘src’ folder in the project and add a new package ‘com.simpleecommerce.customer’. Then, right click on the plan diagram and select ‘Action’ from ‘Generate HTN’ menu. It will ask you for an output folder and select newly created package here.

Figure 10 . Select the appropriate package to generate action classes.

After generating action classes, the outline of the project is figured below. There is an error in the model because the other side of the collaborative InformCustomerAboutPrices goal has not been implemented yet. Now, you will fill the Execution Method s of the action classes.

Figure 11. View of the customer package after action classes are generated.

The ACAskPriceToSeller shows an input dialog to ask the good name to the user and then sets the given value to the outcome. It also adds the receiver agent name (name of the seller agent) for the message. The ACReceivePriceMessage shows the price of the asked good in a dialog window. The ACHandleFailureMessage shows a dialog window similar to ACReceivePriceMessage.

/**

* Action class of ACAskPriceToSeller.

*/

public  class ACAskPriceToSeller extends Action {

...

 /**

* Execution method.

*/

 @ExecutionMethod

 public  void execute() {

 // ask user for good name...

String goodName = JOptionPane

. showInputDialog ( "Good name to ask its price: " );

 // set the outcome....

 this .setGoodDescription(goodName);

 // add receiver agent...

 this .addReceiverAgent( " This email address is being protected from spambots. You need JavaScript enabled to view it. " );

}

}

Figure 12 . Execution method of ACAskPriceToSeller.

/**

* Action class of ACReceivePriceMessage.

*/

public  class ACReceivePriceMessage extends Action {

...

 /**

* Execution method.

*/

 @ExecutionMethod

 public  void execute() {

JOptionPane. showMessageDialog ( null , MessageFormat. format (

"The price of the good is 0." , this .getGoodPrice()));

}

}

Figure 13 . Execution method of ACReceivePriceMessage.

/**

* Action class of ACReceiveFailure.

*/

public  class ACHandleFailureMessage extends Action {

...

 /**

* Execution method.

*/

 @ExecutionMethod

 public  void execute() {

JOptionPane. showMessageDialog ( null , MessageFormat. format (

"The price of the good is 0." , this .getFailureMessage()));

}

}

Figure 14 . Execution method of ACHandleFailureMessage.

In the rest of this section, construction of this auto-generated plan from scratch is explained. Drag a behavior from the palette, drop it to the diagram, and give the name from the Properties view.

Figure 15 . Behavior of the QueryPricePlan.

Then, put an action, ACAskPriceToSeller , to the plan. Set the activation class name of the action with fully qualified name as seen below. We will put the action classes of this plan into the ‘ com.simpleecommerce.customer ’ package. Therefore, add this package name in front of class names.

Figure 16 . First action of the QueryPricePlan.

Construct a subtask link between the behavior and the action as seen below.

Figure 17 . Connecting the subtask link between first action and BHQueryPrice behavior.

After that, add an outcome, goodDescription , to the action and set type of it as ‘java.lang.String’.

Figure 18 . Adding outcome to the ACAskPriceToSeller

Figure 19 . Putting a REQUEST message.

The action in Figure 9 retrieves the good description from the user and sends it to the seller to ask its price. To do this, drag a message from the communication category in the palette. Set its performative as ‘REQUEST’ communicative act from the Properties view. This is the first message of a FIPA Request Protocol[3].

To send the queried goodDescription in the Request message, create a sender link from the outcome to the message. This sender link provides sending an ACL message asynchronously. Fields of the ACL message are assigned automatically at run-time. It only requires the receiver agent name and this is set in the action implementation class.

Figure 20 . Create a sender link from ‘goodDescription’ to ‘REQUEST’ message.

Then add the next action, ACReceivePriceMessage , that waits for the reply message. It has a provision, goodPrice , which gets an integer (java.lang.Integer) value from the received INFORM message. To transfer this value put a message, set performative as INFORM and create a Receiver Link from message to the price provision. Do not forget to set the activation class name of the action.

Figure 21 . Receiver Link from the INFORM message to ‘goodPrice’ provision of ACReceivePriceMessage.

In addition, construct an order link from the ACAskPriceToSeller to the ACReceivePriceMessage to indicate that the ACReceivePriceMessage will be executed after the ACAskPriceToSeller. If you don’t use the order link, the plan represents a parallel execution of actions which is not the expected design for this behavior.

Figure 22 . Order link between actions to determine the execution order.

To handle a failure in the query protocol, you should add a new action too. The ACHandleFailureMessage action writes a message about the failure. Put a message whose performative is FAILURE and connect this message to the failureMessage (java.lang.String) provision of the action.

Figure 23 . FAILURE Message which is received by the ACHandleFailureMessage.

Now, the plan waits for two messages that only one of them will be reached to the agent. To represent this conditional state, construct an order link from the ACAskPriceToSeller to ACHandleFailureMessage and set outcome state of this order link to ‘FAILURE’ while the other one is ‘INFORM’ as seen in the figure.

Figure 24 . INFORM and FAILURE outcome states of the order links from ACAskPriceToSeller

After the plan is completed, action classes are generated and the execution methods of these classes are filled.

4.Implementing the Seller Side

When the Query message of the agent which plays the Customer role, is reached to the agent which plays the Seller role, it performs the InformAboutPrices goal by means of the And refinement that is specified in the organization model. The sender agent uses the refinement to set the act into the action content of the ACL message and the receiver agent interprets it.

InformAboutPrices goal is implemented by the ReplyPriceQueryPlan, which contains a behavior named BHReplyPriceQuery . This plan is also constructed automatically using protocol definition. The package name for the classes of this plan is ‘com.simpleecommerce.seller’. Generate action classes and fill them as described below.

The first action, ACReceivePriceQuery , receives a message whose communicative act is ‘REQUEST’ and the queried good description, queriedGood , (java.lang.String) comes from this message. Remember that the name of the sent outcome is ‘goodDescription’ at the customer side. Here, it is time to mention about the assignment strategy. The assignment is, firstly, done by type compatibility. If there is only one parameter that conforms, it is assigned. If there is more than one provision whose types are the same, the name of the argument is taken into account.

Figure 25 . REQUEST message and receiver link on Seller side.  

ACReceivePriceQuery checks the existence of the received good, and if exists, gives it to the ACSendPriceMessage action by a provision link from the foundPrice (java.lang.int) outcome to the price provision(java.lang.int). A sender link is constructed between goodPrice (java.lang.Integer) outcome and an ‘INFORM’ message to send it to the querior agent. If the good does not exist, the order link to the ACSendFailureMessage will be chosen and a message that indicates the failure is sent via Sender Link constructed between message (java.lang.String) outcome and ‘FAILURE’ message. These sent messages correspond to the messages which are received by the QueryPricePlan.

For actions in the plan, create a new package in the ‘src’ source folder which is named as ‘com.simpleecommerce.seller’. Do not forget to add the package names in front of the activation class name property of the actions. Then generate action class templates. Implementation of action classes are explained in the following paragraphs.

The ACReceivePriceQuery chooses the branch will be executed by setting the outcome state. In the execution method, the outcome state is set according to the existence control. This control is done by accessing the data store, which is simulated by a simple hash table as seen in Figure 23.

 

Figure 26 . Conditional branching in the ReplyPriceQueryPlan and sending different messages according to the outcome state of the ACReceivePriceQuery.

/**

* Action class of ACReceivePriceQuery.

*/

public  class  ACReceivePriceQuery extends  Action {

...

/**

* Execution method.

*/

 @ExecutionMethod

 public  void execute() {

 // get goods from data store..

Map<String, Integer> goods=DataStore. getInstance ().getGoods();

 if (goods.containsKey( this .getQueriedGood())) {

 // if the queried good is in the store...

 this .setOutcomeState( "FOUND" );

 this .setFoundPrice(goods.get( this .getQueriedGood()));

} else {

 // if the good couldn't be found...

 this .setOutcomeState( "NOT-FOUND" );

}

}

}

Figure 27 . Execution method of ACReceivePriceQuery

package com.simpleecommerce.seller;

import java.util.Hashtable;

import java.util.Map;

/**

* The class that simulates a data store for the simple e - commerce project.

*/

public  class DataStore {

 /**

* Shared {@link DataStore} instance.

*/

 private  static DataStore instance = null ;

 /**

* Returns the shared data store instance.

*

* @return data store instance.

*/

 public  static DataStore getInstance() {

 if ( instance == null ) {

 instance = new DataStore();

}

 return  instance ;

}

 /**

* Map for goods.

*/

 private Map<String, Integer> goods ;

 /**

* Private constructor for singleton object. It initialized the map

* of goods.

*/

 private DataStore() {

 this . goods = new Hashtable<String, Integer>();

 this . goods .put( "MyNotebook" , 1500);

 this . goods .put( "MyPDA" , 1100);

 this . goods .put( "MyTV" , 900);

}

 /**

* Returns the current good map.

*

* @return map of goods.

*/

 public Map<String, Integer> getGoods() {

 return  goods ;

}

}

Figure 28 . DataStore Java class that contains sample data for the e-commerce seller.

The ACSendPriceMessage and the ACSendFailureMessage sends messages with different performatives (‘INFORM’ and ‘FAILURE’ respectively) by the sender links seen in the plan above. The execution methods of these actions are given below.

/**

* Action class of ACSendPriceMessage.

*/

public  class ACSendPriceMessage extends Action {

 ...

 /**

* Execution method.

*/

 @ExecutionMethod

 public  void execute() {

 this .setGoodPrice( this .getPrice());

}

}

Figure 29 . Execution method of ACSendPriceMessage action class.

/**

* Action class of ACSendFailureMessage.

*/

public  class ACSendFailureMessage extends Action {

...

 /**

* Execution method.

*/

 @ExecutionMethod

 public  void execute() {

 this .setMessage( "The good is not recorded in the data store." );

}

}

Figure 30 . Execution method of ACSendFailureMessage action class.

Figure 31 . Project view after ontology documents and action classes are ready.

Lastly, the organization ontology and the plan ontologies must be generated by right-clicking the project and selecting Generate All Ontologies from the SEAGENT menu.

Figure 32. Generating all ontologies in the project from the context menu.

Now, you are ready to test the application.

Figure 33 . Creating the agent John.

5.Running the Example

Once you created the SEAGENT project, you need to start a platform to create agents that will use this organization knowledge. Start a multi-agent platform, which is named ‘simpletrader.com’, from the menu. Then, create an agent, John , to play customer role and create an agent, Richard , to play Seller role.

Figure 34 . Creating the agent Richard.

If you trigger the QueryPrice goal from the agent, John, it will ask for the good name. Give ‘MyNotebook’ to it and resume. The agent, Richard, will reply the price of the ‘MyNotebook’ as ‘$1500’.

Figure 35. Requesting the QueryPrice goal from the John agent.

Figure 36. View from the execution of the complex goal InformAboutPrices.

6.References

  1. Fabio Bellifemine, Agostino Poggi, Giovanni Rimassa: Developing Multi-agent Systems with JADE. ATAL 2000: 89-103

  2. John Mylopoulos, Lawrence Chung, and Eric Yu. 1999. From object-oriented to goal-oriented requirements analysis. Commun. ACM 42, 1 (January 1999), 31-37.  

  3. SC00026H, FIPA Request Interaction Protocol Specification, FIPA TC C, 2002-12-06.