Architecture Analysis of Systems based on Publish-Subscribe Systems


Published on

  • Be the first to comment

  • Be the first to like this

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

Architecture Analysis of Systems based on Publish-Subscribe Systems

  1. 1. Architectural Analysis of Systems based on the Publisher-Subscriber StyleFraunhofer CESE NASA Goddard Space Flight CenterDharmalingam Ganesan Lamont RuleyMikael Lindvall Robert Wiegand Vuong Ly Tina Tsui © 2010 Fraunhofer USA, Inc. 1 Center for Experimental Software Engineering
  2. 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. 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. 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. 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. 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. 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. 8. Static Analysis StrategiesGoal of static analysis is to bridge the abstraction gap betweensource code concepts and abstract elements of the software busFraunhofer’s experience repository contains data about severalexternal 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. 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. 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 fordynamically reconfigurable systems:  Architecture extraction and analysis can be performed at run-time © 2010 Fraunhofer USA, Inc. 10 Center for Experimental Software Engineering
  11. 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. 12. GMSEC’s NASA and Other Government Users Operational In Development PlannedKEY (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. 13. GMSEC and the Satellite Control Domain MSFC Avtec Systems DesignAMERICAFront-Ends, Planning & TLM/CMD Flight Analysis &Simulators Scheduling Systems Dynamics Trending Message Bus via API Test Monitoring Situational Automation Tools Tools Tools ToolsNearly all COTS command and control systems are GMSEC compatibleMissions expect that components behave as specified! © 2010 Fraunhofer USA, Inc. 13 Center for Experimental Software Engineering
  14. 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 independentThis 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. 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. 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. 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. 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. 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. 20. Acronyms• AFRL – Air Force Research Laboratory• APL – Applied Physics Laboratory• ARC – Ames Research Center• CESE – Center for Experimental Software Engineering 20
  21. 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. 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. 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. 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