Building a Web-bridge for JADE agents

Building a Web-bridge for JADE agents
Florin Stoica

Abstract — This paper presents the architectural design of
a bridge between agent-oriented applications and web-based
frontends. For this purpose the state-of-the-art JavaServer
Faces (JSF) technology is connected with the JADE platform.
The front-end is based on standard JSF components and the
application tier is based on JADE agents. A simple web
application scenario is implemented, to describe the technical
challenges in developing such a system.
Keywords — agents, JavaServer Faces, JADE.
I. INTRODUCTION
HE work presented in this paper was motivated by the
recognition that JADE, as one of the most widely
deployed open source agent systems, should have the
capability of exposing agent services for consumption by
Web clients. For this purpose, is provided a general
method of how can be linked a JADE agent to a
JavaServer Faces (JSF) component, to allow Web
Applications to be interfaced with a Multi-Agent System.
The testing example is inspired by the JADEServlet add-on
developed by Fabien Gandon [1].
A. Jade agents
JADE is a middleware that facilitates the development
of multi-agent systems and applications conforming to
FIPA standards for intelligent agents. It includes:
· A runtime environment where JADE agents can “live”
and that must be active on a given host before one or
more agents can be executed on that host.
· A library of classes that programmers have to/can use
(directly or by specializing them) to develop their
agents.
· A suite of graphical tools that allows administrating
and monitoring the activity of running agents.
The Agent class represents a common base class for
user defined agents. Therefore, from the programmer’s
point of view, a JADE agent is simply an instance of a user
defined Java class that extends the base Agent class, as
shown in the code below:
import jade.core.Agent;
public class MyAgent extends Agent {
protected void setup() {
// Printout a welcome message
System.out.println("Hello!"+
"The agent " + getAID().getName()+
" is ready!");
}}
Florin Stoica is with the Faculty of Sciences, “Lucian Blaga”
University of Sibiu, Romania (phone: 40/269/216062; e-mail:
florin.stoica@ulbsibiu.ro).
The computational model of an agent is multitask, where
tasks (or behaviours) are executed concurrently. Each
functionality/service provided by an agent should be
implemented as one or more behaviours. A scheduler,
internal to the base Agent class and hidden to the
programmer, automatically manages the scheduling of
behaviours.
A behaviour represents a task that an agent can carry out
and is implemented as an object of a class that extends
jade.core.behaviours.Behaviour. In order to make
an agent execute the task implemented by a behaviour
object it is sufficient to add the behaviour to the agent by
means of the addBehaviour() method of the Agent
class.
Each class extending Behaviour must implement the
action() method, that actually defines the operations to
be performed when the behaviour is in execution and the
done() method (returns a boolean value), that specifies
whether or not a behaviour has completed and have to be
removed from the pool of behaviours an agent is carrying
out. Is important to notice that scheduling of behaviours in
an agent is not pre-emptive (as for Java threads) but
cooperative. This means that when a behaviour is
scheduled for execution its action() method is called
and runs until it returns.
The path of execution of the agent thread is showed in
the following pseudocode:
void AgentLifeCycle() {
setup();
while (true) {
if (was called doDelete()) {
takeDown();
return;
}
Behaviour b =
getNextActiveBehaviourFromSchedQueue();
b. action();
if (b.done() returns true)
removeBehaviourFromSchedQueue(b);
}
}
We can distinguish among three types of behaviour [2]:
(a). “One-shot” behaviours that complete immediately
and whose action() method is executed only once.
The jade.core.behaviours.OneShotBehaviour
already implements the done() method by returning true
and can be conveniently extended to implement one-shot
behaviours.
public class MyOneShotBehaviour extends
OneShotBehaviour {
public void action() {
// perform operation X
}
}
T

Operation X is performed only once.
(b). “Cyclic” behaviours that never complete and whose
action() method executes the same operations each time
it is called.
The jade.core.behaviours.CyclicBehaviour
already implements the done() method by returning false
and can be conveniently extended to implement cyclic
behaviours.
public class MyCyclicBehaviour extends
CyclicBehaviour {
// perform operation Y
}
}
Operation Y is performed repetitively forever (until the
agent carrying out the above behaviour terminates).
(c). Generic behaviours that embeds a status and execute
different operations depending on that status. They
complete when a given condition is met.
JADE provides the possibility of combining simple
behaviours together to create complex behaviours.
B. Java Server Faces Technology
JavaServer Faces (JSF) is a new technology for rapidly
building Web applications using Java technologies, with
objective to create a standard framework for user interface
components for web applications. JSF expedites the
development process by providing the following features:
standard and extensible user interface (UI) components (a
rich component model with event handling and component
rendering), easily configurable page navigation,
components for input validation, automatic bean
management, event-handling, easy error handling,
embedded support for internationalization, and web
application lifecycle management through a controller
servlet.
JavaServer Faces (JSF) is a technology that is being led
by Sun Microsystems as JSR 127 under the Java
Community Process (JCP).
JavaServer Faces technology includes:
· A set of APIs for representing UI components and
managing their state, handling events and input
validation, defining page navigation, and supporting
internationalization and accessibility.
· A JavaServer Pages (JSP) custom tag library for
expressing a JavaServer Faces interface within a JSP
page.
A JSF application is just like any other Java technology-based
web application; it runs in a Java servlet container,
and contains:
· JSP pages with JSF components representing the UI.
· JavaBeans to hold the model data.
· Application configuration files specifying the JSF
controller servlet, managed beans, and navigation
handles.
JavaServer Faces technology is based on the Model
View Controller (MVC) architecture for separating logic
from presentation. This design enables each member of a
web application development team to focus on his or her
piece of the development process, and it also provides a
simple programming model to link the pieces together.
The example application was developed in Sun Java
Studio Creator 2, an Integrated Development Environment
(IDE) for developing state-of-the-art web applications.
Based on JSF technology, this IDE simplifies writing Java
code by providing well-defined event handlers for
incorporating business logic, without requiring developers
to manage details of transactions, persistence, and other
complexities. In addition, it supports the web applications
architecture as defined in the J2EE BluePrints [3].
Web applications in the Java Studio Creator
development environment are supported by a set of
JavaBean components, called managed beans, which
provide the logic for initializing and controlling JSF
components and for managing data across page requests (a
single round trip between the client and server), user
sessions, or the application as a whole.
II. A JSF-JADE BRIDGE
The following JSF application is deployed in Tomcat
and is interfaced with a proxy-agent in JADE in order to
retrieve and display the list of the agents advertising a
service with the Directory Facilitator (DF) as defined in
FIPA [4]. We suppose that before running the Tomcat
server, a default JADE platform has been started on the
same host, port 1099, with a main container.
The main page of application, Page1.jsp, contains a
table component used to display all registered agents
within JADE platform advertising a service specified by
the user.
Each user’s request is linked to a behavior of the Proxy
Agent in charge of handling the request; each instance of
the behavior connect to the DF, retrieves the list of
advertised agents, and update the UI through a data
provider. This architecture allow the handling of multiple
requests in parallel (requests are resolved by a multi-behavior
Proxy Agent) and further customization of the
behaviors to handle different types of requests in different
ways. The architecture of the application is showed in Fig.
1.
JADE platform
request
Figure 1. Architecture of the example.
Page1.jsp
JSF Table component
ObjectArrayDataProvider
SessionBean1
theProxyAgent (controller)
AgentInfo [ ]
ProxyAgent
Directory Facilitator (DF)

Business Objects
The following are the business objects used in the
application:
A. AgentInfo
Encapsulates an agent ID retrieved from the Directory
Facilitator (DF) agent, consisting from its name and its
address.
public class AgentInfo {
public String name;
public String address;
//...
}
B. CondVar
Simple class behaving as a Condition Variable, used in
synchronization.
public class CondVar {
/** Constructor */
public CondVar() {
}
private boolean value = false;
synchronized void waitOn() throws
InterruptedException {
while(!value) {
wait();
}
}
synchronized void signal() {
value = true;
notifyAll();
}
synchronized void reset() {
value = false;
}
}
C. HelloJADE
Create a new non-main JADE container, then create a
new instance of Proxy Agent in the StartProxyAgent
method:
synchronized public AgentController
StartProxyAgent() {
// Create a new non-main container
try {
sync.reset();
Runtime myJADERunTime =
Runtime.instance();
Profile myJADEProfile = new
ProfileImpl();
AgentContainer myNewContainer =
myJADERunTime.createAgentContainer(
myJADEProfile);
// The sync Object is used to achieve
// a startup synchronization
theProxyAgent =
myNewContainer.createNewAgent(
"ProxyAgent",
ProxyAgent.class.getName(),
new Object[] { sync });
theProxyAgent.start();
// Wait for synchronization signal
sync.waitOn();
}
catch(Exception ex) {
ex.printStackTrace();
}
return theProxyAgent;
}
The StartProxyAgent method return an
AgentController used to communicate with Proxy
Agent.
D. ProxyAgent
Represent the bridge between Web application and
JADE platform. Has a CyclicBehaviour, activated at
each user request by launching a new
OneShotBehaviour to resolve that request. This agent
declares it accepts messages through the object to agent
communication channel and dynamically creates behaviors
(GetDFList) to handle each request that is received:
public class ProxyAgent extends Agent {
private CondVar sync;
/** Constructor */
public ProxyAgent() {
}
public void setup() {
// Accept objects through the object-
// to-agent communication channel,
// with a maximum size of 100 queued
// objects
this.setEnabledO2ACommunication(true,
100);
// Register the Proxy Agent with the
// DF so that there is at least one
// registered agent
....
// Notify the HelloJADE that the
// Proxy Agent is ready
Object[] recvArgs = getArguments();
sync = (CondVar)(recvArgs[0]);
sync.signal();
// Add a cyclic behaviour checking
// the queue of objects
this.addBehaviour(new
CyclicBehaviour() {
Object recvObj = getO2AObject();
if(recvObj != null) {
myAgent.addBehaviour(new
GetDFList(myAgent,
(SessionBean1)recvObj,sync));
}
else block();
}
});
}
}
The GetDFList retrieve the list of all registered agents
advertising a service specified by the user. Then, update
the property agents of SessionBean1 with results, and
finally notify the Page1 bean the response is ready:
class GetDFList extends OneShotBehaviour{
private AgentInfo[] agents;
private CondVar sync;
private SessionBean1 session;
// Constructor
public GetDFList(Agent agent,
SessionBean1 session,
CondVar sync) {
super(agent);
this.session = session;
this.sync = sync;
}
try {

DFAgentDescription template = new
DFAgentDescription();
ServiceDescription sd = new
ServiceDescription();
// retrieve the service from user
if (session.getService().equals("all"))
sd.setType(null);
else
sd.setType(session.getService());
template.addServices(sd);
DFAgentDescription[] result =
DFService.search(myAgent, template);
if (result.length > 0) {
String agentID;
int p1, p2;
agents = (AgentInfo [])
Array.newInstance(AgentInfo.class,
result.length);
for(int count=0;count<result.length;
count++) {
agentID =
result[count].getName().toString();
p1 =agentID.indexOf(":name");
p2 =agentID.indexOf(":addresses") ;
Array.set(agents, count,
new AgentInfo(
agentID.substring(p1+5, p2-1),
agentID.substring(p2+11,
agentID.length()-1)));
}
}
else {
agents = (AgentInfo [])
Array.newInstance(AgentInfo.class,
1);
Array.set(agents, 0,
new AgentInfo("not found",
"not found"));
}
session.setAgents(agents);
sync.signal();
}
catch(Exception ex)
{ex.printStackTrace(); }
}
}
In the following is explained the code of the standard
managed beans. The method init() of the
SessionBean1 contains the code for creating a new non-main
JADE container and launching the Proxy Agent:
sync = new CondVar();
if (theProxyAgent == null)
theProxyAgent = new
HelloJADE(sync).StartProxyAgent();
The sync object is passed to Proxy Agent and used at
startup for waiting the complete initialization of the Proxy
Agent and later for synchronization between user requests
and associated Proxy Agent tasks.
An user request is performed through selection of button
labeled Find (with id button1):
public String button1_action() {
try {
AgentController t =
getSessionBean1().getTheProxyAgent();
CondVar sync =
getSessionBean1().getSync();
sync.reset();
t.putO2AObject(getSessionBean1(),
AgentController.ASYNC);
sync.waitOn();
AgentInfo [] agents =
getSessionBean1().getAgents();
// refresh table component
getObjectArrayDataProvider1().setArray(
agents);
}
catch(Exception ex) {
ex.printStackTrace();
}
return null;
}
The objectArrayDataProvider1 wraps the
JavaBean component AgentInfo[] agents (property of
SessionBean1) through its array property, which we can
set in the Creator Properties window. In Fig. 2 is showed
the running example discovering all “live” registered
agents in the JADE platform depicted in Fig. 3.
Figure 2. A JSF table component linked to a JADE agent
III. CONCLUSION
Data providers can be used to access the JavaBean
components both in the Java page bean code and in the
property binding dialogs of the Java Studio Creator IDE.
The Web-bridge for JADE agents is based on data
providers wrapping JavaBeans components which are
updatable by JADE agents through the object to agent
communication channel between agent controllers and
JADE agents. Binding data provideres to JSF components,
these are linked in fact to JADE agents.
REFERENCES
[1] Fabien Gandon, “Linking a servlet to a JADE agent”, JADE add-on,
http://jade.tilab.com
[2] F. Bellifemine, G. Caire, T. Trucco, G. Rimassa, JADE
programmer's guide, http://jade.tilab.com
[3] Java Studio Creator Field Guide, 2nd ed., Sun Microsystems
(currently in development),
http://developers.sun.com/prodtech/javatools/jscreator/learning/
bookshelf/index.html
[4] The Foundation for Intelligent Physical Agents (FIPA),
www.fipa.org
[5] D. Geary, C. Horstmann, Core JavaServer Faces, Prentice Hall,
2004, ch. 1-5.

Figure 3. A snapshot of the JADE platform with three registered agents

Building a Web-bridge for JADE agents

Recommended

More Related Content

What's hot (20)

Viewers also liked (18)

Similar to Building a Web-bridge for JADE agents (20)

More from infopapers (11)

Recently uploaded (20)

Building a Web-bridge for JADE agents