Refining middleware functions for verification purpose

1
Refining middleware functions for verification
purpose

• Jérôme Hugues (hugues_at_enst.fr)
• Laurent Pautet (pautet_at_enst.fr)
• Fabrice Kordon (Fabrice.Kordon_at_lip6.fr)

2
Distribution middleware (MW)

• Multiple dimensions
• Domains avionics, space, transportation
• Families reliability, integrity
• Application f (Domains, Families)
• Different distribution requirements or needs
• Various facilities DOC, RPC, MP, (D)SM
• Different models CORBA, DSA, JMS
• Middleware architectures that enable
• Customization
• Verification

3
Goal build proof-based middleware

• A priori engineering process
• Guidelines for certification
• Restricted profiles e.g. Ravenscar
• Modeling MetaH, AADL
• A posteriori verification
• Modeling formal methods and tools
• How to handle variations (DxF space) ?

1. Reduce MW components scope
2. Define MW component connectors
3. Define a MW architecture to ease verification

4
Variations configurability

• Minor variations at deployment
• Communication channels
• OS, runtime or hardware capabilities
• Implementation of software components
• Design patterns and frameworks are appropriate
  solutions at this level
• one can choose the most adequate implementation
  for a specific component

5
Variations genericity

• Major variations in distribution facilities
• Generic middleware
• Single architecture
• Generic components abstract interfaces
• Personality
• Instance of generic middleware for a given
  distribution model
• Built from a restricted set of general and
  specific components
• Jonathan/Quarterware/ACT
• Increases code reusability, but limited (10-25)

6
Beyond configurability genericity

• Several domains/families in one application
• Integrity, reliability, ..
• Heterogeneous distribution models in one
  application
• Redundant components gt Large footprint
• Interacting components gt Support for
  heterogeneity
• Strong architecture and component requirements
• Aggressive code reuse
• Interoperable components
• gt Neutral from distribution model
• Schizophrenic middleware (extreme genericity)
• Collocating and interacting personalities

7
PolyORB schizophrenic middleware

• Developed in Ada, approx. 110 klocs
• Configurability component-level
• Well-known or new patterns
• Tasking profiles no tasking, full tasking,
  Ravenscar
• Genericity architecture
• Separation of key middleware functions
• Functional implementation of
• CORBA, MOMA, DSA, AWS, SOAP, IIOP, MIOP
• Instantiations 75 code from generic layer
• Performance
• Compete with traditional middleware for similar
  setups
• Greater code reuse than generic middleware
• Entered industrialization process
• Supported free software (Ada Core Technologies)

8
Schizophrenic MW collocating and interacting
personalities

• Neutral core MW
• MW mechanisms as generic components
• ensures high code reuse ratio

9
Refining MW functions for verification purpose

• Neutral Core Middleware 7 core functions
• Simple finite state machines, data manipulators
• Coordinated by a broker architectural component
• To be verified first

Transport
Execution
Activation
Binding
Addressing
Representation
Protocol
Broker
10
How to model the broker ?

• Combination of 2 modeling facilities
• To catch broker behavior
• and then to detail it for verification
• One high-level model
• Descriptive easy to manipulate
• One lower-level model
• Enable formal verification

11
How to describe the broker ?

• Design patterns
• Solutions for recurrent problems
• Many patterns documented
• Typical solutions to design middleware
• Well-known broker patterns
• Coordinate entities in distributed application
• Covers client, server, communication, ..
• Too large !!

12
Refining broker mBroker (1/2)

• Reduce broker to generic abstractions
• Express interactions with core services

Addressing
Activation
mBroker
Binding
Protocol
13
Refining broker mBroker (2/2)

• Introduce simpler abstractions
• Notionally equivalent to broker pattern

Addressing
Activation
mBroker
Binding
Job Queues
Protocol
Async. I/O
Async. I/O
Scheduler
14
How to verify the mBroker ?

• Specification of the mBroker
• Driven by external events parallelism

• Modeled using Petri nets
• Structural methods
• Model checking
• CASE tools available
• Assembly-like
• Computable properties
• Deadlocks, bounds
• Execution paths

class C is 1 .. 2 Domain D is ltC, Cgt Var
x, y in C
15
Modeling steps

• Define sub-models
• One per modeled function/entity
• Can be tested separately
• Build complete model
• Composition of sub-models
• Inherit some properties from sub-models
• Support for Broker verification
• Scenarios
• Specific Petri nets to model external
  interactions
• Incoming data, local user code

16
One modelTry_Check_Sources

• Monitors I/O sources
• 1 Poll on event sources
• ChckSrcB/ChckSrcE
• SigOut signals events
• 2 Process I/O
• Under mutual exclusion
• Build jobs event on s
• Queue jobs for processing

17
Properties inheritance benefit

• Instances inherit some properties from Neutral
  Core MW
• Enable verification of multiple instances
• .. at reduced cost

Instances
Neutral Core MW
Not verified
Not verified
Genericity
Verified
Verified
Configurability
18
Conclusion

• Requirements for new middleware
• Domain x Family space
• Middleware personalization verification
• Flexible architecture that separate concerns
• Aggressive code configurability and genericity
• to enable verification
• Are schizophrenic middleware one step forward
  in the good direction ?
• Configurability, genericity
• Prototyping of distribution middleware
• Formal verification of core components
• Requirements from para-functional elements ?