Model Checking Publish-Subscribe Software Architectures

1. Model Checking Publish-Subscribe Software Architectures David Garlan Carnegie Mellon University

2. Research Approach • Specification and analysis of software architectures • Components and their interactions • Architectural styles (e.g., client-server, pipe-filter, publish-subscribe) • Architectural frameworks (e.g. for specific domains and product lines) • Why? • Architectural design is a critical design artifact • Can explore system properties before implementation • A good level of abstraction for reasoning about system properties -- especially quality attributes • State of arch practice is informal - needs formalism • Amortized effort when architecture used by many systems

3. Specific Thrusts • Past research • Specification languages for software architecture • Wright -- based on CSP • Analysis of specific architectural frameworks • High-level architecture for distributed simulation • Enterprise JavaBeans • JavaPhone • Tools for software architects • Current research • Specification and analysis of publish-subscribe software architectures (today’s talk) • Compositional mechanisms for component interactions • Self-configuring systems

4. Publish-Subscribe Architectures • An architectural style • components: objects, processes, functions • connectors:event registration • computational model:event announcement triggers invocation of the zero or more methods/tasks that are registered for that event • Features • Anonymous multi-cast supports decoupling between components • Hence easy to modify and maintain • Widely used • UIs, Prog envts, JavaBeans, Visual Basic, JINI, CORBA, robots • Many variants • synch/asynch, dispatch policies, concurrency, shared state

5. Set Counter RTI … Sim1 Simn Examples • Set-Counter • Set (S) has operations insert/delete • Counter (C) has operations inc/dec • Establish “invariant” |S| = C • Distributed Simulation (HLA) • Arbitrary number of simulations publish values of objects that they simulate • Run-time infrastructure (RTI) maintains state (e.g.,ownership of objects), mediates protocols of interaction • Many invariants (e.g., each object is owned by a single simulation)

6. Sensor/ActuatorVariables Comp1 Comp2 Shared Variables Task1,1 Taskn,1 Task1,2 Taskn,2 Taskn,3 More Examples (State-based duals) • Shared-variable triggered systems • Aka “continuous query” systems • State changes trigger computations • Components read/write shared variables, but are otherwise independent • Real-time periodic tasks • Tasks placed in periodically-scheduled buckets • Tasks consume values of certain variables; produce values of other variables • Tasks within bucket must completebefore bucket period

7. Pub-Sub Systems are Hard to Reason About • Burden of correctness falls to system integrator • Lots of inherent non-determinism • Order of invocation of multiple event recipients • In-transit events • Non-determinism in “dispatch” mechanism • Questions that are hard to answer • What do we want to say about such systems? What’s an “invariant”? • Do the components announce the events that they should announce? • What will be the effect of announcing a particular event? • Are there the correct event subscriptions? • If a new component is added, will it break what is already there?

8. Technical Approach - Foundations • Key ideas • Events have semantics • Explicit specification of non-interference conditions • Compositionality via component environmentspecn • Rely-guarantee verification framework • Joint work with Juergen Dingel, Somesh Jha [Din98b] • Based on Jones rely-guarantee approach • Results: It works, but is hard to use, and often requires stronger invariants than are necessary • Temporal logic verification framework • Explicit modeling of dispatcher [Din98a] • Properties expressed in LTL • Results: Properties are more naturally expressed

9. Technical Approach - Tools • Features • Based on (LTL) foundations mentioned earlier • Specifications translated to Cadence SMV Model Checker input • Attempts to reduce cost of (a) building a system model and (b) specifying the properties to check • Provides a Parameterized Model Generator • Supports certain Built-in Checks • Currently in early stages of development and experimentation

10. Parameterized Model Generator • Generate most of the run-time event delivery and dispatch mechanisms • Greatly reduce cost of constructing model for pub-sub systems • Support common dispatcher alternatives • Allow easy exploration of alternatives • Delivery options • Asynchronous: immediate return from announcement • Synchronous: return after event completely processed • Concurrency options • Single thread per component • Multiple threads per component • Dispatch order • FCFS, Prioritized, Lossy, etc.

11. Interface Comp 1 Interface Comp N Model Architecture Environment (external event source) Event Announcement DeliveryPolicy Dispatcher Data Exchange Event Delivery … Shared state

12. Environment (external event source) Event Announcement DeliveryPolicy Dispatcher Data Exchange Event Delivery Interface Comp 1 Interface Comp N … Shared state Shared

13. Built-in Checks • Provide many of the common sanity checks • Move towards push-button tools • Special cases • Model-view topology • UI event model • Idempotent systems • Procedure call pairs • General consistency/completeness checks • Components respect event semantics • Events that are published, but not subscribed to • Events that are subscribed to, but not published • Liveness properties • Race conditions

14. C1 D1 C2 D2 Bridge Next Steps(and opportunities for collaboration) • Tool development • More built-in checks, parameterization options • Alternative model-checker substrates • Applications • Realistic problems • Pub-sub “bridges” • Current plan is to work on part of NASA remote agent architecture • Better linkage to code • Auto generation of component models? • Counterexample explanation • New specification capabilities • Dynamism, timing, real-time

15. More information • ABLE Project web site: www.cs.cmu.edu/~able • Papers: [All98] Formal Modeling and Analysis of the HLA Component Integration Standard. R. Allen, D. Garlan, and J. Ivers. Proc of the 6th International Symposium on the Foundations of Software Engineering (FSE-6), Nov 1998. [Din 98a] Reasoning About Implicit Invocation. J. Dingel, D. Garlan, S. Jha, and D. Notkin. Proc of of the Sixth International Symposium on the Foundations of Software Engineering (FSE-6), Nov 1998. [Din 98b] Towards a Formal Treatment of Implicit Invocation using Rely/Guarantee Reasoning," J. Dingel, D. Garlan, S. Jha, and D. Notkin. Formal Aspects of Computing 10, 1998.