In the following, you will use a MAS with an environment deployed on multiple machines. You will develop some agents joining a remote workspace of this environment. The code is thus organized into two JaCaMo configuration files (.jcm): one for the MAS "kind-of" server, one for the MAS "kind-of" client.

• The MAS server part ("step_main.jcm") provides you with the configuration file where some artifacts are deployed in the "server" workspace.
• The MAS client part ("step.jcm") is refering to the agents that you will have to customize or develop. These agents will connect on the remote workspace to use artifacts that are deployed on this remote workspace.
• For an agent deployed in the client part, use the action in the agent code: "joinRemoteWorkspace("default","localhost",WspID2)" where you replace "localhost" by the machine IP number.

In this step, the configuration is as follows:

• In the workspace running on the server, a very simple artifact of type "EnvBasic", called "env" has been deployed. This artifact will be enriched step by step with actions and observable properties.
• The first version of this artifact has one action "printMsg(String msg)". This action prints the parameter "msg" on the standard output adding the name of the emitter of this message
• On the server, the "majordomo" agent creates the workspace and the artifact, and leaves a message

"majordomo" agent code:

!setup_and_monitor.

+!setup_and_monitor
        <-      createWorkspace("server");
                joinWorkspace("server",Id);
                !setupArtifacts.
                
+!setupArtifacts
        <- makeArtifact("env","easss.step.EnvBasic",[]);
           printMsg("ready. Your turn!").

In this step:

• The artifact "env" has been enriched with an observable property numMsg showing the number of messages left so far.
• A couple of guest agents repeatedly place messages on env
• An observer agent has been added, observing the env artifact and reacting to changes related to the numMsg observable property

In this step:

• The artifact "env" has been enriched with a "computePi" action (with output parameters "OpFeedbackParams")
• We still have the observer and guest agents of the previous step. You can reuse the "observer" agent that you adapted in the previous exercise

In this step,

• The "env" artifact has been enriched to install mutual exclusion in the actions for leaving messages. It has a private attribute "locked" and two operations "lock" and "unlock" insuring the mutual exclusion.
• The agent that you will develop for this step in the client part, will use these actions to access in an exclusive way to the artifact and print the messages in sequence.
• The "observer" agent as in the previous steps, joins the workspace, lookups for the artifact "env", focuses on the artifact "env" and gets the value of the "numMsg" observable property.

In this step:

• The "env" artifact has been enriched with a synchronisation operation "sync" and with the possibility to setup a number of participants for the synchronization "setupBarrier" or via initialisation.
• The "majordomo" agent has been enriched to setup the barrier in the "env" artifact.

majordomo agent code:

!setup_and_monitor.

+!setup_and_monitor
        <-      createWorkspace("server");
                joinWorkspace("server",Id);
                !setupArtifacts;
//        setupBarrier(3).
                
+!setupArtifacts
        <- makeArtifact("env","easss.step5.Env",[3]);
           printMsg("ready. Your turn!"). 

• With the previous implementation, we had a monolithic "env" artifact. It could cause some problems, for instance, if adding a long-term action such as computePi. Why?
• A better way could be to decompose the "env" in multiple artifacts (types and instances). Let's do a little bit of refactoring in this step.
• Thus, for this step, the artifact "env" has been refactored and decomposed into "msg_console", "calculator", "lock", "barrier"
• The majordomo agent has been changed to create instances of these artifacts in the workspace.
• The observer agent has been changed to focus on the proper artifact.

In this step, you are going to create your own artifacts building a simple counting world example. In this world, counter agents and observer agents are situated in the default workspace and use counting artifacts.

• The "Counter" artifact is a simple artifact composed of a "count" observable property initialized to 0 when the artifact is created. The artifact has a single operation "inc" without any parameters. This operation increments "count" and sends a "tick" signal every time it is executed by an agent.
• The "observer" agent:
  • sends a message to the "ticker" agent and starts focusing on this artifact, as soon as it receives a message telling it the name of the counter artifact that has been created "artifact_counter_is(Name)".
  • stops focusing on the artifact as soon as the observable property "count" is equal to 6.
  • prints a message "observed new value" with the value, each time the observable property is changed.
  • prints a message "perceived a tick in" with the name of the artifact in which a tick has been done.

// Agent observer code
/* Initial beliefs and rules */

/* Initial goals */
!observe.

/* Plans */ 

+!observe : true 
<-      println("Observer starting to work");
        lookupArtifact("counter",Count);
        +myTool(Count); 
        focus(Count).
...

• The "ticker" agent:
  • creates the "counter" artifact of type Counter and tells to all the agents that are in the MAS the name of this artifact ("tell", "artifact_counter_is(counter)"),
  • starts to use this artifact to increment the value of the counter as soon as it receives an answer of an agent
  • Being a lazy agent, it rests for a while (let's say 100 ticks), after each increment. It does this job for 100 cycles. Every time, it increments the artifact and prints a message.

// Agent ticker code
/* Initial beliefs and rules */

/* Initial goals */
!setup.

/* Plans */

+!setup : true <- 
        !setupCounter(Id);
        +counter(Id);
        !increment.

+!increment : ready[source(Ag)] & counter(Id) <-
        for (.range(I,1,100)) {
                .wait(100);
                inc[artifact_id(Id)];
                .print("incrementing");
                }.
        
+!increment : not ready[source(Ag)] <-
        !increment.
        
+!setupCounter(C) : true <-
        makeArtifact("counter","easss.step7.Counter",[],C);
        .broadcast(tell,artifact_counter_is(counter)).

In this step, we are going to extend the previous simple counting world example.

• Keeping the same agents, the "Counter" artifact will be transformed into a "bounded" counter artifact, i.e. its observable property "count" cannot be higher than a maximum value fixed at the initialisation of the artifact.
• The artifact generates a failure signal when its action "inc" is no more possible.

• We strongly invite you to have a look at the set of exercises that are provided in the cartago distribution: here

Coming soon …

• This last exercise is dedicated to the development of a MAS where agents use an artifact to execute an auction protocol to allocate a set of tasks between them. You can get here the specification of the global application.
• The contractor agent, "giacomo" creates an artifact of this type for each of the tasks it needs to allocate the tasks to "company" agents: e.g. one auction artifact for building the walls, another one for setting the floors, …
• The "company" agents observe the artifacts that propose a task compatible with goals and skills. They use these artifacts for bidding according to their own strategies.