In this paper we propose a general framework for web-enabling economic and financial simulations. Especially suited for agent-based models, the system is fully built upon Open Source software and well-known standards which ensure a very high level of generality. For the sake of completeness, two tools are used to make an instance of this framework: JAS Library as a simulation tool and Zope for web interface and users management. Both communicate through XML-RPC. In conclusion, this system is used to simulate the Prisoner's Dilemma problem.

Keywords:

Simulation tools, Economic and financial simulation, Open source

Introduction

1.1

Economic and financial simulations generally require writing specific software in order to deal with the multi-agent paradigm and its complexity which characterises recent trends in this field of research (Beltratti et al. 1996). Different software tools, especially in the form of libraries, have been developed to help the researcher to code the description of the models and their dynamic behaviour without starting every time from scratch. As an example, Swarm (http://www.swarm.org) is a set of libraries and functions, formerly written in Objective-C and successively ported in Java, which was developed by the Santa Fe Institute for modelling agent-based economic and social simulations. Different applications have been developed, ranging from economic models to simulation of banking systems or ecosystems and diffusion models.

1.2

One of the more common limitations of these tools is the user interface which is typically limited to local and single-user interaction. Conversely, recent trends in economic research require multi-user and Internet-oriented interaction.

1.3

In this work, we propose a general approach for web-enabling economic and financial simulations and present Sim2Web, a general framework of interest not only for traditional simulations but for experimental economics and generally for agent-based modelling. Realisations are only subject to the constraint for building blocks and tools to be compliant with well-known communication standards.

1.4

In these areas of research, web-enabling simulations produce many advantages for both the researcher and the user, like remote control of simulations, broadcast of simulation output, distributed interaction with the simulation over a network (LAN, WAN or the Internet).

1.5

For a better presentation, we chose to apply this framework to specific tools and link together JAS Library, an agent-based simulation tool, and Zope, an object-oriented content management system for delivering a full-blown web-based system. Communications occur via XML-RPC. The web site of Sim2Web is at http://wf.econ.unito.it/sim2web, where full code can be downloaded and the Heatbugs example is shown as a running simulation. This system is eventually tailored to build an application which simulates the Prisoner's Dilemma problem.

1.6

The structure of this paper is as follows: section 3 presents the structure of Sim2Web, section 4 the standards we use in the application are discussed. In sections 5 and 6, we focus on JAS and the JAS layer while sections 7 and 8 present the Zope framework and the Zope layer. In section 9 we present an application to the Prisoner's Dilemma problem we build as an example of Sim2Web use. Finally, section 9 concludes and describes future directions of research.

The Advantages of Sim2Web

2.1

Kuljis et al. (2001) highlights the importance of the web infrastructure for the simulation environments. Most of the emerging tools designed to create parallel, distributed simulation models are going in the direction of using the network as the main infrastructure for simulations. This is due to the power representation of the asynchronous events and the speeding up of the computation given by the parallel computing.

2.2

Unfortunately, the networking software interfaces, like CORBA, SOAP or RMI, require not only a good skill in programming, but a good knowledge of the interface definition languages (IDL) and, in general, of the network programming.

2.3

As shown in Shen (2000), the aim of increasing the portability of existing simulation software leads to using well-defined protocols and architectures. This approach goes into the frontier programming thoroughly. The social scientists are not encouraged to use hard programming techniques to implement their simulation models.

2.4

As the Swarm experience shows, it is necessary to define a protocol and reduce the programming technicalities, hiding them inside the tool facilities. The Sim2Web architecture goes in the direction of reducing the modifications to the existent simulation code and enabling web interactions in simulation models with little effort. Thanks to the XML-RPC light protocol no new programming languages are required to show an AB model on the web.

2.5

Nevertheless, the Sim2Web architecture is very suitable for the simulation typical in experimental economics, where artificial simulation models are played by humans.

2.6

Mainly in the field of social science, it is very useful to integrate simulation tools with specifically designed platforms that allow to open the simulated world to the remote controls of human agents. These are the reasons which drive Sim2Web to be a suitable platform for social scientists to web-control agent-based models.

The Structure of Sim2Web

3.1

Sim2Web is a three-tier application (Figure 1):

• the presentation tier provides user authentication and defines the web-based graphical user interface (GUI)
• the communication tier is in charge of establishing and managing (local or remote) communication between simulation and web interface
• the simulation tier runs the simulation, generates data to be made available to the users (text and graphics) and receives data (text, decisions and actions) from the users.

3.2

The simulation tier is entirely managed by JAS Library. The presentation tier is totally under the control of Zope while the communication tier is controlled by both. The users interact only with Zope which in turn communicates with JAS Library.

3.3

After installing both JAS Library and Zope (on the same or on two different servers), and installing in Zope the xmlrpclib library (http://www.xmlrpc.com), one must perform some steps for setting-up the simulation:

• define the model to simulate
• write the code for the simulation (JAS)
• define the interactions (data to generate, send and receive)
• code data generation and communication functions (JAS)
• define the GUI
• code the web-based GUI (Zope)
• define users and authentication policies
• create users and code authentication policies (Zope).

Figure 1. The three-tier structure of Sim2Web.

3.4

In order to make Sim2Web as general and platform-independent as possible, we used only Open Source tools and widely recognised and adopted standards.

The Standards

4.1

The architecture of Sim2Web is based on the collaboration of heterogeneous applications. They not only play different roles, but are also based on different programming languages. In order to uncouple the specific implementation of each single tier from the others we have chosen a language-independent communication protocol: XML-RPC.

4.2

The communication tier, based on XML-RPC, represents a universal bridge between the simulation model and the web server. In this way, within the general framework proposed by Sim2Web, applications can be implemented with different simulation tools and with any web server, with the only constraint for them to be XML-RPC compliant.

4.3

The implementation we propose here is based on Zope (Z Object Publishing Environment), the most widely used Open Source Content Management System, with Python external interface, and on JAS Library.

4.4

The different standards we use for building the system are:

• Java and Python, as programming languages
• XML-RPC, as communication protocol
• SVG, as a graphic format.

Java

4.5

Java (http://java.sun.com) is the standard programming language for JAS Library. It has been chosen because it is considered the most suitable technology for Open Source projects. Its independence from the operating system, its easiness in admitting third-party libraries into the code and the availability of many free libraries which cover many areas of interest, are the reasons why the Java Open Source community grows day by day.

4.6

In particular, many Java implementations of the XML-RPC protocol and of the SVG standard format (two of the technologies we used for developing Sim2Web) are available.

Python

4.7

Python (http://www.python.org) is an interpreted, easy to learn and elegant programming language, created and developed by Guido Von Rossum. Nearly all the Zope code is written in Python and therefore this language is the native Zope extension tool. It can be used to extend Zope and to write complex web applications within Zope. We used it to build the main components of the presentation layer of Sim2Web and exploited one of its XML-RPC libraries.

XML-RPC

4.8

XML-RPC (eXtensible Markup Language - Remote Procedure Call) (see http://www.xmlrpc.comand http://xml.apache.org/xmlrpcfor the Java implementation) is a remote procedure call protocol using HTTP for the transport and XML for the encoding. That means it could be used by any application to invoke methods of another remote process via a web channel, both running on different system architectures (a example may be a Win32 client asking the sum of two numbers to a routine running on a remote Linux machine) (St. Laurent et al. 2001).

4.9

The communication protocol represents the core of Sim2Web. It is the "glue" connecting each part of the assembly. Accordingly, when comparing the available technologies we considered some key issues like the language compatibility (at least with Python and Java), the simplicity in implementation, and a scant invasive implementation strategy.

4.10

It is worth noting that Sim2Web is a low-level architecture with the aim to web-enable an existing simulation model, while allowing the programmer to concentrate on the economic or financial application rather than dealing with system set-up problems. Moreover, we designed the Sim2Web architecture in such a way as to require as few changes as possible to the original simulation code.

4.11

For managing communicating among heterogeneous architectures, we have found XML-RPC to be the protocol of choice among the available RPC technologies like CORBA, SOAP and RMI, thanks to its lightness and easiness of use.

4.12

We can point out the following advantages of XML-RPC, with respects to other tools:

• RMI is strictly Java-based: no other languages can take advantage of it.
• both RMI and CORBA require an explicit declaration of exported class interfaces through a specific language called IDL (Interface Definition Language). Moreover, each IDL definition must be compiled using a special IDL compiler. XML-RPC is able to export an object interface with just a couple of instructions.
• with XML-RPC or SOAP it is possible to open a socket on a host port, send a string, close the connection, and everything is done.
• contrary of the popular belief, SOAP has not been ratified by the W3C, whereas XML-RPC has been around for a while and, even if it isn't maintained by a standard committee, it is stable and open to community inputs.
• CORBA's solution is rather complex and requires a good bit of explanation beyond the source code. XML-RPC just uses URLs. This comes back to the "flexibility and simplicity" reason for choice.

4.13

In spite of these advantages XML-RPC has some limitations:

• The XML data format adds overhead compared to CORBA's binary format.
• XML-RPC cannot export complex data structures, because it calls methods via its methodName property which may only contain characters. For most purposes this is adequate, but introduces additional difficulties when one needs to pass an object as an argument.

4.14

When one gets right down to it, XML-RPC is really simple and easy to understand. Its requests and responses are intuitive and can be coded without fuss. It is a lowest common denominator form of communication allowing to get almost any job done with a minimum amount of complexity.

4.15

SOAP, on the other hand, is designed for transferring far more complex sets of information. It requires profuse attribute specification tags, namespaces, and other complexities in order to describe exactly what is being sent. Asking to the researcher to learn the CORBA or the SOAP protocol is surely not a friendly way to write down a web-enabled simulation.

4.16

Thanks to the extreme ease in XML-RPC implementation, we finished by completely hiding the communication tier from the final user.

SVG

4.17

The worst limit of the XML-RPC is that it cannot manage objects with a complex data structure. So we had to face the problem of sending to the web page graphical widgets generated by the simulation.

4.18

The SVG standard (W3C 2001) and the Apache Batik library (http://xml.apache.org/batik) came to our help. In fact, SVG allows vector graphics, animations and simple bitmaps to be described, using the XML format.

4.19

It is becoming the standard graphic format (Eisenberg 2002; Cagle et al 2002; Trippe et al 2002; Pearlman et al 2002), just like the PDF is for the documents, so different specific plug-ins exist for the most common web browsers, which can execute SVG instructions and draw graphics within HTML documents (http://www.adobe.com/svg).

4.20

The Apache Batik library is one of the SVG implementations for Java and it is able to create a rendering graphic context with the same interface for the common graphic context used by Java Swing (the GUI libraries of Java) to draw a window.

4.21

By simply using the graphic context created by Batik, just the same instructions that before were drawing on the screen are now able to draw on an SVG document. After the window has been drawn on an SVG graphic context, it is possible to send it via XML-RPC because it now consists of a simple string. This technique is very powerful because one can export a graphic frame almost without any change in the original code of the model.

JAS

5.1

JAS (Java Agent-based Simulation library) is an Open Source project, hosted by the SourceForge (http://sourceforge.net and http://jaslibrary.sourceforge.net) directory. It consists of a collection of Java classes useful to create simulation models, according to the agent-based modelling (ABM) paradigm.

5.2

Unfortunately, the simulation of social systems is an algorithm-intensive task. In fact, an agent-based model is often made of a population of agents, whose behaviour is driven by complex (sometimes adaptive) rules. In other words, simulating "intelligent" social systems entails producing applications with onerous decision routines. This is the reason why the ABM tools are nearly all represented by code libraries and not just by visual development tools.

5.3

The choice of JAS, as a platform for the Sim2Web simulation tier, was made because one of the authors is involved in its development. This represents a good way to make Sim2Web part of the standard equipment of JAS and a fully working version of the simulation-to-web application will be deployed in its next release.

5.4

The JAS class collection contains:

• a core module (jas.engine) implementing a flexible discrete event simulation engine, particularly optimized to manage repetitive groups of actions (typical in agent-based modelling) and designed to run both in simulated and real-time mode. The real-time execution mode in particular makes JAS also an emulation tool which can be used to test physical systems (playing the role of a virtual user of the system), to coordinate network experiments and interaction with human agents;
• a Java dynamic class-loader, to avoid the boring library path declaration necessary to start a simulation. Through this service the user is in a condition to load and execute models directly from a visual control panel, as if they were simple documents;
• a multi-run class automating the parameter calibration. It creates a loop that loads a model, sets its parameters, runs it for a while, changing the initial values each time on the basis of the results obtained from the previous run;
• an I/O library (jas.io) to perform visual data input from the user and file I/O operations, with a full support for the XML format. It is also able to manage the Microsoft Excel format, thanks to the jExcelApi library by Andy Khan (http://www.andykhan.com);
• a plotting library (jas.plot) mostly based on the widely adopted Ptolemy PtPlot library (http://ptolemy.eecs.berkeley.edu/java/ptplot/index.htm), with many format image exporting functions (JPG, GIF, BMP, SVG);
• many statistical (jas.stats) and random generation (jas.random) functions, based on the efficient routines from the COLT library, developed at CERN (http://nicewww.cern.ch/~hoschek/colt/index.htm);
• a grid space representation library (jas.space) allowing the user to manage agents' positions and their graphical representation in a easy way.

5.5

Soon JAS will be equipped with a native AI library (jas.ai) with Genetic Algorithms, Neural Networks and Classifier Systems to design agents endowed with adaptive decision capabilities.

The JAS Layer

6.1

In the Sim2Web model, the JAS layer is in charge of the simulation tier and part of the communication tier.

6.2

In order to realise the simulation tier we had to design two Java classes:

• a communication class (InformationServer),
• a graphic exporting tool (SVGGenerator).

6.3

JAS has been equipped with the jas.net.InformationServer class, which is a textual repository, able to speak with any XML-RPC interface. It contains a list of string data, indexed by a specific key (user id and information id). Any external object speaking the XML-RPC language could ask information of it and in the same way it might send orders back to the simulation model.

6.4

Any data published by the running model could be accessed using the right key. So when a remote user opens the web page, Zope asks the InformationServer for the strings corresponding to the id values it finds in the HTML source coupled with the current user id and then dynamically creates the page with the retrieved data.

6.5

Obviously if no data are loaded, the answer will be empty. This suggests that the modeller has to plan the consistency of data, scheduling a periodic update of the simulation status.

6.6

While building the simulation layer, it was important to create an asynchronous software interface, because the simulation might run both with and without external interactions.

6.7

This means that the communication between remote user and running model is asynchronous; in fact no warnings are sent to the former when information is updated (the web page must be periodically refreshed) and decisions or actions sent by the user are processed only at scheduled times (if two orders arrive before the simulator process them, only the last will be considered).

6.8

The code in Listing 1 shows the first part of the InformationServer class. It is based on the org.apache.xmlrpc.WebSever class (listings are in the Appendix).

6.9

The constructor creates an instance of the WebServer class specifying the tcpPort and publishes (with the addHandler method) on this port the whole interface of the InformationServer class. That opens a communication channel on a specific TCP/IP port and accepts queries for data and orders sent to the simulator. Every XML-RPC client on the network would be able to invoke one of its public methods using the specified TCP port.

6.10

The HashMap variables called infos and receivedInfos respectively contain a list of published information and received orders. Each string data is mapped to unique keys. This technique allows an easy implementation of the information repository. When a specific information is asked of the server, it retrieves the String value using its relative key.

6.11

The method getInfo (Listing 2.) searches in the infos list for the string coupled with the key. Each key is made with the userId name and the information id.

6.12

Data are updated through the addInfo method (Listing 3).

6.13

The second important class is relative to the SVG drawing context implementation. The code is wholly contained into the jas.io.SVGGenerator class.

6.14

Through this object it is possible to export surfaces populated by agents, variable plots and any other graphical widget the modeller decides to put into the model.

6.15

The way to transmit graphical data through a textual protocol is to translate them into a string representation. The Batik library by Apache is a converting tool that translates commands sent to a standard graphic context in a SVG (XML) stream.

6.16

The code presented in Listing 4 is the implementation of the JAS generator based on the Batik library.

6.17

The getSVG method generates a brand new XML document, according to the SVG specifications. It is called before the beginning of the rendering process.

6.18

The getOutput method flushes the current content of the SVG graphic context into a text stream, in order to finalise the rendering task.

6.19

The key method is called generateAsPicture. Invoking it from the simulation and passing it a panel object (the content of a Java window) as parameter, will return an SVG version of the current content of the panel.

6.20

It consists of four steps:

• first, it creates an SVG empty document, using the getSVG method;
• second, it sets the size of the graphic context to the size of the panel;
• third, it asks the panel to repaint itself on the new SVG graphic context;
• then it finalises the operation with the getOutput method and returns the SVG-XML document containing the panel content.

6.21

Trying to summarise the steps to enable the model to communicate with external users, it is necessary to:

• create an instance of the InformationServer class into the model code
• plan the time schedule for data updates and graphic refreshing. In this way, remote users can always receive the correct information
• plan the time schedule to process pending orders that might have been received from remote users.

Zope

7.1

Zope (Z Object Publishing Environment) (Latteier 2002; Beehive 2001) from Zope Corporation (http://www.zope.org) is an Open Source Content Management System (CMS) and a Web Application Server (WAS). Web applications, that is programs that can be accessed with a browser over the Internet, are nowadays widely used and the World Wide Web, formerly a repository of static pages, is becoming a provider of services and dynamic contents. In this work, we mainly use the WAS functionality of Zope.

7.2

Many characteristics make Zope different from other CMS, either commercial or Open Source. Zope:

• is fully object oriented.
• contains an object-oriented database and a web server. The whole site is contained in this database and can be served by the internal web server or through Apache or another web server.
• is transaction-oriented and allows a high level of data integrity and different levels of undo.
• has a web-based management interface. All the operations can be done over the Internet with a browser.
• can connect to external relational databases, including Oracle, PostgreSQL, MySQL.
• supports open standards like HTTP, FTP, WEB-DAV, SQL, ODBC, XML, XML-RPC, LDAP and more.
• incorporates a very sophisticated security system, based on users, roles and permissions, which allows safe delegation of the site updating operations to the various actors involved in the maintenance operations (web designers, content managers, ...)
• has a powerful scripting language, DTML (Dynamic Template Markup Language). This tag-based language allows the generation of pages from dynamic content.
• is Open Source software, and is mostly written in an Open Source language, Python, which can be used to extend Zope and to write more complex applications than those it is possible to obtain by using only DTML.
• provides scalability through the ZEO (Zope Enterprise Objects) functionality, which implements load balancing across servers.
• has a built-in search engine for full-text indexing and searching.
• is extensible, with more than 300 existing products, which complete the Zope core with high level functionality (forum, mail systems, form builders, database interfaces, ...).
• has a very active community of users and developers.

The Zope layer

8.1

While JAS represents the Sim-side of Sim2Web, Zope is the Web-side (including user authentication, if necessary) and manages part of the communication tier.

8.2

The Zope layer itself is based on a three-component architecture:

• a web page (in the form of a standard Zope object called DTML Method), for exposing the web GUI
• some Zope objects (External Methods), for interfacing function calls present in the web page and the corresponding Python functions
• some Python functions which perform XML-RPC communication for interacting with the simulation.

8.3

Authentication management, finally, requires:

• creating the users' directories
• defining users and granting them permission to access the web page.

The web page

8.4

For the sake of simplicity, we use a HTML table to display information in the web page. Each cell (or data in the cell) has a unique identifier named id01, id02, ... In each cell of the table, we insert:

• a text string which describes the content of the cell
• one or more function calls and some HTML codes, depending on the type of data to display or input.

8.5

Different types of data are implemented. The simulation can produce and send to the user:

• text
• graphics.

8.6

To display text in the page, the cell must contain the code of Listing 5, where:

• Title describes the content of the cell
• id01 is the identifier of the data
• zAsk is the function call which asks the simulation to send the data
• zDisplayText is the function which displays the text received from the simulation.

8.7

To display a picture in the page, the cell must contain the code in Listing 6, where:

• Title, id02and zAsk have the same meanings described above
• zDisplaySVG is the function which displays the SVG graphics received from the simulation.

8.8

The simulation can receive from the user actions encoded as:

• text
• radio button value
• selection value
• method activation request.

8.9

To allow the user to send text, the cell must contain the code in Listing 7, where:

• Title and id03 have the meanings already described
• default is the default string which appears in the text box.

8.10

To allow the user to use a radio button, the cell must contain the code in Listing 8, where:

• Title and id04 have the meanings already described
• FirstValue, SecondValue, ..., LastValue are the displayed strings corresponding to the radio buttons
• one, two, three are the values which are transmitted to the simulation
• CHECKED must be assigned to one of the values.

8.11

To allow the user to send a value from a selection, the cell must contain the code in Listing 9, where:

• Title and id05 have the meanings already described
• First, Second, ..., Last are the different choices, one of which is transmitted to the simulation.

8.12

At the beginning of the page, it is necessary to open the HTML table and the form with the tags in Listing 10.

8.13

At the end of the page, the form and the table must be closed with the tags in Listing 11, where

• zTransmit is the Python External Method for processing the form.

8.14

Another functionality was implemented to activate special methods defined within the simulation. To allow users to request the activation of a method exposed by the simulation, the page must contain the code in Listing 12, where:

• id9000 is the name used for identifying special methods
• method1, method2, ..., methodN are the names of the methods to activate.

8.15

Note that implementation of method activation request requires a complete HTML form, each method being associated with a separate submit button. Graphical aspect of the page is not considered here.

Zope external methods

8.16

Function calls inserted in the web page must be linked to the Python functions through external methods. External methods are standard Zope objects used to expose external functions, grouped in Python modules, and make them available within Zope. It is necessary to define one external method for each function call we use within a web page.

8.17

In this application, all the Python functions are grouped in a unique Python module, called sim2web.py.In order to access this module, it must belong to the Zope Extensions folder.

8.18

External methods require four parameters:

ID: the name of the function called in the web page
Title: a description of the function (optional)
Module name: the name of the Python module (without the .py extension)
Function name: the name of the function within the Python module.

8.19

We use the following values in our application:

Table 1: Zope and Python methods.
ID	Module name	Function name
ZAsk	sim2web	zAsk
ZDisplayText	sim2web	zDisplayText
ZDisplaySVG	sim2web	zDisplaySVG
ZTransmit	sim2web	zTransmit

Python functions

8.20

Python functions are grouped in the sim2web.py Python module (Listing 13).

Creation of users and users' directories

8.21

The Zope layer of Sim2Web allows multi-user authentication. In order to activate this feature, one must:

• assign to each user a user id and a password
• create a directory for each user. We chose to group the different users' directories, each identified with the user id, within a global /users directory in the file system of the Zope server.
• create and assign rights to the users in the Zope security system, through the acl_users standard Zope object.

An application: the Prisoner's Dilemma problem

The Prisoner's Dilemma problem

9.1

As an example of the use of Sim2Web architecture, we propose the well-known model of the Prisoner's Dilemma. It was originally formulated by mathematician A.W. Tucker and, with the contributions of Axelrod (1984) and Nowak et al. (1995), it became a key topic of the Game Theory (Taylor 1987).

9.2

The Prisoner's Dilemma has been implemented with many different platforms and simulation tools. It is possible to find stand-alone simulations and many web-based ones. See for instance:

• http://members.ozemail.com.au/~wpdavis/iterated-prisoners-dilemma/
• http://serendip.brynmawr.edu/playground/pd.html
• http://www.patweb.com/game/index2.htm

9.3

For this reason it represents a good test to understand which are the Sim2Web pros in comparison with other platforms.

9.4

Obviously our aim is not to attack the PD problem in a new way, but to use a well-known problem to show the Sim2Web facilities.

9.5

Moreover, although in Axelrod (1984) and Nowak et al. (1995) there is a definitive analysis of the problem, the application of the game in experiments with human players is still a research subject, mostly in experimental economics.

9.6

The "Dilemma" can be summarised as follows:

• two criminals are caught by the police and they are held in separate cells in a jail;
• they cannot talk to each other;
• if neither of them confesses the crime (defects), both get a year in jail, because there is circumstantial evidence against them;
• if one confesses and the other does not (cooperates), the first is free thanks to his usefulness and the second gets three years in jail;
• if both confess they get two years;
• the terms of imprisonment for any possible situation are put into a pay-off matrix (as parameter of the model).

9.7

The following table shows the effect of each possible strategy for the two players, as described above.

Table 1: Payoff matrix
		What other does
		Cooperates	Defects
What you do	Cooperate	You get 2 years The other gets 2 years	You take 3 years The other gets 0 years
	Defect	You get 0 years The other gets 3 years	You take 1 year The other gets 1 year

9.8

This problem is studied to analyse strategies and behaviours in competitive environments. Axelrod pointed out the best rule, inviting game theorists to submit computer strategies for playing iterated Prisoner's Dilemma tournaments (Hofstadter 1983).

9.9

Some of the most famous strategies were the following:

• The Golden Rule. "Do unto others as you would have them do unto you". The player always cooperates (doesn't confess). It's quite easy to take advantage of this innocent strategy.
• The Brazen Rule. "Do unto others as they do unto you". It begins with a cautious defection (the player confesses), but after that it does whatever the opponent did last.
• The Brazen Rule 3. Almost the same as the Brazen Rule. The exception is that it is a little more forgiving. If the opponent defects (confesses), the player will forgive about once every three times and cooperate the next time anyway.
• The Iron Rule. "Do unto others as you wish, before they do it unto you." The player always defects. Both of them tend to accumulate a large prison sentence.
• The Tit-For-Tat Rule. It is similar to the Brazen Rule but it begins with a cooperation (doesn't confess). After that it does whatever the opponent did last (Nowak et al 1992).

9.10

The consistent winner strategy was the cooperative Tit-For-Tat rule. In honour to it, we gave this name to the model developed with Sim2Web, since it is a simply interactive version of the Prisoner's Dilemma.

9.11

The model developed with Sim2Web is a hybrid implementation of the tournament, where agents act autonomously but the humans can force their current strategy. It is a supervised Prisoner's Dilemma tournament.

9.12

The simulation model can run with generic pairs of players but each pair plays separately. Every single computer player is associated with a single human player.

9.13

The artificial agents are programmed with a specific strategy and each of them can receive orders via a web interface, which is accessible only by its authorised (by Zope server) owner. So, the user is in a condition only to observe his own agent and may only send orders to it.

9.14

If the artificial agent does not receive instructions, it decides autonomously according to its strategy. For the sake of simplicity agents can play randomly only the Golden Rule or the Iron Rule, while human player are obviously free to choose the strategy they prefer.

The JAS side

9.15

The model implementation in JAS is quite simple. We will explain only the specific code for the web implementation.

9.16

The TitForTat model class extends the SimModel standard class (Listing 16). When the model has to be loaded into memory, JAS automatically invokes its buildModel() method. This is always the starting point for a simulation.

9.17

The building phase (buildModel) consists of three steps.

• we install the XML-RPC server with the buildServer() method. It creates an instance of the jas.net.InformationServer class on the infoServerTCPPort TCP port. This operation makes the model accessible by the Zope server (more generally by a generic XML-RPC client).
• the buildObjects() method is invoked. It creates artificial players according to the list specified in the parameter window and assigns them a random strategy.
• in order to let the model run it is necessary to specify the sequence of operations to be executed at every step. So, the buildActions() method defines a call to each player's step() method and then a call to the step() and updateServer() of the model itself.

9.18

The sequence of actions defined in the buildActions() method is graphically represented in the sequence diagram. (Figure 2)

9.19

The player's step() procedure will be shown later, while the TitForTat.step() method compares the strategies of each playing couple and updates their cash according to the value found in the corresponding pay-off matrix cell.

9.20

Another crucial task is to update data periodically. The updateServer() method iterates the list of players (a list containing TitForTatBug objects) and asks them for the strings corresponding to the identifiers previously defined in the web page. Each string is sent to the XML-RPC server object using the corresponding name of the bug as a key, with the following instruction:

server.addInfo(bug.getName(), "id01", "Cash: " + bug.getCash());

9.21

Obviously, the simulation will run in a real-time mode, to let the humans think and send commands for interacting through the web page. Artificial agents could play at high speed, but humans would not be able to control their actions. For that reason, each simulated round of the game is performed every ten seconds.

9.22

Notice that the runLocally variable inside the model code is simply used to start the model without the web support, in debugging mode.

Figure 2. Sequence diagram of the TitForTat model

9.23

Finally, we have to analyse the code relative to the players (Listing 15). Each instance of this class represents a computer player that may remotely interact with a human. Therefore the object must be able to generate the output for the web interface, via a plotter for drawing the cash time series.

9.24

When a user points its browser to the Zope server it is asked to type user name and password. Zope will authenticate and show the web page requested. It asks for data from the player with the same name of the logged user.

9.25

As shown in the model code, at every step the JAS scheduler calls the step() method of the player class. This makes the player check the XML-RPC server (srv) for new orders placed by the human player. If nothing new is present the artificial player continues with its previous strategy.

9.26

This operation represents an asynchronous communication between simulated agent and human player. If the user presses the button of the web page, Zope sends information to JAS which updates the orders database, but the artificial player will check for this new order only when it is programmed to do so.

9.27

During the update(double) procedure, the agent not only updates the cash settlement according to the last pay-off but refreshes all the objects that are published on the web page: the history string (representing the past strategies) and the cash plot.

9.28

After data have been updated, the model can refresh the XML-RPC server with the last status of the players. This operation enables the Zope server to show the up-to-date web page of each agent.

The Zope side

9.29

Implementation of the Zope side of the Prisoner's Dilemma problem simulation requires:

• creating the users as previously described
• writing the web page and incorporating the different function calls.

9.30

The HTML code of the web page (a DTML Method object) created in the Zope Object Database is in Listing 16.

9.31

The web-GUI for two players, after ten minutes of play, is reported in Figure 3.

Figure 3. Zope: the GUI for playing Prisoner's Dilemma simulation.

Conclusions and Future Directions for Research

10.1

In this paper we proposed a general framework for web-enabling economic and financial simulations, and we implemented a system where two Open Source tools (JAS Library and Zope) communicate through XML-RPC to allow users to interact with the simulation. In conclusion, the Prisoner's Dilemma problem has been implemented as an example of application of the system.

10.2

This work has demonstrated the effectiveness of this framework and the usefulness of Open Source software coupled to the adoption of standards.

10.3

Although Sim2Web has been developed for economic and financial simulations, its general approach and its standard-based architecture make it a tool of choice for web-enabling simulations belonging to other fields of research: production systems, ecological or social systems and, in general, discrete-event based simulations.

10.4

Future directions for research are oriented towards three improvements of the system:

• Negotiation of the structure of the page. Currently, the researcher must act on two fronts, the simulation and the web interface, and is required to have knowledge of JAS and Zope. We plan to introduce a simple information description language to avoid having the researcher deal with Zope but allowing him/her to fully describe the contents of the web interface.
• Automatic generation of the page. As a direct consequence of the first improvement, after negotiation of the page structure, Zope will autonomously build the HMTL page with the different information blocks used for interaction.
• Improvement of error trapping and management. The actual version of Sim2Web lacks some error control and default behaviour definition. It is likely that network errors or transmission time-out occur, which have to be managed to give the user a smooth unwinding of the simulation.
• Support for standard agent communication protocols (FIPA:http://www.fipa.org, BDI), to enable the platform to use the building blocks. Standard protocols allow the modeller to recycle the implementation of common agent types.

Appendix