Fraunhofer CESE
Dharmalingam GanesanMikael Lindvall
1
NASA Goddard Space Flight Center
Lamont RuleyRobert WiegandVuong LyTina Tsui
Architectural Analysis of Systems based on the Publisher-Subscriber Style
© 2010 Fraunhofer USA, Inc. Center for Experimental Software Engineering
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
2© 2010 Fraunhofer USA, Inc. Center for Experimental Software Engineering
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
3© 2010 Fraunhofer USA, Inc. Center for Experimental Software Engineering
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
4© 2010 Fraunhofer USA, Inc. Center for Experimental Software Engineering
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
analysis5© 2010 Fraunhofer USA, Inc.
Center for Experimental Software Engineering
Elements of Software Bus
6© 2010 Fraunhofer USA, Inc.
Center for Experimental Software Engineering
Connection Management
Message Buffer
Management
SubscriptionManagement
Message Routing
Management
Interfaces forPublishing
and Subscribing
Typical elements we can expect in a software bus
Challenge is to locate corresponding code elements
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?
7© 2010 Fraunhofer USA, Inc. Center for Experimental Software Engineering
Static Analysis Strategies
8© 2010 Fraunhofer USA, Inc.
Center for Experimental Software Engineering
Middleware Vendor Class Name Method Name PurposeTibco Smart Sockets (SS) SSConnection SSConnection Initialize connection to the
middlewareTibco 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 messageApache Active MQ cms::MessageConsumer setMessageListener Subscribes to the given message
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
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-time9© 2010 Fraunhofer USA, Inc.
Center for Experimental Software Engineering
Dynamic Analysis - Overview
10© 2010 Fraunhofer USA, Inc.
Center for Experimental Software Engineering
System
Abstraction Builderusing CP-nets
GUI usingDyn-SAVE
Style Constraints Checkerusing CP-nets
Probes using static analysis
Run-time Events(e.g., Call Event)
published on the bus
Run-time Event Collector(RECO) component
This set-up enables online dynamic analysis needed for dynamically reconfigurable systems:
Architecture extraction and analysis can be performed at run-time
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
11© 2010 Fraunhofer USA, Inc. Center for Experimental Software Engineering
Mis
sions
GMSEC’s NASA and Other Government UsersOperational(since 2005)
In Development(2009)
Planned(ongoing meetings)
TRMMTRMM
SMEX SeriesSMEX Series
ST-5ST-5GLASTGLAST
SDOSDO
TerraTerra AquaAqua
AuraAura
GPMGPMMMOC(multiple)MMOC(multiple)
MMSMMS
Exte
rnal
NRONROAir ForceAir Force
Faci
litie
s and L
abs
FDFFDF
CSTLCSTL White SandsWhite Sands
ORSORS
ISS (MSFC)ISS (MSFC)
ClarreoClarreo
LRO-emLRO-em
Cx Const.of LabsCx Const.of Labs
GSFC ServerFarmGSFC ServerFarm
OTF (JSC)OTF (JSC)
HomelandSecurityHomelandSecurity
WFF RCCWFF RCC
KEY
Many missions depend on GMSEC! 12© 2010 Fraunhofer USA, Inc.
Center for Experimental Software Engineering
GMSEC and the Satellite Control Domain
13© 2010 Fraunhofer USA, Inc.
Center for Experimental Software Engineering
Avtec Systems
MSFC
DesignAMERICATLM/ CMDSystems
Planning &Scheduling
Front-Ends,
SimulatorsAnalysis &Trending
FlightDynamics
Message Bus via API
Situational Tools
TestTools
MonitoringTools
AutomationTools
TLM/ CMDSystems
Planning &Scheduling
Front-Ends,
SimulatorsAnalysis &Trending
FlightDynamics
Message Bus via API
Situational Tools
Situational Tools
TestToolsTestTools
MonitoringTools
MonitoringTools
AutomationTools
AutomationTools
Nearly all COTS command and control systems are GMSEC compatible
Missions expect that components behave as specified!
Structure of the GMSEC API
14© 2010 Fraunhofer USA, Inc.
Center for Experimental Software Engineering
ice
tibco_rv websphere7
soap
tibco_ss
GMSEC/Wrapper
mb activemq
ICE
ICEStorm
Tibco Rv
stdsoap2.h
ICEUtilTibco smart
sockets
External
socket.h
MQ Series
Active MQ
Connection Connection is an abstract interface
Publishers/Subscribers program to the abstract interface
All middleware APIs are wrapped
Binding to a selected wrapper using dynamic loading
Novel vendor independentmiddleware abstraction layer
Helps NASA’s missions to avoid vendor lock-in
This structure was discovered from code
Dynamic Analysis of the GMSEC
15© 2010 Fraunhofer USA, Inc.
Center for Experimental Software Engineering
Software Bus (for “real” messages)
CAT GREATGEDAT RECO…
Software Bus (for “trace” messages)
RECO collectsrun-time traces
RECO subscribesto trace 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
Discovered Views - sample
16© 2010 Fraunhofer USA, Inc.
Center for Experimental Software Engineering
Pid_7720(SA) Pid_7252 (CAT)
Pid_3804 (GEDAT)
Pid_4704 (CAT GUI)
Connection port for publishing to the software bus
Connection port for subscribing to the software bus
Pid_7024 (RECO)
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
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
17© 2010 Fraunhofer USA, Inc. Center for Experimental Software Engineering
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)18© 2010 Fraunhofer USA, Inc.
Center for Experimental Software Engineering
Acknowledgement
• Lisa Montgomery of the NASA IV & V
• Sally Godfrey of the NASA GSFC
• All members of the GMSEC team
19© 2010 Fraunhofer USA, Inc. Center for Experimental Software Engineering
Acronyms
• AFRL – Air Force Research Laboratory • APL – Applied Physics Laboratory• ARC – Ames Research Center• CESE – Center for Experimental Software
Engineering
20
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
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
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
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