Unifying Event-based and Rule-based Styles to Develop Concurrent
and Context-aware Reactive Applications
Toward a Convenient Support for Concurrent and Reactive Programming
Truong-Giang Le
1
, Olivier Hermant
1
, Matthieu Manceny
1
, Renaud Pawlak
2
and Renaud Rioboo
3
1
LISITE - ISEP, 28 Rue Notre-Dame des Champs, 75006 Paris, France
2
IDCapture, 2 Rue Duphot, 75001 Paris, France
3
ENSIIE, 1 Square de la R´esistance, F-91025
´
Evry, France
Keywords:
Event-based Programming, Rule-based Programming, Concurrent Applications, Context-awareness, Reactive
Applications.
Abstract:
We propose a new programming language called INI, which combines both event-based and rule-based styles
and is suitable for building concurrent and context-aware reactive applications. In our language, both events
and rules can be defined intuitively and explicitly, in a stand-alone way or in combination. Events in INI can
run in parallel in order to handle multiple tasks concurrently and may trigger actions defined in related rules.
Besides, events can interact with the execution environment to adjust their behaviors if necessary and response
to unpredicted changes. This makes INI a convenient language to write many kinds of programs which need to
take advantages of concurrency and context-awareness, such as embedded software, interactive applications,
sensors applications, robotic systems, etc.
1 INTRODUCTION
Context-awarereactiveapplications are intelligent ap-
plications that can monitor the runningcontextby reg-
istering eventhandlers. In case of changes in this con-
text, they may adapt their behavior if needed and re-
act accordingly in order to satisfy the user’s desired
requirements (Daniele et al., 2009). Such aware sys-
tems have become one of the most exciting concepts
in ubiquitous computing, with a wide range of appli-
cation areas, e.g. monitoring and controlling systems
(Loke, 2006; Dargie, 2009). Ideally, since multipro-
cessors are now very widespread, a context-aware re-
active system should use multithreading so that it may
handle multiple tasks in parallel to improve the per-
formance and responsiveness (Sand´en, 2011).
Context-aware computing was first discussed by
Schilit et al. (Schilit and Theimer, 1994). Since
then, there have been numerous attempts to support
context-aware computing. However, writing context-
aware reactive applications is still challenging. The
main reason is that we need a well-defined mecha-
nism to handle with widely varied sources of context
information. In order to support programmers to write
these kinds of applications more intuitively and strai-
ghtforwardly, we develop a new language called
INI. INI compounds both event-based and rule-based
paradigms, which are appropriate styles to monitor
and react to changes in the environment. Although
several event-based and rule-based programming lan-
guage have been proposed so far (Cohen and Kalle-
berg, 2008; Baillie et al., 2010; Mircea Marin, 2006;
Giurca et al., 2009), they still do not provide a flexi-
ble and intuitive way to define events and rules as in
INI. Another advantage of INI is that it supports mul-
tithreading to speed up the execution.
The rest of this paper is organized as follows. In
Section 2, we introduce INI, including its syntax, in-
formal semantics and type system. We discuss a case
study of using INI to write concurrent context-aware
reactive applications in Section 3. Section 4 con-
cludes the paper.
2 PROGRAMMING WITH INI
INI combines both event-based and rule-based pro-
gramming styles. With event-based programming,
changes in the operational environment can be eas-
ily captured and handled during execution. With rule-
347
Le T., Hermant O., Manceny M., Pawlak R. and Rioboo R..
Unifying Event-based and Rule-based Styles to Develop Concurrent and Context-aware Reactive Applications - Toward a Convenient Support for
Concurrent and Reactive Programming.
DOI: 10.5220/0004081403470350
In Proceedings of the 7th International Conference on Software Paradigm Trends (ICSOFT-2012), pages 347-350
ISBN: 978-989-8565-19-8
Copyright
c
 2012 SCITEPRESS (Science and Technology Publications, Lda.)

based programming, a program may react straightfor-
wardly to changes.
2.1 Functions and Rules in INI
Each INI program contains functions, which combine
event expressions, logical expressions (used to spec-
ify the conditions to trigger) and the actions (lists of
statements) bound to them. The scope of all variables
is the whole function. A function in INI has the fol-
lowing syntax:
func t i o n <name>(< parameters >) {
<l o g ic a l e x p re ss i on > { <s t a te ments> }
| <e ve nt e xpress i o n> { <s tatem e n t s> }
| <e ve nt e xpress i o n> <l og i c a l e xp re s si on >
{ <statem e n t s> }
}
A rule in INI consists of a logical expression and a
corresponding action. When the logical expression
part of a rule is evaluated to true, the action is in-
voked. INI also allows the use of logical expressions
along with events, and in this case they play the same
prerequisite role as in rules.
2.2 Events in INI
(M¨uhl et al., 2006) defines events as any happening
of interest that can be observed by a system. An event
instance in INI starts with @ and takes input and out-
put parameters, both are optional. The scope of output
parameters is the whole function, like other variables.
Moreover, an event can also be bound to an id and
synchronized on other events through
$ (id1,...,idN)
construct (as described below). The syntax of event
instances is as follows.
$ ( id1 , id2 , . . . , idN ) id0 : @eventKind
[ inputParam1 =value1 , inputParam2 =value2 , . . . ]
( outputParam1 , outputParam2 , . . . )
{ <s ta tements> }
Programmer may use built-in events (listed in Ta-
ble 1), or write user-defined events (in Java or in
C/C++), and then integrate them to their INI programs
(Le, 2012).
By default, except for the @init and @end events
(see Table 1), all INI events are executed asyn-
chronously. However, in some scenarios, a given
event id0 may want to synchronize on other events
id1,..., idN. It means that the synchronizing event id0
must wait for all running threads corresponding to the
target events to be terminated before running. For
instance, when id0 affects the actions defined inside
other events, we need to apply the synchronization
mechanism.
Table 1: Some built-in events in INI.
Built-in event Meaning
@init() Used for initialization,
when a function starts.
@end() Invoked when no more rule
or event in the function
can run or when the
function is about to return.
@every Triggers an action, period
[time:Integer]() is indicated by its input
parameter (in milliseconds).
@update[variable:T] Invoked when the value
(oldValue:T, of an observed variable
newValue:T) changes during execution.
Events in INI may also be reconfigured at run-
time to adapt their behaviors to changes happening in
the environment. Programmers can call the built-in
function reconfigure
event(eventId, [inputParam1 =
value1, inputParam2 = value2,...]) in order to modify
the the values of event’s input parameters (see Section
3 for example). To understand more about the algo-
rithm we use to implement events synchronization in
INI, and also the event reconfiguration mechanism,
please refer to our previous paper (Le et al., 2011).
2.3 Example
To illustrate rules and events in INI, let us consider an
automatic lighting control system in a corridor (Fig-
ure 1). In our program, there is one user-defined
event called @motionDetection, that is applied to de-
tect movement. This event has one input parameter
named mode, which is set to point out whether we
apply a simple algorithm or an advanced one for de-
tecting motion. Whenever a motion is detected, our
program will turn on the lights if they were turned off
before (lines 9-12). The event @every at lines 15-17
is applied to set how long does it pass without any mo-
tion. If there is no movement within fifteen minutes
and the current lights state is on, a rule at lines 18-21
will be invoked to turn off the lights to save energy.
2.4 Type System in INI
2.4.1 Built-in Types
INI comes with 5 built-in types for numbers (Double,
Float, Long, Int, and Byte), a Char type, and a
Boolean type. Besides, INI provides a built-in poly-
morphic map type: Map(K, V), where K is a key type
and V is a value type. Lists are instances of maps
when K = Int (in reality, it is more of an indexed set).
ICSOFT2012-7thInternationalConferenceonSoftwareParadigmTrends
348

1 function main() {
2 @init() {
3 lightOn = false
4 timeWithNoMotion = 0
5 }
6 @motionDetection [mode = "simple"](){
7 timeWithNoMotion = 0
8 case {
9 !lightOn {
10 //Turn on the lights
11 lightOn = true
12 }
13 }
14 }
15 @every[time = 60000]() {
16 timeWithNoMotion ++
17 }
18 timeWithNoMotion > 15 && lightOn {
19 //Turn off the lights
20 lightOn = false
21 }
22 }
Figure 1: An automatic lighting control system.
String type is a list ofChar. Syntactically, lists can be
noted with the * notation:
T ∗ b=Map(Int, T)
INI types are ordered with a subtyping relation ≻.
Numerics are ordered so that it is not possible to as-
sign more generic numbers to less generic numbers.
Double ≻ Float ≻ Long ≻ Int ≻ Byte
Other conversions must be done by using built-in
functions (Le, 2012).
2.4.2 User-defined Types
To define a new type, the programmer uses the type
keyword followed by a name starting by an upper-
cased letter. For example, we can define and use a
Person type as:
ty pe Person = [ name : Stri ng , age : I n t ]
p = Person [ name=”Giang ” , age =28]
p r i nt ln (” I n f o : ” + p . name + ” i s ” + p . age )
Field access is done with a usual “dot” and field
initialization is not mandatory. One can construct a
person with undefined age or name. Moreover, types
can be recursive. For example, we can refine the
above Person type as:
ty pe Person = [ name : Stri ng , age : Int , f a t he r :
Person , mother : Person , c h i ld r e n : Person ∗]
Note that INI also performs type-checking on ob-
ject fields. In order to understand more about types
in INI, please refer to INI Language Reference Docu-
mentation (Le, 2012).
2.4.3 Type Inference
INI provides type inference, so that the programmers
may leave types implicit. For instance, the i=0 state-
ment will assign to i the Int type. If the program-
mer tries to set the type of i to any other type within
the definition scope of i, (for instance with the i=0.1
statement that assigns i with a Float type) the INI type
checker will raise a type mismatch error.
Most types in INI are calculated with the type in-
ference engine. The core of this type inference is
based on a Herbrand unification algorithm, as de-
picted by Robinson in (Robinson, 1965). The typ-
ing algorithm is enhanced with polymorphic function
support, abstract data types (or algebraic types) sup-
port, and with internal sub-typing for number types.
3 CASE STUDY
Figure 2 showsan intelligent virtual personal assistant
written in INI, which can recognize voice commands
from users and then do appropriate actions. One of
the most interesting features of our program is that it
can detect who is using it (based on face detection),
in order to adjust the voice recognition process with
regard to his or her maternal language, tones and ac-
cents. This data is previously collected and stored in
a database during a speech training procedure. As a
result, the accuracy of voice recognition will be im-
proved.
There are two user-defined events in our program.
The event @faceRecognition (identified by f) is ap-
plied to detect a human face. This event has one out-
put parameter called recognizedId, which is used to
indicate the corresponding id (if existing) of the user.
If a new face is detected, we stop the event @voiceRe-
cognition (identified by v), reconfigure it depending
on whether the user has been recognized or not, and
restart the eventv in order to improve the performance
of voice recognition. The event @voiceRecognition is
used to recognize user’svoice. It has one input param-
eter specifying the id of the user, which is applied in
order to tune the recognition pattern. Moreover, there
is one output parameter called voiceCommandString,
which is the returned recognized spoken sentence. At
line 28, we match the user’s command against a reg-
ular expression to guess its meaning (by using the
match operator ∼), and then do a suitable action. The
event f should be synchronized on the event v, which
means that if there is a current running thread for v,
f has to wait before it can be executed. The synchro-
nization is necessary since we want to avoid unfin-
ished voice recognition jobs to be stopped.
UnifyingEvent-basedandRule-basedStylestoDevelopConcurrentandContext-awareReactiveApplications-Towarda
ConvenientSupportforConcurrentandReactiveProgramming
349

1 f u n ction main () {
2 @init ( ) {
3 d ef au lt Id = 1
4 c u rr en tId = 1
5 }
6 $ ( v ) f : @faceRecognition ( isKnown ,
7 re cogniz e d Id ) {
8 case {
9 / /A f a m il ia r person i s dete c t ed ,
10 / / then change c ur r en t s e t t in gs
11 / / to new s e t t i n g s
12 isKnown && r e cognize d I d != c u r re nt I d {
13 cu rr e n tId = re c o gn iz edId
14 st o p e v en t ( v )
15 re c o n fi g ur e e ve n t ( v , [ u serId = c u r r e nt Id ] )
16 r es t a r t e ve nt ( v)
17 }
18 / /A s t r a n g e r i s detec t e d ,
19 / / then use d ef a u l t s e t t i n g s
20 ! isKnown {
21 . . .
22 }
23 }
24 }
25 v : @voiceRecognition [ u s erId = d ef au l t I d ]
26 ( voiceCommandString ) {
27 case {
28 voiceCommandString ˜ regexp ( . . . ) {
29 / / Do a c t io n 1
30 }
31 . . .
32 de fa u l t {
33 / / Do a d ef au lt a c t io n
34 }
35 }
36 }
37 }
Figure 2: An intelligent virtual personal assistant.
4 FUTURE WORK
For future work, we will develop a context recovery
mechanism in INI so that when the reaction fails, our
program can recover to the previous stable state. Ad-
ditionally, we will define formal semantics for INI
with thoughtful consideration of parallel and concur-
rent aspect. Operational semantics, denotational se-
mantics or axiomatic semantics with some exeten-
sions can be taken into account. Furthermore, we also
have a plan to apply INI in more real applications in
order to better evaluate its capabilities.
ACKNOWLEDGEMENTS
The work presented in this article is supported by
the European Union. Europe is committed in Ile-
de-France with the European Regional Development
Fund.
REFERENCES
Baillie, J.-C., Demaille, A., Hocquet, Q., and Nottale, M.
(2010). Events! (reactivity in Urbiscript). CoRR,
abs/1010.5694.
Cohen, N. H. and Kalleberg, K. T. (2008). EventScript:
an event-processing language based on regular expres-
sions with actions. In Proceedings of the 2008 ACM
SIGPLAN-SIGBED conference on Languages, com-
pilers, and tools for embedded systems, LCTES ’08,
pages 111–120, New York, NY, USA. ACM.
Daniele, L. M., Silva, E., Ferreira, L., and van, M. S.
(2009). A SOA-based platform-specific framework
for context-aware mobile applications. In Enterprise
Interoperability, volume 38 of Lecture Notes in Busi-
ness Information Processing, pages 25–37, Berlin
Heidelberg. Springer Verlag.
Dargie, W. (2009). Context-Aware Computing and Self-
Managing Systems. Chapman & Hall/CRC, 1 edition.
Giurca, A., Gasevic, D., and Taveter, K. (2009). Handbook
of Research on Emerging Rule-based Languages and
Technologies: Open Solutions and Approaches. IGI
Publishing, Hershey, PA, USA.
Le, T.-G. (2012). Ini Online.
https://sites.google.
com/site/inilanguage
.
Le, T.-G., Hermant, O., Manceny, M., and Pawlak, R.
(2011). Dynamic adaptation through event reconfigu-
ration. In Meersaman, R., Dillon, T., and Herrero, P.,
editors, On the Move to meaningful Internet Systems:
OTM 2011 Workshops, volume 7046 of Lecture Notes
in Computer Science. Springer.
Loke, S. (2006). Context-Aware Pervasive Systems. Auer-
bach Publications, Boston, MA, USA.
Mircea Marin, T. K. (2006). Foundations of the rule-based
system pLog. Journal of Applied Non-Classical Log-
ics, 16:151–168.
M¨uhl, G., Fiege, L., and Pietzuch, P. (2006). Distributed
Event-Based Systems. Springer-Verlag New York,
Inc., Secaucus, NJ, USA.
Robinson, J. A. (1965). A machine-oriented logic based on
the resolution principle. J. ACM, 12(1):23–41.
Sand´en, B. (2011). Design of Multithreaded Software: The
Entity-Life Modeling Approach. John Wiley & Sons.
Schilit, B. and Theimer, M. (1994). Disseminating ac-
tive map information to mobile hosts. IEEE Network,
8:22–32.
ICSOFT2012-7thInternationalConferenceonSoftwareParadigmTrends
350