Coordinating entities in a networked environment has always been a significant challenge for software developers. In recent years, however, it has become even more difficult, because devices have increasingly rich capabilities, combining ever larger range of technologies (networking, multimedia, sensors, etc.).
To address this challenge, we propose a language-based approach to covering the lifecycle of applications coordinating networked entities. Our approach covers the characterization of the networked environment, the specification of coordination applications, the verification of a networked environment and its deployment. It is carried out in practice by a domain-specific language, named Pantaxou.
We develop the domain-specific language Pantaxou, dedicated to the development of applications for networked heterogeneous entities. Pantaxou has been used to specify a number of coordination scenarios in areas ranging from home automation to telecommunications. The language semantics has been formally defined and a compiler has been developed. The compiler verifies the coherence of a coordination scenario and generates coordination code in Java.
Detailed description
Syntax and operational semantics
here.
Figure 1. Complete compilation process
Figure 1 shows the main steps in the compilation of a Pantaxou application. First, a Pantaxou application is passed to the Pantaxou compiler, which (1) verifies the consistency of the model of the networked environment and the conformance of the Pantaxou service with this model, as described in Section 4, (2) transforms the model into a specification expressed in
DiaSpec, which is an ADL dedicated to specifying the interactions that are allowed within a distributed application, and (3) transforms the coordination logic into a Java application. The DiaSpec specification is then passed to the DiaSpec compiler, which generates a Java programming framework on which to build distributed applications. This programming framework is dedicated to the given environment model and provides boilerplate functionalities, such as methods for service discovery or for publishing typed events. The Java application generated by the Pantaxou compiler relies on this dedicated programming framework. Finally, a standard Java compiler is invoked to produce executable code.
Use cases
Figure 2. Secretary scenario
1. The Bluetooth detector detects that a Bluetooth device has just entered.
2. The Bluetooth detector publishes an event to signal the presence of the Bluetooth device. This event is received by Bluetooth Manager.
3. The Bluetooth Manager queries the database to know who the tag belongs to.
4. The Bluetooth Manager publishes an event to signal that Alice is in office 1. This event is received by Presence Agent.
5. When Alice is called, an audio session request is received by her Virtual Phone.
6. The Virtual Phone queries Presence Agent to know where Alice is.
7. The Virtual Phone transfers the call to the phone of office 1.
Pantaxou environment model
Specifying a networked environment using Pantaxou first involves declaring the functionalities of entities and the kinds of data they exchange.
Data types
The below code illustrates standard structure declarations for our secretary scenario. Libraries of data types can be imported. Pantaxou also provides some domain-specific types, such as uri (Uniform Resource Identifier).
import Audio;
struct Room {
int number;
}
struct Presence {
uri entity;
bool status;
Room room;
}
struct DbBluetoothInfo {
uri ownerName;
}
struct BluetoothDetection {
string bluetoothAddress;
int signalStrengh;
}
Signatures
Pantaxou provides an interface definition language for declaring command interfaces, as provided by RPC-related technologies. Examples are given below. Such a declaration names a group of commands (e.g., DbQueryBluetooth) and lists the commands' signatures (e.g., getInfoBT).
command DbQueryBluetooth {
DbBluetoothInfo getInfoBT(string bluetoothAddress);
}
command GetRoom {
Room getRoom(uri user);
}
Service taxonomy
A Pantaxou taxonomy defines a collection of service classes, each of which groups together entities that share the same functionalities. We refer to an entity as a service. A service interacts with other entities in terms of their service classes, via a process of service discovery. It is thus shielded from irrelevant variations in the available entities. A service class declaration specifies a collection of attributes that range over the variations in non-functional service properties and declares the interaction modes that services provide to and require from other service classes. Finally, service classes are hierarchically organized, enabling the coordination logic to abstract over unnecessary service details by using less specific service classes.
The below code displays the declarations of service classes for the advanced telecommunication environment. The declared service classes form a hierarchy, as shown in Figure 3. Each service class is associated with a set of attributes and interaction modes. The attributes, such as room in the Device service class, allow a service to characterize itself in terms of the values of its nonfunctional properties. These attributes are then consulted during service discovery, e.g., allowing the secretary scenario to discover a phone in a specific room to be able to forward a call. The interaction modes are annotated to indicate whether the interaction mode is provided or required and the classes of services with which the interaction is allowed. For example, the BluetoothPresence- Manager requires Bluetooth detection events that are produced by the BluetoothDetectorAgent. A BluetoothPresenceManager may also use the command DbQueryBluetooth of an InfoDB service to associate a detected bluetooth device with its owner and must provide presence events to PresenceAgent services.
The hierarchical definition of service classes allows subclasses to inherit the attributes and interaction modes of their ancestors. This approach makes it possible to characterize classes of entities as an incremental refinement process. For example, in our advanced telecommunications environment, we introduce a virtual phone that behaves like a phone (its ancestor) but requires a command to get the current location of a secretary to forward her calls to a room's phone.
service Service {}
service Device extends Service {
Room room;
}
service BluetoothDetectorAgent extends Device {
provides event to BluetoothPresenceManager;
}
service PresenceAgent extends Service {
requires event from BluetoothPresenceManager;
provides command to Service;
}
service InfoDB extends Service {
provides command to BluetoothPresenceManager;
}
service BluetoothPresenceManager extends Service {
requires event from BluetoothDetectorAgent;
requires command from InfoDB;
provides event to PresenceAgent;
}
service Phone extends Device {
provides session to Phone;
requires session from Phone;
}
service VirtualPhone extends Phone {
requires command from PresenceAgent;
}
Figure 3. Hierarchy of services
Pantaxou services
The development of an application is guided by the description of the networked environment, enabling the programmer to focus on the coordination logic. The below code (Presence manager and call forwarding services) illustrates the complete Pantaxou implementation of the secretary scenario.
Presence manager service
import datatype BluetoothDetection;
import datatype DbBluetoothInfo;
import datatype Presence;
import datatype Room;
import command DbQueryBluetooth;
import service Service.InfoDB;
import service Service.BlueToothPresenceManager;
'sip:
This e-mail address is being protected from spambots. You need JavaScript enabled to view it
' instantiates BluetoothPresenceManager {
service { } bluetoothDetectorAgent;
service { } database;
event from bluetoothDetectorAgent[*] {
signalStrengh > 50;
} btDetectionEvt;
var database db = new database[1];
onReceive btEvtReception(btDetectionEvt e) {
DbBluetoothInfo i = db.getInfoBT(e.data.bluetoothAddress);
event {
entity = i.ownerName;
room = e.src.room;
} p;
publish(new p);
}
initial {
adopt(btEvtReception);
}
final {}
}
Call forwarding service
import datatype Audio;
import datatype Room;
import datatype Presence;
import command GetRoom;
import command Display;
import service Service.PresenceAgent;
import service Service.Device.Phone;
'sip:
This e-mail address is being protected from spambots. You need JavaScript enabled to view it
' instantiates Phone.VirtualPhone {
service {} phone;
service {} pa;
session from phone[*] {} inSess;
var pa agent = new pa[1];
onReceive callReception(inSess s) {
service {
room = agent.getRoom('sip:
This e-mail address is being protected from spambots. You need JavaScript enabled to view it
');
} myPhone;
invite(new myPhone[1], s) {
accepted(activeSession aas) {
// An active audio session (aas) is accessible.
}
rejected() {
reject(s); // Forward the reject.
}
}
}
initial {
adopt(callReception);
}
}
Related work
Related Phoenix projects
Session Processing Langage (SPL)
DiaGen
Pantagruel
Participants
Charles Consel
Julien Mercadal
Nicolas Palix
Julia Lawall (External Collaborator)
Tools
OCaml
