# On the Use of the Multi-Agent Environment for Mobility Applications
## 3 Environment for Non-Spatial Interaction in Mobility Applications
### Example Application: Environment-Centred System for Traveller Information  
In this section, we describe an application based on our model. We modelled and implemented a traveller information server. The purpose of the server is to inform online travellers about the status of the parts of the transportation network that concern them. Transportation Web services are represented with agents in the server, and their properties are related to the service or the information that they provide. The problem in this kind of application concerns the information flows that are dynamic and asynchronous. Indeed, each information source is hypothetically relevant. An agent cannot know a priori which information will interest him, since this depends on his context, which changes during execution [9]. The objective of this application is to ensure the information of a traveller about his ongoing trip (disturbances, alerts, alternative itinerary). This process is complex because the information sources are distributed, and the management of the follow-up assumes a comparison of all the available information. Using our environment model for this application allows designing an information server parameterised by its users (the travellers). We defined two categories of agents. The first concerns the agents representing the users (that we call PTA for Personal Travel Agent), while the second concerns the agents representing the transportation services (that we call Service Agent). We implemented a multi-agent system running on a Web server for traveller information. Each Web service has a representation in the multi-agent environment, which is responsible for conveying messages from the server to the transportation Web service conversely. Every user is physically mobile and connects to the server via a transportation assistant app (TAA). During his connection, a PTA agent represents him inside the server, which is his interlocutor during his session. The context of the example is the following: inside the system, an agent represents a trip planning service, and an agent represents a traffic service responsible for the emission of messages related to incidents, traffic jams, etc. These agents are persistent since they are constantly associated with the service system. On the contrary, PTA agents representing the TAA in the system are volatile, created on a user's connection and erased at the end of his session, i.e., when he/she arrives at destination. Every stop of the network is described by a line number \(line\) to which it belongs, and a number \(number\) reflecting his position on the line. A user \(u\) is also described by his current position in the network (the properties \(line\) and \(number\)). In a basic execution scenario, \(u\) has a path to follow during his trip, i.e. a sequence of tuples \(\{(line,number_{source},\)\(number_{destination})_{i}\ |\ i\in I\}\), with \(I\) the number of transportation means used by the traveller. Every tuple represents a part of the trip, without transfer. The TAA connects to the information server to receive his plan, and the agent \(u\) representing him is created. Then, the user is asked to specify his departure and his destination. Once this information is entered, \(u\) adds his planning demand in the environment. A demand is an object described by its properties: \(emitter,subject,\) etc. Afterwards, \(u\) keeps on listening to messages that are addressed to him, this way: \(look(\emptyset,\{message\gets x\},x.receiver=id)\). The agent representing the trip planning service is listening to messages asking for a plan: \(look(\emptyset,\{request\gets x\},x.subject=\"plan\")\). As soon as he/she receives the message, he/she creates a message addressed to the trip planning Web service and awaits the response. When he/she receives the answer, a message is added to the environment addressed to \(u\) with the received plan as body: \(add(\{emitter\gets id,receiver\gets request.emitter,body \gets plan\})\).