Observability and Controllability of Wireless Software Components

1
Observability and Controllability of Wireless
Software Components

• Fabien Romeo

Liuppa, Université de Pau
2
Background

• Component-Based Software Engineering (CBSE)
• A software component is a unit of composition
  with contractually specified interfaces and
  explicit context dependencies only. A software
  component can be deployed independently and is
  subject to composition by third parties.
  Szyperski et al
  (2002).
• CBSE applied to Wireless Systems (WS)
• WS are heterogeneous systems and
  software componentization allows adaptation
• WS are dynamic and open systems, and as such,
  they often use Service-Oriented
  Architecture, which relies on
  software components (eg. OSGi bundles)

3
The need for management in WS

• Toward Open-World Software Issues and Challenges
• (IEEE Computer Magazine, October 2006)
•  A highly dynamic and open system necessitates
  runtime monitoring to watch for situations that
  might require suitable reactions to assure the
  desired level of global quality. As a result
  of monitoring, it should be possible to handle
  deviations from expected behaviors and plan for a
  reconfiguration. 
• I. Crnkovic, Component-based Software
  Engineering for Embedded Systems, in ICSE05.
• A. Möller, J. Fröberg, and M. Nolin, Industrial
  Requirements on Component Technologies for
  Embedded Systems, in CBSE04.

• Luciano Baresi, Elisabetta Di Nitto, and Carlo
  Ghezzi

4
Management in CBSE

• Maintaining component-based systems is a
  difficult problem Voas (1998)
• Black-boxes, in particular COTS components
• No communication between providers and assemblers
• Management is often an after-thought
• Three kinds of approaches in the literature
• based on the components infrastructure
• Lifecycle management, low-level states
  (attributes) access
• based on the applications architecture
• Components reify the architecture, control by
  replacement
• based on the components behavior
• External observations are confronted against
  behavior models

5
Our proposal

• A runtime management infrastructure
• Address the internal behavior of software
  components
• Wireless remote access
• Deployment on constrained devices (PDA, mobile
  phones, )
• Model-Driven Engineering philosophy
• The components behavior is designed with UML
  State Machines
• Direct execution and control of components
  behavior by their internal managers which embed a
  PauWare Model Execution Engine
• The same models designed at development time are
  retrieved at runtime for management purpose

6
Wireless Software Components Architecture
external effector
Managed Component
external application port
provided interface
internal effector
external pulled sensor
internal pulled sensor
Business Component
Internal Manager
required interface
internal management port
internal management port
external management port
internal pushed sensor
external pushed sensor
7
Statecharts

• Harel 1987  Statecharts
• state-diagrams XOR

• depth hierarchie

• orthogonality AND

• broadcast-communication
• Asynchronous Communication
• Notation signal

8
The PauWare Engine

• Power the execution of Statecharts
  models(simulation, verification, implementation)
• All-terrain Java Implementation (J2EE, J2SE et
  J2ME)

PauWare Engine
PauWare Library
Model of the application dynamics
9
The PauWare Library

• Declaration of states
• Classes Statechart and Statechart_monitor
• Composition of states
• XOR and AND operators
• Declaration of transitions
• fires(String event, Statechart from, Statechart
  to, boolean guard, Object target, String
  action, Object args)
• Generation of events
• _statechart_monitor.run_to_completion("event")

Statechart
Statechart_monitor
10
Example Light
/ UML statecharts / Statechart _On new
Statechart("On") _On.doActivity(this,"display")
Statechart _Off new Statechart("Off") _Off.inp
utState() / PauWare engine /
Statechart_monitor _Light new
Statechart_monitor(_On.xor(_Off),"Light") /
UML transitions / _Light.fires("turnOn",_Off,_On)
_Light.fires("turnOff",_On,_Off) / UML
events / public void turnOn() throws
Statechart_exception _Light.run_to_completion
("turnOn") public void turnOff() throws
Statechart_exception _Light.run_to_completio
n("turnOff")
/ the code is incomplete /
11
PauWare Component Model
 interface  Light functional interface
turnOn() turnOff()
Light
 implement 
 class  Light implementation class
 service  turnOn()  service 
turnOff()  action  display()
1
_Light
1
_ComposytorStatechart_monitor
Internal Manager
_StateMachine
12
PauWare ? WMX

• PauWare with JMX provides a management framework
  for non-wireless components
• Too much for constrained devices

• PauWare
• Java Reflexion Mechanisms
• JMX
• Web Server

Not feasible
Java ME
13
WMX

• Wireless Management eXtensions
• http//wmx.fromeo.fr

Application Side
Management Side
Management Interface
Controle
Manager
Monitor
Java ME
Java SE
14
Demo Traffic Light
15
WMX new problems

• Wireless Management eXtensions
• http//wmx.fromeo.fr

Unreliable Communication Asynchronous Mode ?
Management Interface
Controle
Manager
Monitor
Replication ? Coherence ?
What to transmit and how ? - Events ? - States ?
16
Coherence of statecharts (1)
Application Side
Management Side
turnOff
Forwarding events causes problems with guards
Unknown?
Component
Component
turnOff component.temperature lt 40
turnOff component.temperature lt 40
On
On
On
On
Off
Off
Off
Off
event
turnOn
turnOn
turnOff
component.temperature 43
And we dont want to send low-level states
(attributes)
17
Coherence of statecharts (2)
Application Side
Management Side
turnOff
If we forward the transitions
Component
Component
turnOff component.temperature lt 40
On
On
On
On
Off
Off
Off
Off
transition
turnOn
component.temperature 43
as we still dont want to send low-level states
(attributes)
18
Coherence of statecharts (3)
Application Side
Management Side
turnOff
the statecharts are synchronized
Component
Component
turnOff component.temperature lt 40
On
On
On
On
Off
Off
Off
Off
transition
turnOn
On ? Off
component.temperature 39
we didnt have to send low-level states
(attributes)
because the internal manager handled them for us
19
Composition Management

• Desynchronization of automates(example Traffic
  Light)
• Undetectable Error by Model Checking
• It is supposed to work
• Shows the possibility to define management
  policies based on the replicated statechart

20
States Sub-states (1)
RedLight
turnOff
Off
On
Off
On
do / display
turnOn
TrafficLight
Start
goRed/ RedLight.turnOn
Red
entry goRed
goRed/RedLight.turnOn, YellowLight.turnOff
goGreen/ GreenLight.turnOn, RedLight.turnOff
Yellow
goYellow/YellowLight.turnOn, GreenLight.turnOff
Green
21
States Sub-states (2)
RedLight
turnOff
Off
On
Off
On
do / display
turnOn
TrafficLight
YellowLight
Start
goRed/ RedLight.turnOn
turnOff
Red
entry goRed
Off
On
Off
On
goRed/RedLight.turnOn, YellowLight.turnOff
do / display
goGreen/ GreenLight.turnOn, RedLight.turnOff
Yellow
turnOn
goYellow/YellowLight.turnOn, GreenLight.turnOff
Green
22
States Sub-states (3)
RedLight
turnOff
Off
On
Off
On
do / display
turnOn
TrafficLight
Start
goRed/ RedLight.turnOn
Red
entry goRed
goRed/RedLight.turnOn, YellowLight.turnOff
goGreen/ GreenLight.turnOn, RedLight.turnOff
Yellow
goYellow/YellowLight.turnOn, GreenLight.turnOff
GreenLight
Green
turnOff
Off
On
Off
On
do / display
turnOn
23
Composite Manager
CompositeManager
in(state) / managed.in(state)
Control
to_state(state) / managed.to_state(state)
Monitor
state_changed(transition)
execute(action) / managed.execute(action)
Undefined State Composition
Defined State Composition
part_state_changed / self.check valid_state_guar
d
part_state_changed not valid_state_guard
check / self.to_state(state) consistency_guard
consistency_guard ( !(state compositeState1)
!(self.managedIn(compositeState1))
part1Manager.managedIn(p
art1ComposedState1)
partNManager.managedIn(partNComposedState1) )
( !(state compositeStateN)
!(self.managedIn(compositeStateN))
part1Manager.managedIn(part1Compos
edStateN)
partNManager.managedIn(partNComposedStateN) )
valid_state_guard ( part1Manager.managedIn(part
1ComposedState1)
partNManager.managedIn(partNComposedState1) )
( part1Manager.managedIn(part1ComposedStateN)
partNManager.managedIn(partNC
omposedStateN) )
24
Part Manager
PartManager
in(state) / managed.in(state)
state_changed(transition) / CompositeManager.part
_state_changed
Monitor
Control
to_state(state) / managed.to_state(state)
execute(action) / managed.execute(action)
25
Performances?

• Deployed on a HP iPAQ hx4700
• JVM IBM J9
• Complex Case Studies
• Home automation system
• Railcar System (J2EE JMS)
• , your system

26
Performances Quantitative Study

• Benchmark
• 100.000 loops of state changes
• (adapted from JAC Benchmark)
• Intel Centrino 1600MHz, 512 Mo RAM, WinXP, JVM
  1.5 SUN

Implementation Benchmark Overhead per state change
Pure Java 2 ms 0 µs
Java reflect API 14 ms 0,12 µs
JMX (internal access) 721ms 7,19 µs
PauWare (w/o cache) 1491 ms 14,89 µs
PauWare (w cache) 1027 ms 10,25 µs
Velcro (w/o cache) 1529 ms 15,27 µs
Velcro (w cache) 1038 ms 10,36 µs
Following implementations include I/O or networking Following implementations include I/O or networking Following implementations include I/O or networking
Pure Java System.out.print() 2584 ms 25,82 µs
WMX (velcro sockets) 3893 ms 38,91 µs
JMX RMI connector 22077ms 220,75 µs
27
Conclusion

• PauWare
• Components driven by executable statecharts
• But also a framework for experimenting research
  results in MDA, CBSE,
• Velcro WMX
• Management of the software components behavior
  in the context of wireless systems
• Perspectives
• Integration into other component models (OSGi,
  Fractal, )
• Persistence at runtime of other types of models,
  (other views for management)
• Autonomic Computing a solution to put the human
  on the loop

28
PauWare
 Power is not a means, it is an end. 
George Orwell, Nineteen
Eighty-Four
Thank you for listening!

• Fabien Romeo, Franck Barbier, Jean-Michel Bruel,
  Observability and
  Controllability of Wireless Software Components,
  7th IFIP Conference on
  Distributed Applications and Interoperable
  Systems, Paphos, Cyprus, 5-8
  june, 2007.
• Code available at http//www.pauware.com
• 
  http//wmx.fromeo.fr

29
Bonus Track
30
Velcro
PauWare
java.lang.reflect
PauWare (java.lang.reflect)
Velcro
Velcro
31
Horizontal Composition

• Components have the same granularity
• Client / Server or Peer to Peer
• Provided Interfaces / Required Interfaces
• Low coupling
• Distributed Application
• Statecharts Communication by signal
• JMS, Message-Driven Bean

32
Example Traffic Light
33
Vertical Composition

• (De)composition composite/compound
• Hierarchie (cf. Fractal)
• A higher coupling
• Life-cycle Dependances, encapsulation,
• Theoretical Foundations
• Revised formalization of aggregation and
  composition in UML (IEEE TSE 29(5) et 29(11) -
  2003)
• State Machines of compound components integrated
  into the State Machine of the composite as
  concurrent macro states
• public class Light extends _PauWare.Composable
  / ... /
• Light redLight, yellowLight, greenLight
• Statechart_monitor trafficLight new
  Statechart_monitor(redLight.state_machine()
  .and(yellowLight.state_machine())
  .and(greenLight.state_machine(
  )) .and(start.xor(red).xor(ye
  llow).xor(green)))

34
Example Traffic Light
35
PauWare Component Model

• A State Machine Execution Engine (diagrammes
  UML 2)
• Model verification at development time
• Support for implementation
• Models persist at runtime
• State Machine ? Components ?
• Structure-Behavior Binding(i.e.
  component-statechart)
• Support for horizontal composition and
  vertical composition (hierarchical)

36
PauWare Component Model
 interface  Light functional interface
turnOn() turnOff()
Light
 implement 
 class  Light implementation class
 service  turnOn()  service 
turnOff()  action  display()
1
_Light
_ComposytorStatechart_monitor
37
Behavior modeled with Statecharts
Managed Component
SB
service2 guard1 / self.serviceX
service2 guard2 / action1
service1
SA
service2
service2
service1
S2
S3
serviceX / action4
service2
entry action3
with (guard1 gt not guard2) and (guard2 gt not
guard1)
38
Detailed Architecture
interface Business Component functional
interface service1() service2()
interface Internal Pushed Sensor
control_service1() control_service2()
control_serviceX()
interface External Pushed Sensor
state_changed(transition)
interface Internal Pulled Sensor guard1()
guard2()
interface External Pulled Sensor in(state)
require
require
require
interface Internal Effector service1()
service2() serviceX() action0() action1()
action2() action3() action4()
interface External Effector execute(action)
to_state(state)
Business Component
Internal Manager
require
implement
implement
class Business component implementation class
service service1() service service2()
service serviceX() action action0()
action action1() action action2() action
action3() action action4() guard guard1()
guard guard2()
class Internal Manager implementation class
control_service1() control_service2()
control_serviceX() execute(action)
to_state(state) in(state)
1
_ComposytorStatechart_monitor
serviceX is not part of the functional interface
since it is only sent internally
39
Demo
Management Communication (WMA)
Management Console (JMX)
Wireless Components (J2ME)
40
PauWare Library
Event
State-based programming support
public void f_c() throws Statechart_exception
_Programmable_thermostat.fires(_Ambient_temp
erature_displaying,_Ambient_temperature_displaying
) _Programmable_thermostat.fires(_Target_
temperature_displaying,_Target_temperature_display
ing,true,this,"switch_mode")
_Programmable_thermostat.fires(_Program_target_tem
perature_refreshing,_Program_target_temperature_re
freshing,true,this,"switch_mode")
_Programmable_thermostat.run_to_completion()

UML-2 run-to-completion model execution mode
41
Model Execution
42
Demo
Fan switch
Is on
 
auto
on/ programmable thermostat.fan switch turned on
Is auto
43
Demo Home Automation System
PauWareView
44
MDA CBSE

• MDA (Model-Driven Architecture)
• Model Centric Developpements
• Model Transformation
• UML structural models and behavioral
  models
• CBSE
• Structural Models architecture, composition,
  interfaces
• Technological Component Model
  (model format)

PIM
PSM
PSM
PSM
45
Application Management

• Monitoring
• Sensors
• Controlling
• Activators
• What to monitor?
• What to control?
• Where is the line between the application
  and the management system?

Management System
sensors
activators
Application
46
Towards Autonomic Computing
Cf. Cyril Ballagnys on-going thesis