Towards Principled FineGrain Composition of Middleware

1
Towards Principled Fine-Grain Composition of
Middleware

• Venkita Subramonian
• Dissertation Proposal Defense
• Distributed Object Computing Group
• Department of Computer Science and Engineering
• Washington University, St. Louis
• venkita_at_cse.wustl.edu

Advisor Dr. Christopher D. Gill
Research supported by DOC Group, Washington
University DARPA PCES and NEST
March 30, 2005
2
Research Context

• Distributed Real-time Embedded (DRE) systems
• Trend towards horizontal integration of DRE
  systems
• Complex DRE systems need correct-by-composition
  development methodologies
• Research focus - Model-driven approaches to build
  correct DRE middleware
• This research aims to provide a principled basis
  to compose correct DRE middleware from fine-grain
• middleware elements

3
Motivation

• Why a principled approach?
• A principled approach provides a formal basis (as
  opposed to an ad-hoc basis) for making
  appropriate choices to deal with interference
• Why target fine-grain middleware elements?
• Key source of interference in middleware
• Makes our approach applicable to a wide variety
  of middleware
• Interference
• Occurs when computations require the same
  resource(s) at the same time - e.g., CPU, thread,
  reactor
• Could occur in application, middleware or OS
  layers
• Interference issues FUNDAMENTAL when analyzing
  safety and liveness properties of DRE systems
• Resolving interference
• E.g., Synchronization, Scheduling, ORB Reply Wait
  Strategies

4
Proposed Research
5
Expert Opinion
ORB configurations have a substantial impact on
performance, e.g., TAO's fastest concurrency
model is thread-per-connection, rather than
thread pool
what's ultimately most important is to determine
how things perform for applications that are
representative of actual user configurations,
rather than micro-benchmarks alone
Dr. Douglas Schmidt, ICE vs CORBA newsgroup
discussion 3/29/05
a main obstacle to the application of rigorous
development techniques is the lack of methodology
for relating application software and functional
design to physical architecture and
implementation
Dr. Joseph Sifakis, Modeling real-time
systems-challenges and work directions, EMSOFT
2001
6
Round-Trip System Engineering Support
Generator/ Weaver
Model Checker
E? reactor.critical and controller.idling
Simulation Verification
Code Synthesis
Libraries
Software
Tests
Formal Model
front end (formal domain)
back end (software domain)
Automated Build Test
Compile, Configure, Run
Modeling Tool Interface
Case ltR1,threads3gt ltR2,threads2gt ltdeadlock_
timer_id3gt ltexpired 1223.001gt
Test output
7
My Research Focus
E? reactor.critical and controller.idling
Existing Software (ACE/nORB)
Tests
Formal Model
Simulation Verification
A First step Model consolidation using an
Iterative approach
Model Checker
8
Research Impact

• Modeling community
• Bringing more concrete models of the platform
• Models reflect actual system more closely
• Middleware community
• Formal documentation of available knowledge
• Bringing more rigor in to model-driven middleware
• Feedback from model verification to code base and
  vice-versa
• Helps correct construction of DRE systems software

9
Proposed Research
10
Problem Interference Issues in DRE Middleware

• Key features of modern DRE middleware
• Reusability
• Flexibility
• Interaction between fine-grain building blocks
  leads to interference
• E.g. Interaction between
• reactor and multiple
• event handlers
• Interference issues in
• middleware affect
• safety and liveness
• properties of DRE systems

This research aims to capture middleware
interference issues formally
11
Extending State-of-the-art

• Extensive research and documentation available on
  patterns in middleware, but
• Informal representation
• Has not been composed with formal models of
  application for formal verification
• We aim to create formal models of fine-grain
  middleware building blocks
• For reuse thru composition that is verifiable
• Encodes collective expertise in building
  middleware
• Provides a formal substrate to analyze
  interference
• E.g. Reactor, Acceptor, Connector, Thread Pools,
  Active Objects

12
Interference Example (Part 1)
Client2
Client1
S1
S2
S3
S4
Client2
Service1
s1
Service2
s2
Client1
s4
Service3
ORB
s3
ORB
Service4
Client2
ORB
ORB
Time
Nested Upcall Loop in request call sequence at
middleware level
13
Inside the ORB Core - Reactor
Application
Middleware
Network
De-multiplexing Dispatching
Application logic
Event Handlers
Event sources
Reactor
Synchronous wait
Serial dispatching
Asynchronous event arrival
14
Safety Issues
Reply Wait Strategy Wait-on-Connection
Service4
Service1
Service3
Service2
EH1
ORB
Reactor
C1
client1
DEADLOCK

• How might we formalize this?

15
Safety Issues A Solution
Reply Wait Strategy Wait-on-Reactor
Service4
Service1
Service2
Service3
EH3
EH1
EH2
ORB
Reactor
C1
C2
C3
client1
NO DEADLOCK, BUT
16
Interleaving calls
Reply Wait Strategy Wait-on-Reactor
Service4
Service2
Service1
Service3
EH1
EH2
ORB
Reactor
C1
C2
C3
client1
client2

• How might we formalize this?

17
Interference Example (Part 1)
Client2
Client1
S1
S2
S3
S4
Client2
Service1
s1
Service2
s2
Client1
s4
Service3
ORB
s3
ORB
Service4
Client2
ORB
ORB
Time
Incoming request while reply from remote server
is pending
18
Timing (Safety) Issues
s1
s2
s4
s2 reply queued
Blocking delay for s1

• Wait-on-Reactor strategy could cause interleaved
  request/reply processing
• Blocking factor could be bounded or unbounded
• Based on the upcall duration
• And number of intervening upcalls

s2 cannot be processed until s4 is done
s4 returns
s1 returns
How might we formalize this?
19
Proposed Research
20
Problem Chasm Between High-Level Model and
Actual System
Formal Models
Petri-nets
Automata
S?
S!
This research aims to reduce this gap
Implementation Platform
CORBA
CCM
EJB
Java RMI
INTERFERENCE
OS
21
Extending State-of-the-art

• Significant research advances in model checking
  techniques
• Highly extensible model checkers e.g. Bogor
• Model checking for timed systems e.g. UPPAAL,
  IF-toolkit
• Application domain experts develop formal models
  of application
• However, middleware domain experts need to chip
  in with formal models of middleware
• Our aim is to close the gap between high-level
  models and the actual system
• Enable the development of composable, verifiable,
  high-fidelity models of middleware

22
Our Solution A Principled Approach
Building blocks
Complete high-fidelity model of the actual system
Middleware
Application

• Verify system properties of the complete model
  using model-checking tools
• Iterate verification step with alternative
  middleware configurations enabling the choice of
  the appropriate set of configurations

23
Our Formalism
Timed Automata Enables us to capture both time
and event-based triggers
Clock variables keep track of time
Guard
time gt 5
x 2
y 6, time0
chan!
Communicating Timed Automata
Actions
Communication
chan?
Invariants
time 5 pulse! time 0
Periodic Pulse
time lt 5
24
Demo example
Event Handler1
conn_s1_s2
Client1
conn_c1_s1
Reactor2
Reactor1
Client1
S1
S2
S3
S4
Client2
s1
s2
s4
conn_s2_s3
Event Handler2
s3
Event Handler3
Time
25
Research Plan

• Create models of building blocks in ACE
• Reactor, Acceptor, Connector, Event
  De-multiplexer, Event Handler, Thread-pool
• Use ACE and ACE-based applications as test case
  for our models
• Experimental Evaluation
• Metric of success - How faithful is the model?

26
Concluding Remarks

• Goal DRE systems that are correct-by-composition
  
• Open research challenges
• Inadequate formal description of interference
  issues in middleware
• Gap between high level application models and
  actual system
• The above challenges can be addressed by a
  principled approach to middleware composition
  using composable, reusable and verifiable formal
  models of middleware building blocks
• Result is complete and faithful models of DRE
  systems
• Future work
• Middleware customization/configuration is
  non-trivial
• A principled approach to guide the
  customization/configuration of middleware

27
BACKUP SLIDES
28
Safety Analysis

• Model needs abstractions from multiple layers
• Application layer method invocation dependency
  DAG
• ACE layer reactors, threads, reply wait strategy
• Deadlock can occur w/ WOC
• Iff ?i ?k gt Ki calls into reactor Ri on a path in
  dependency DAG
• Where Ki is the number of threads in reactor Ri
• E.g., ltf1,f2,f3,f4gt
• Graph node colors designate to which reactor they
  belong
• Count color changes along a path

reactor R1
k1 1
dependency
f4
f1
threads
methods
f2
k2 2
f3
reactor R2
29
Evaluation of tools

• Untimed Automata
• SPIN
• Bogor extensible model checker from KSU
• Timed Automata
• KRONOS
• UPPAAL
• Good graphical interface
• No message parameters
• IF-toolkit
• Uses extended state machine as input language
• Connects to a variety of back-end toolset (e.g.
  CADP)
• ADT support to abstract irrelevant details
  (C/C implementation)

30
IF-toolkit
http//www-verimag.imag.fr/async/IF/index.shtml.e
n
31
IF-toolkit

• Processes, Signals, Channels, Transitions
• Process as an active object?
• Atomicity of transitions
• Guarded (timed and untimed) transitions
• How do we model objects and interaction between
  objects?
• How do we represent blocking calls?
• Observers vs mu-calculus for verification

32
Problem Middleware Configuration is Non-trivial
Connect strategies
Concurrency strategies
Flushing strategies
Middleware
TransportMux strategies
Reply-Wait strategies
Collocation strategies
This research aims to provide a principled basis
to configure/customize middleware
33
Extending State-of-the-art

• Application of model integrated computing
  techniques to middleware development
• E.g., CoSMIC, CADENA
• Modeling languages help application developers
  with
• Component Assembly, Deployment and Configuration
• E.g. Platform Independent Component Modeling
  Language (PICML)
• Component Middleware Configuration
• E.g. Options Configuration Modeling Language
  (OCML)
• Testing and verification
• E.g. Benchmark Generation Modeling Language
  (BGML)
• An essential first step, but more needs to be
  done
• OCML What is the right combination of
  middleware configurations?
• BGML aids exhaustive testing to check
  combinations of configurations for satisfaction
  of QoS requirements
• Our research aims to answer the question Why it
  is the right combination of configurations in the
  context of the application?
• Our research aims to guide middleware
  configuration at the design stage itself