This document discusses analyzing systems based on the publisher-subscriber architectural style. It describes analyzing a NASA system called GMSEC that uses this style. Static analysis is used to understand how components connect and communicate. Dynamic analysis involves monitoring a running system to understand behavior, such as which subscribers receive messages from which publishers. This analysis uncovered a high-priority bug and provided valuable insights into GMSEC.

1. Architectural Analysis of Systems based
on the Publisher-Subscriber Style
Fraunhofer CESE NASA Goddard Space Flight Center
Dharmalingam Ganesan Lamont Ruley
Mikael Lindvall Robert Wiegand
Vuong Ly
Tina Tsui
© 2010 Fraunhofer USA, Inc. 1
Center for Experimental Software Engineering

2. Background
• Architectural styles offer reusable
solutions to recurring design problems
• Architectural styles define:
– the roles of components and connectors
– the structure or topology
– the interaction behavior of involved elements
• Pipe-and-Filter, Publish-Subscribe, Client-
Server are some architectural styles
© 2010 Fraunhofer USA, Inc.
2
Center for Experimental Software Engineering

3. Model of Publish-Subscribe Style
• Components publish or subscribe to
messages with relevant subjects/topics
• Components communicate indirectly by
publishing and subscribing to messages
• Message delivery taken care by an
intermediate software bus
• Indirect communication increases flexibility
– ease of component substitution & integration
– attractive for developing a family of systems
© 2010 Fraunhofer USA, Inc.
3
Center for Experimental Software Engineering

4. Problem
• Increased flexibility of the pub-sub style
decreases analyzability
– difficult to extract dependencies among
components
– difficult to predict emerging behavior if several
components are using the bus
• E.g., timing problems, missed messages, etc.
• Need an approach for systematically
analyzing pub-sub style implementations
– NASA’s GMSEC is one example system
© 2010 Fraunhofer USA, Inc.
4
Center for Experimental Software Engineering

5. Approach
• Derive reusable analysis questions from
the definition of the style
• Structural questions are statically
answerable
• Behavioral questions are best answered
using dynamic analysis
– by monitoring the running system with
injected probes that generate runtime traces
• Static analysis is used to guide dynamic
analysis 5
© 2010 Fraunhofer USA, Inc.
Center for Experimental Software Engineering

6. Elements of Software Bus
Interfaces for
Connection Message
Publishing
Management Buffer
and
Management
Subscribing
Message
Subscription
Routing
Management
Management
 Typical elements we can expect in a software bus
 Challenge is to locate corresponding code elements
© 2010 Fraunhofer USA, Inc.
6
Center for Experimental Software Engineering

7. Analysis Questions from the Style
• Are there any middleware used for
implementing the software bus?
• If middleware is used, is there any
middleware abstraction layer?
• Can publishers and subscribers be
implemented in different programming
languages?
• Which subscribers receive messages
from which publishers and in what order?
© 2010 Fraunhofer USA, Inc.
7
Center for Experimental Software Engineering

8. Static Analysis Strategies
Goal of static analysis is to bridge the abstraction gap between
source code concepts and abstract elements of the software bus
Fraunhofer’s experience repository contains data about several
external entities (table – small excerpt for middleware technologies)
Build abstractions using dependencies to external entities
Middleware Vendor Class Name Method Name Purpose
Tibco Smart Sockets (SS) SSConnection SSConnection Initialize connection to the
middleware
Tibco SS SmartSockets::TipcSrv send Publishes the given message
Tibco SS SmartSockets::TipcSrv setSubscribe Subscribes to the given message
Apache Active MQ CMSConnection CMSConnection Initialize connection to the
middleware
Apache Active MQ cms::Session createProducer Publishes the given message
Apache Active MQ cms::MessageConsumer setMessageListener Subscribes to the given message
© 2010 Fraunhofer USA, Inc.
8
Center for Experimental Software Engineering

9. Dynamic Analysis Strategies
• Run-time traces are collected by
instrumentation using static analysis
• Each run-time event is treated as a
message
• Events of pub-sub style highly interleaved
• Construction of Colored Petri Nets (CP-
nets) for recognizing pre-planned patterns
• CP-nets produce the actual architecture at
run-time
© 2010 Fraunhofer USA, Inc.
9
Center for Experimental Software Engineering

10. Dynamic Analysis - Overview
GUI using
Dyn-SAVE
Style Constraints Checker
Abstraction Builder using CP-nets
using CP-nets
Run-time Events Run-time Event Collector
(e.g., Call Event) (RECO) component
published on the bus
Probes using
static analysis
System
 This set-up enables online dynamic analysis needed for
dynamically reconfigurable systems:
 Architecture extraction and analysis can be performed at run-time
© 2010 Fraunhofer USA, Inc.
10
Center for Experimental Software Engineering

11. Analysis of NASA’s GMSEC
• GMSEC API is a reusable framework for
missions inside and outside NASA
• Publishers/Subscribers can be
programmed in different languages
(C/C++, Java, Perl)
• Objectives of the analysis:
– Independent review of the implementation
quality
– Report structural and behavioral issues
© 2010 Fraunhofer USA, Inc.
11
Center for Experimental Software Engineering

12. GMSEC’s NASA and Other Government Users
Operational In Development Planned
KEY (since 2005) (2009) (ongoing meetings)
TRMM Terra Aqua
SMEX Series SDO Aura
Clarreo
ST-5
Missions
MMOC
GLAST (multiple)
GPM
ISS (MSFC) LRO-em MMS
CSTL White Sands
GSFC Server
Cx Const. Farm
and Labs
FDF
ExternalFacilities
of Labs
OTF (JSC) WFF RCC
Air Force NRO
Homeland
ORS Security
Many missions depend on GMSEC! © 2010 Fraunhofer USA, Inc.
12
Center for Experimental Software Engineering

13. GMSEC and the Satellite Control Domain
MSFC
Avtec Systems
DesignAMERICA
Front-Ends, Planning & TLM/CMD Flight Analysis &
Simulators Scheduling Systems Dynamics Trending
Message Bus via API
Test Monitoring Situational Automation
Tools Tools Tools Tools
Nearly all COTS command and control systems are GMSEC compatible
Missions expect that components behave as specified!
© 2010 Fraunhofer USA, Inc.
13
Center for Experimental Software Engineering

14. Structure of the GMSEC API
Connection  Connection is an abstract
interface
GMSEC/Wrapper
tibco_rv websphere7 tibco_ss Publishers/Subscribers
program to the abstract
ice mb soap activemq
interface
External MQ
Series
Active MQ  All middleware APIs are
wrapped
ICE socket.h stdsoap2.h
 Binding to a selected
ICEStorm
Tibco smart
ICEUtil Tibco Rv
sockets wrapper using dynamic loading
 Novel vendor independent
This structure was discovered from code
middleware abstraction layer
 Helps NASA’s missions to
avoid vendor lock-in
© 2010 Fraunhofer USA, Inc.
14
Center for Experimental Software Engineering

15. Dynamic Analysis of the GMSEC
Software Bus (for “trace” messages)
GEDAT CAT GREAT … RECO
RECO collects
run-time traces
RECO subscribes
to trace messages
Software Bus (for “real” messages)
 AspectJ was used to inject probe code into the bytecode of applications (bubbles)
 “Trace” messages and “real” messages are transmitted in different S/W bus
to avoid any communication conflicts
© 2010 Fraunhofer USA, Inc.
15
Center for Experimental Software Engineering

16. Discovered Views - sample
Pid_7024
(RECO)
Pid_7720(SA) Pid_7252 (CAT)
Pid_4704 (CAT GUI)
Pid_3804 (GEDAT)
Connection port for publishing to the software bus
Connection port for subscribing to the software bus
 Automatically extracted at run-time using CP-nets
 Developers found it useful to understand the actual run-time structure
 One “unexpected” connection was found
 This view is not statically extractable because connections are established
at run-time
© 2010 Fraunhofer USA, Inc.
16
Center for Experimental Software Engineering

17. Detection of a High-Priority Bug
• Our CP-nets detected a bug due to:
– inconsistency in the implementation of the
same interface by different middleware
wrappers
• One implementation allowed consecutive
calls to “subscribe” without an intermediate
“unsubscribe”
• Another implementation did not allow this
• Resulting in component substitution failure
© 2010 Fraunhofer USA, Inc.
17
Center for Experimental Software Engineering

18. Conclusion
• Style based analysis makes reverse
engineering focus and scalable
• Static analysis is used to:
– Bridge the abstraction gap with
implementation
– Identify code location to inject probes
• Dynamic analysis is used to discover
component-connector views
• Approach helped in finding a high-priority
bug (which is fixed now)
© 2010 Fraunhofer USA, Inc.
18
Center for Experimental Software Engineering

19. Acknowledgement
• Lisa Montgomery of the NASA IV & V
• Sally Godfrey of the NASA GSFC
• All members of the GMSEC team
© 2010 Fraunhofer USA, Inc.
19
Center for Experimental Software Engineering

20. Acronyms
• AFRL – Air Force Research Laboratory
• APL – Applied Physics Laboratory
• ARC – Ames Research Center
• CESE – Center for Experimental Software
Engineering
20

21. Acronyms (2)
• CHIPS - Cosmic Hot Interstellar Plasma
Spectrometer
• CLARREO - Climate Absolute Radiance
and Refractivity Observatory
• COTS – Commercial Off-The-Shelf
• DSILCAS – Distributed System Integrated
Lab Communications Adapter Set
• Dyn-SAVE – Dynamic SAVE
21

22. Acronyms (3)
• GLAST - Gamma-ray Large Area Space
Telescope
• GMSEC – Goddard Mission Services
Evolution Center
• GOTS – Government Off-The-Shelf
• GPM - Global Precipitation Measurement
• GSFC – Goddard Space Flight Center
• IV& V – Independent V & V
22

23. Acronyms (4)
• JSC – Johnson Space Center
• LADEE - Lunar Atmosphere and Dust
Environment Explorer
• LDCM - Landsat Data Continuity Mission
• LRC - Langley Research Center
• LRO - Lunar Reconnaissance Orbiter
• MMOC – Multi-Mission Operations Center
• MMS - Magnetospheric MultiScale
23

24. Acronyms (5)
• MSFC - Marshall Space Flight Center
• RBSP – Radiation Belt Storm Probes
• SAVE – Software Architecture
Visualization and Evaluation
• SDO – Solar Dynamics Observatory
• TRMM – Tropical Rainfall Measuring
Mission
• V & V – Verification and Validation
24