Architectural Analysis of Systems based on the Publisher-Subscriber Style

Dharrnalingam Ganesan, Mikael LindvallF°aunhofer° CESE, College Park, Maryland

{dganesan, mlindvall)Wc-md.umd.edu

Abstract

Architectural styles impose constraints on both thetopology and the interaction behavior of involvedparties. In this paper, we propose an approach foranalyzing implemented systems based on the publisher-subscriber architectural style. From the style definition,we derive a set of reusable questions and show thatsome of them can be answered statically whereas othersare best answered rasing dynamic analysis. The paperexplains how the results of static anal ysis can be used toorchestrate dynamic analysis. The proposed method wassuccessfully applied on the NASA's Goddard MissionServices Evolution Center (GMSEC) software productline. The results show that the GMSEC has a) a novelreusable vendor-independent middleware abstractionlayer- that allows the NASA's missions to configure themiddleware of interest without changing the publishers'or subscribers' source code, and b) some high prioritybugs due to behavioral discrepancies, which wereeluded during testing and code reviews, among differentimplementations of the same APIs for- different vendors.

Keywords: Architectural Styles, Middleware, Vendors,Static and Dynanuc Analysis, Component-ConnectorViews, Colored Petri Nets.

1 Introduction

Architectural styles are abstract "high-level" conceptsoffering reusable solutions to recurring design problems.Equivalently, architectural styles define the roles, thetopology, and the interaction behavior of involvedcomponents [20]. The publisher-subscriber architecturalstyle is one of the most prominent styles, in whichdifferent components communicate in an indirectfashion by publishing and subscribin g to messagesmanaged by an intermediate communication bus (orbroker) [3]. This indirect connnunication makes thearchitecture flexible because it facilitates adding andremoving components. This style is thus an attractiveoption, for example, when one wants to develop afamily of similar products in a disciplined way. Forexample, in a previous case study [6], we reported thatthe NASA's flight software product line was developed

Lamont Ruley, Robert Wiegand, Vuong Ly,Tina Tsui

NASA Goddard Space Flight Center,Greenbelt, Maryland

{ lamont.t.ruley, robert. e. wiegand,Vuong.T.Ly, Tina.Tsuil@nasa.gov

in a flexible way by adding or removingpublisher/subscribers, based on the needs of missions.

However, this increased flexibility of the publisher-subscriber architectural style is also a curse because itmakes it difficult to predict the emerging behavior andto prove the correctness of the integrated system eventhough each individual component passed testing andwas demonstrated to be correct on its own. Thus, whileflexibility increased, analyzability decreased. Oneexample of problems that cannot be detected byanalyzing individual components is inter-componentoriented timing issues. Such issues emerge only whenseveral components are using the bus.

Several researchers have analyzed the publisher-subscriber architectural style at an early stage (i.e.,before the implementation) (e.g. [8, 9]). They constructrigorous fornial models of the publisher-subscriber styleand prove correctness using model-checking techniques.Unfortunately, many existing systems were developedwithout such a rigorous architectural phase. Also, evenif there was such a phase, experience reminds us that theimplementation could deviate from the specifiedarchitecture (e. g ., [16, 7]). Therefore, it is instructive toreverse engineer the implemented architecture andanalyze the behavioral properties and constraints of thepublisher-subscriber style.

We developed a practical approach for analyzingimplementations based on the publisher-subscriber style.Our key activity is to derive a set of reusable questionsfrom the definition of the style. These questions drivethe analysis and the answers to them constitute evidenceregarding the compliance of the implementation to thestyle constraints and overall design quality. We willshow that some questions are possible to answerstatically, whereas others are better answered bymonitoring the running system. In the static analysisphase, we bridge the gap between "high-level" conceptssuch as publish, subscribe, unsubscribe, andcomnnunication bus, and the source code concepts. Thatis, we locate key interfaces, methods, and data structuresused for implementing the publisher-subscriber style.Our static analysis is guided by analyzing dependenciesto external entities (e.g., Middleware vendors' APIs andprogranuning language libraries) which are stored in our

https://ntrs.nasa.gov/search.jsp?R=20100031707 2020-07-22T08:40:45+00:00Z

experience repository, based on more than 10 years ofanalysis of several commercial systems at Fraunhofer.

In order to conduct complementary dynamic analysis,we use the results of the static analysis to a) define andautomatically insert probes at the right location forcollecting run-time events (e.g., call events), and b) storeand/or forward run-time events to various tools that weuse to analyze data. Our technical set-up for dynamicanalysis takes advantage of the publisher-subscriberstyle by introducing a run-time event collectorcomponent (RECD) into the software architecture. Ourprobes emit run-time events as messages into thecommunication bus, which deliver them to the RECD.In a sense, dynamic analysis is seamlessly integratedinto the publisher-subscriber style. By monitoring therunning system, we interpret the run-time events fordiscovering a) component-connector (C-C) views of thepublisher-subscriber style including components, portsand connections between ports as well as b) sequencediagrams including messages exchanged betweendifferent components indirectly using the intermediatebus or directly between components with the bushidden. We also discuss how we detect violations ofbehavioral style properties. Our dynamic analysis isfacilitated by the construction of Colored Petri Nets(CP-nets) [4]. CP-nets are useful for recognizing pre-planned patterns in interleaved events. We used CP-netsbecause run-time events of a publisher-subscriberarchitectural style are highly interleaved. For example,when one component is emitting subscribe events theother component could be in the middle of creating aconnection to the communication bus.

The system under study is NASA's GMSEC system,whose team has developed a software product line basedon the publisher-subscriber architectural style. Theproposed approach was followed for an independentanalysis of the GMSEC implementation. We discovereda) a middleware abstraction layer that offers vendors'independent abstract interfaces to interact with thecommunication bus of different vendors, b) C-C views,c) sequence dia grams, and d) some behavioral violationsresultin g in hi gh-priority bugs due to inconsistenciesbetween the implementations of the same interface fordifferent vendors.Contributions of the paper: We have found littlediscussion on the topic of analyzing structure andbehavioral constraints of architectural styles in thereverse engineering community. To this end, we hopethe paper contributes the following:1. A practical approach for analyzing the publisher-

subscriber style using a combination of static anddynamic analysis. The technical set-up and analysisquestions are also reusable on other systems basedon the same style.

2. The reverse engineered GMSEC architecture is alsoreusable, offering novel insights on how to design

and implement middleware abstraction layer, whichfrees organizations from being vendor-locked.

2. Approach

In this section, we will introduce the "high-level"concepts of the publisher-subscriber style, which will beused to derive a set of questions for the architectureanalysis. In order to answer the questions, we willpresent the approach for discovering a set of views,using both the static and dynamic analysis.

2.1. Concepts of the Publisher-Subscriber Style

In the Publisher-Subscriber style, each participant canplay the role of a publisher of message, a subscriber ofmessages, or both. Messages are key entities in thisstyle. Typically, each message has a subject (a.k.a.topic) as well as a structure containing a number offields and values that carry the data to be sent [3]. Thecentral artifact is the broker or the bus (a.k.a. softwarebus). A typical bus has elements for connectionmanagement, subscription management, message bufferand routing management, as well as interfaces forpublishing and subscribing, as shown in Figure 1. Theconnection management is used by thepublishers/subscribers for connecting to anddisconnecting from the bus. Subscribers use theinterfaces of the bus to subscribe to messages of interest.Similarly, publishers use the interfaces of the bus topublish messages, which are stored in an internal buffer,often created and managed by the software bus [3]. Thesubscription management is used by the bus to managethe list of subscribers. One important job of the bus is toroute the messages to appropriate subscribers, thus itneeds to have message routing management concepts.Note that the bus can also play a role of publisher and/orsubscribers by using its own interfaces.

There are several implementations of software buseson the market; typically based on middleware. Systemsthat make use of a middleware may want to hide/wrapand even generalize the interfaces of the middleware inorder to avoid being dependent on a particularmiddleware from a particular vendor. To provide trueflexibility, the programming language used toimplement the bus should not dictate the programminglanguage to be used by the subscribers and publishers.

Connection Message Buffer InterfacesforMana gement Management Rib lishulaand

SubscRbinSubscliption MessageRouting

Mana gement Manaaenlent

Figure 1 Typical elements of a software bus

2.2. Deri-,ping Analysis Questions from the StyleIn order to understand and assess the implementation ofsystems based on the publisher-subscriber style, we nowderive a set of typical questions based on the high-levelconcepts of this style, introduced above.

1. Are there any middleware used for implementing asoftware bus?

2. If middleware is used, is there any middlewareabstraction layer that hides the knowledge of aparticular middleware API?

3. Can publishers and subscribers be implemented indifferent progratiutung languages? If yes; how arethe variants in the languages managed?

4. Can publishers and subscribers come-and-godynamically at nin-time?

5. Can publishers, subscribers, and the software busrun on different machines?

6. Which subscribers receive messages from whichpublishers and in what order?

7. Do subscribers receive messages that are notsubscribed by them?

8. Can subscribers subscribe to the same messagemore than once without an intermediateunsubscribe?

9. Can subscribers unsubscribe to messages that arenot subscribed by them?

10. Are there timing delays in delivering messages tosubscribers?

The above set of questions is concerned with both thestructural and the behavioral aspects ofimplementations. For instance, questions 1-5 deal withthe module-structure of the system, whereas questions 6-10 deal with behaviors. Therefore, our approach has astatic and a dynamic analysis phase. In the staticanalysis phase, we discover key header files, classes,interfaces, and routines related to the software busconcepts. In addition, we create "box-and-lines" viewsof modules related to the software bus concepts that wehave discovered. In the dynamic analysis phase, we usethe results from the static analysis in order to a) createprobes that monitor the running system, and b) forpattern recognition of run-time events. The data fromthe probes is used to discover components andconnectors and are documented as component-connectorviews and sequence diagrams. The discoveredrelationships depicted in component-connector viewsoffer insights related to the run-time structure of thesoftware, which are difficult to obtain using staticanalysis techniques. The views are used to understandthe implemented architecture and to draw conclusionson the systems' implementation quality. Now, weexplain how we perform static and dynamic analysis toanswer these questions.

2.3. Static Analysis StrategiesOur goal of the static analysis step is to locate "high-level" concepts of the publisher-subscriber style in thesource code. We automatically extract dependencymodels (e.g., include relations, call relations) from thesource code and analyze them semi-automatically. Ourstatic analysis strategy is based on observations thatsystems typically do not implement the publisher-subscriber style from scratch; instead they build on topof external entities such as middleware frameworksoffered by cotntnercial or open source vendors.

For the analysis, we use a set of tools and otherresources that have been developed during the past 10years at Fraunhofer. For example, we stored the namesof header files, classes, and methods/functions offrameworks and progratmning language libraries that arearchitecturally-significant for each architectural style.For example, Table 1 shows a small snippet of thestored data for two middleware vendors, namely theTibco and the Apache Active MQ. We store this data ina relation database model, and use it in conjunction withdependency models in order to locate the files that areinvolved in the implementation of the software busconcept. For querying the dependency model, we use therelation partition algebra (RPA) [5]. The search result isused to a) discover the presence of any abstractionlayers or wrappers to such vendor libraries, and b) detectpotential architecture issues. For example, if the systemunder study uses vendor libraries directly without anyintermediate wrappers then it indicates a potentialdesign issue, because the system is now vendor-locked,impeding switching to another vendor's solution.

Table 1 an excerpt of middleware vendors' APIs.

Vendor Method Name PurposeTibco SSConnection::SSConnection InitializesSmart connection toSockets the(SS) middlewareTibco SS SntartSockets::TipcSrv::send Publishes the

eiven messageTibco SS SntartSockets::TipcSrv::setStibscribe Subscribes to

the givenmesa e

Apache CMSCrntuection::CMSConnection InitializeActive connection toMQ the

middlewareApache erns:: Session::createProducer Publishes theActive eiven messageMQApache ciiis::MessageCoiisumer::setMessageLi Subscribes toActive stener the givenMQ I message

In order to reason about how the system handlesprogramming language variants, we locate dependenciesto common header files and trace backwards. Forexample, JNI [ 15] and XS [ 14] are respectively used for

communication between Java to C++, and Perl to C++.Using this knowledge, we can locate files that aredealing with more than one programming language. Weattempt to understand how the language-to-languagetranslation is separated from other concerns.

We also keep track of typical variable and routinenames developers use for implementing differentarchitectural styles of systems. For example, in aprevious case study, programmers used "publish","subscribe", "sendMsg", "rcvMsg", and "unsubscribe"to implement the publisher subscriber style in the Clanguage [6]. We use these sets of keywords to searchthe code base and/or the extracted dependency models torecognize the presence of potential architectural styles inthe source code. To facilitate searching, we developed arobust implementation of the vector space model ; basedon [18]. which allows us to search the source code baseand outputs a ranked list of files similar to a given list ofsuch keywords. This search technology also facilitatesthe static analysis of systems that support differentprogramming languages for implementing the publisherand subscriber style. For example, we can select theJava implementation of the software bus and request forfiles "similar" to the given set of files, which mightimplement the software bus for other prograrnrninglanguages.

We stop the static analysis after getting answers toquestions 1-5. Since discovery is an iterative process, weoften conduct more static analysis as dynamic analysisraises new questions. The output of the static analysis isthe discovery of the presence (or absence) of significantcomponents as well as key header filers and/orinterfaces corresponding to the "high-level" conceptsshown in Figure 1. This output feeds into the dynamicanalysis activities.

2.4. Dynamic Analysis Strategies

Our goal of the dynamic analysis is twofold. First, todiscover components and connectors in theimplementation, and create corresponding component-connector views of the publisher-subscriber style.Second, to create sequence diagrams, showing messagesexchanged among the publishers and subscribers,including the support for hiding the intermediatesoftware bus. We need dynamic analysis because a)there is an inherent dynamism in the publisher-subscriber style, meaning that publishers/subscribers canconnect and disconnect as each individual componentfeels necessary. Thus, the actual architecturalconfiguration of the system is often only known at run-time, and b) questions related to ordering of messagesand timing are not easy to answer statically, if notimpossible. The correctness of systems based on thepublisher-subscriber style depends on the correctfunctioning of the software bus, and also depends on the

publishers and subscribers using the software bus in theright way. A misbehaving component could easilyprevent it from functioning properly.

In several cases, we observed that the software busand the publisher/subscribers are developed by differentteams, who may even belong to different organizations.Thus the developers never meet in person and buildcomponents solely based on interface control documentsand similar information. Therefore, it is often notpossible to statically check the correctness of thebehavior of the resulting system, and verify that thepublishers/subscribers and software bus are all "safe".Thus, we need to monitor the running system and beable to check the correctness at run-time so thatconstructive actions can be taken. For example,notifying the misbehaviors for further investigations bysystem administrators, triggering requests for removingmisbehaving parties, etc.

Now, we will enumerate a few key challenges relatedto such analysis and how we address them in dynamicanalysis of the publisher-subscriber style.

First, in order to minimize both the overhead ofinjected monitoring code and the amount of run-timedata, we need to locate the right spots where the soughtfor data can be collected. We address this challenge byinserting probes that monitor the usages of the interfacesof the software bus that were discovered using staticanalysis. Depending on the context factors (e.g.,software architecture, programming languages, andorganizational boundaries), we choose the mostappropriate instrumentation strategy for defining andinserting probes. In [7], we used run-time weaving usingAspect-J for Ricoh's photocopy machine. In the contextof the publisher-subscriber style, we can design probesto emit run-time events, as messages with the specialsubject "trace", into the software bus itself.

Second, we need to collect the emitted run-timeevents and forward them to analyzers. In our approach,we introduce and integrate a special component calledthe Run-time Event Collector (RECO) into thepublisher-subscriber architecture, which subscribes to allmessages with "trace" as the subject.

Third, we need to systematically handle interleavedrun-time events of the publishers and subscribers fordiscovering component-connector views and sequencediagrams. For instance, when one publisher is in theprocess of creating a connection to the software bus,another subscriber might already have subscribed toanother or the same message, and at the same moment,another subscriber mi ght be waiting for other set ofmessages to come in. Note that publishers andsubscribers could run on different machines, processesand threads. As a consequence, the emitted run-timeevents are highly interleaved and difficult to analyze.

We tackle the challenge of analyzing interleavedevents by using Colored Petri Nets (CP-nets), which are

shown to be a useful executable formal language forhandling asynchronous systems behavior [4]. CP-netsare well-elaborated in [7]. Basically, a CP-net is a graphwith two types of nodes called places and transitions.Tokens are entities with data attributes/fields, associatedwith places. Each transition can have one or more inputplaces and one or more output places. Every transitionhas a precondition which is a Boolean expressionassociated with input places. A transition fires if there isat least one token in each of the input places that satisfythe precondition. If a transition fires, it removes oneinput token from each of the input places. Everytransition has an action, which is a sequence ofassignment statements that assign tokens to outputplaces when transition fires. We developed a prototypeimplementation of CP-nets that is described in [ 12].

Based on the publisher-subscriber style and itsimplementation concepts, which was discovered duringstatic analysis, we constructed CP-nets that process theincoming run-time events and recognize pre-plannedpatterns, and produce the data necessary for constructingC-C views and sequence diagrams. By pre-plannedpatterns, we mean the implementation constructscorresponding to architectural constructs. For example;calls to the "publish" method of the Connection classcorrespond to the abstract publishing concept in thestyle. The output of CP-nets is used to visualize both C-C views and sequence diagrams that hide the softwarebus. If we do not hide the software bus, allconununication will be between a component and thesoftware bus. We developed Dyn-SAVE toautomatically create and visualize sequence diagramsbased on output from such CP-nets [1 31.

It is worth noting that CP-nets run in parallel to thesystem under study and analyses the run-time events atrun-time. Thus, it is a novel formalism for buildingarchitectural monitoring and compliance checking atrun-time for dynamically reconfigurable systems. In ourapproach, we also use CP-nets for checking behavioralconstraints at run-time. For example, we can checkwhether a subscriber receives any message other thanwhat was subscribed as follows: One transition of theCP-net can wait for subscribed events and output, to oneof its output places, the list of subscribed messages bysubscribers. The second transition of the CP-net canwait for events that read messages from the software busto occur, and output, to one of its output places, the listof messages read by each subscriber. The third transitionof the CP-net, designed to consume the output of theabove two transitions, can output to its one of the outputplaces, the list of unwanted messages wrongly routed bythe software bus. Figure 2 summarizes the conceptualelements of our dynamic analysis environnnent foranalyzing systems based on the publisher-subscriberstyle. It is worth noting that the RECO component is infact plugged into the running system — just like other

components — probes can also be injected into theRECO component in order to make sure this tracecollection component uses the software bus in the rightway.

GUI -mgDyn-SAVE

stv_ le Constraints Checker

Abstraction Builder usntg CP-nets

using CP-nets

Ruu-tune Events Bnn-time;went^¢]kctor

(e. g., Call Event) (RECO) component.nblished on the bus

Probes usingstatic analysis

System0

Figure 2 Conceptual Elements of Dynamic Analysis.Arrows denote the direction of data flow.

3. Analysis of the NASA's GMSEC

3.1. Objectives of the Case StudyThe NASA's GMSEC branch has developed theGMSEC software architectures as a reusable frameworkfor missions inside and outside the NASA. In addition totheir rigorous reviews and testing, they also prefer anindependent organization to review the implementationquality, and report to them architecture/design issues aswell as behavioral problems that could lead to failures.

3.2. General Process for the AnalysisIn the first part of the analysis, the NASA's GMSECteam provided the GMSEC framework 2.6 as well assome example applications that illustrate the publisher-subscriber architectural style. The Fraunhofer team thenanalyzed this version statically from the point of view ofproduct lines and software architectures. This analysisled us to understand the implemented softwarearchitecture of the GMSEC framework. After theanalysis, the Fraunhofer team presented the discoveredarchitectural issues to the GMSEC team, whichaddressed some of the high-priority issues in versions3.0 and 3.1. The GMSEC team then provided the 3.1version and a set of real applications for analysis. TheFraunhofer team set up a test-bed for running andperforming dynamic analysis of the GMSEC, whichadded to the results in this paper. This fruitful process,which is supported by NASA IV&V's SoftwareAssurance Research Program (SARP), has been going-on for a year.

3.3. Static Analysis of the GMSECThe GMSEC source code contains several programminglanguages (C, C++, Java, and some Perl). We extracted

code-level dependency models (e.g., include, import,call relations) and stored them as binary relations forquerying using the RPA. We briefly explain how thedependency models were used to discover the softwarebus and the middleware abstraction layer in GMSEC.

Our approach was a combination of bottom-up andtop-down strategies. Recall that we stored a list ofmiddleware frameworks and the names of header files,classes, function/methods that deal with concept such asconnecting to the middleware, sending, and receivingmessages, etc., (see Table 1). In the bottom-up strategy,we queried the dependency models for all usages ofcornrnercial middleware frameworks and sockets. Thisled us to locate the directories and files of the GMSECframework that implement the concepts of the publisher-subscriber style. We lifted the file-level dependencies todirectory-level dependencies using the RPA's liftoperator. Our conclusion is that the GMSEC frameworkhas a clean implementation that separates the concernsof using and supporting several conunercial nddlewarefrom providing software bus services to subscribers andpublishers. The separation of concerns is implementedusing a set of wrappers, one for each externalmiddleware framework, as well as for the standardsocket library. Each wrapper provides the same set ofservices to publishers and subscribers, thus hiding thedifferences between different rniddlewares. Thus, usagesof external vendors' libraries are only allowed through awrapper. For example, the ICE (Internet CommunicationEngine) is a commercial middleware that offers APIs fordeveloping systems based on the publisher-subscriberstyle. The GMSEC framework offers a wrapper calledice that accesses the ICE APIs. All vendor librariessupported by the GMSEC framework are wrapped in thesame way, see Figure 3.

Connection

GMSEC/Wrapper

ti bco_ry I I websphere7 I I tibco_ss

ice I I mb I I I soap I I activemq

External I I MQSeries 1 1 Active MQ

ICE I I socket.h I I stdsoap2.h

ICEStorm

ICEUtiI I I 7bco Rv II Tibcosmart

Figure 3 A slice of the GMSEC from the viewpoint ofdependencies to external middleware and socket

libraries. Boxes are directories (except socket.h andstdsoap2.h and Connection). Arrows denote thedirection of module dependencies. The filled arrowdenotes that each module within the wrapper folderifflierits from the Connection class, which offersinterfaces for publishing, subscribing, etc.

All wrappers are fully implemented in C++. Eachwrapper inherits from the abstract base class calledConnection which contains interfaces for connecting tothe middleware, publishing, subscribing, etc. In additionto commercial middleware, the GMSEC team alsoimplemented their own middleware, which is called thesoftvi^are message bits (inb); based on standard sockets.We queried the dependency models to understand whouses each wrapper of the middleware vendors, whichshowed that there are no static dependencies to thewrapper folder. In order to understand this design, wealso used a top-down strategy using the simple exampleapplications offered as part of the GMSEC distribution.The examples clarified that there is a class calledConnectionFactory, which is responsible fordynamically loading the wrapper of a vendor at run-timebased on configuration settings. The build process of thewrapper showed that there is a dynamically loadedlibrary (dll) for each vendor. For example, the wrapperimplementation of the ActiveMq middleware iscompiled into gmsec_activemq.dll for Windows, andgmsee_activemq.so for Linux. The source code of theConnectionFactory class revealed that each wrapperimplements standardized interfaces (e.g.,CreateConnection), which are called by theConnectionFactory at run-time to initialize the wrapperby loading the corresponding dll. The CreateConnectionmethod of the loaded dll creates an instance of thecorresponding nvddleware's connection class.

As discussed above, the core of the GMSEC isimplemented in C++. However, the GMSEC alsosupports other publishers and subscribers beingimplemented in lan guages such as C, Java. and Perl. Weanalyzed the implementation of the core in order tounderstand how it handles variability due toprogramming languages. We used our text-basedsimilarity tool for this purpose, and it revealed that thereis an equivalent of Connection and ConnectionFactoryclass for each progrannning language. This was possibleto discover automatically because the GMSEC teamused the same method, variable names, and signatures inall prograrnrning languages. Since the GMSEC uses the` jni.h" file, which supports connnunication betweenJava and C++, it became clear that all calls to the Javaimplementation of the Connection, ConnectionFactoryare redirected to respective C++ method calls using JNI[15]. Similarly, all calls to the Perl version of theConnection, ConnectionFactory are redirected to C++method calls using the XS Perl to C++ interface [14].

To sum up the results from the static analysis, anattractive aspect of the GMSEC framework is thatflexibility is built into the architecture, meaning that a)missions can easily add new middleware vendor of theirinterest by inheriting and implementing the abstract baseclass (Connection), b) missions can switch betweendifferent middleware using configuration settings andwithout changing the source code; the

ConnectionFactory class will take care of loading andbinding to the selected middleware wrapper, c)applications (i.e., publishers/subscribers) are agnostic tomiddleware vendor's API because they program to thevendor independent abstract base class, d) applicationscan be programmed in different languages, and e)applications can freely enter at run-time by connectingto the runningring software bus. From the static analysis, weunderstood the structure of the GMSEC, key interfaces,and classes involved in the publisher-subscriber style.We will now use this knowledge to analyze behavioralaspects of the style using dynamic analysis_

3.4. Dynamic Analysis of the GMSECDuring the static analysis, we observed thatdependencies among applications of the GMSEC areimpossible to extract statically because allcommunication is indirect using the intermediatesoftware bus using middleware. Thus, it is difficult todetermine exactly which application sends and receivesmessages. Therefore, we also conducted dynamicanalysis, and customize Figure 2 to the GMSEC.

3.4.1. Defining Probes of the GMSEC ApplicationAll "real" applications given to us are implemented inJava. Therefore, we have chosen AspectJ as thelanguage for inserting probes [11]. Because the staticanalysis showed us that the Connection class is the coreclass for connecting to the middleware, publishing,subscribing messages, etc., we injected probes beforeand after the invocation of the methods of theConnection class in each application. We insertedprobes "before" and "after" so that a) we could calculatethe execution time of each method, and b) we couldcapture parameter values, which mi ght be updated dueto call-by-reference. We weaved our probes into thecompiled binary class files of the GMSEC applications,which use the framework. Our probes emit run-timeevents as messages (with subjects "trace -before" or"trace. after") using the APIs of the Connection class,resulting in the publication of nm-time events usin g thesoftware bus itself It is worth noting that we can useany middleware, for example a middleware, differentfrom the one used for publishing/subscribing "real"messages, to send out trace messages. We use differentmiddleware for "trace" and "real" messages in order toavoid any communication conflicts, see Figure 4.

3.4.2. Developing the RECO componentWe developed the RECO component using the GMSECAPIs, and thus it can be plugged into the GMSEC run-time environment like any other GMSEC compliantapplication. The RECO plays the role of a subscriber bysubscribing to all messages with the subject"trace.before" or "trace. after". One precondition for theRECO component is that it should use the samemiddleware that was used by the probes, otherwise, thetrace messages will not be delivered to it by the GMSECsoftware bus (see Figure 4). We nm the RECOcomponent in monitoring mode in order to verify that itfollows the behavioral constraints of the publisher-subscriber style and that it works well with allconfigurations of the middleware type. This is why thereis a bidirectional arrow between the RECO componentand the software bus for trace message. The RECOcomponent reads traces of other applications andpublishes its own traces (see Figure 4). Note also thatthe RECO component can be configured and deployedto run on a different machine. similar to other GMSECapplications.

Software BUS (for "trace" messages)

L— ----^ ------r------i

GEDAT CAT SA RECD

ISoftware Bus (for "real" messages)

Figure 4 an overview of the environment for thedynamic analysis of the GMSEC. Each filled bubble is aGMSEC application. Two software buses arerespectively used for publishing "trace" and "real"messages. RECO is the component for collecting tracesenutted by other applications, including its own traces.Arrows denote data-flow.

3.4.3. Discovering C-C views and Sequence Diagrams

Readers who are unfanuliar with the concepts of CP-nets are requested to [7], which offers an in-depthdiscussion on how CP-nets were used for analyzing thePipe-and-Filter architectural style of Ricoh's photocopymachine software. We used the same concept to performanalyses of the Publisher-Subscriber architectural stylebelow. Here, we informally explain the design of CP-nets for discovering the C-C view of the publisher-subscriber style. We designed our CP-nets in a modularfashion, meaning that it was a composition of severalCP-nets such as a) One CP-net for recognizing thecreation of a connection to the software bus by

monitoring call events to the `Create' method of theGMSEC API (Le., to the ConnectionFactory classexplained in static analysis), b) One CP-net for creatingthe connection port used for publishing messages on thesoftware bus. The CP-net implements this capability bymonitoring call events to the `publish' method of theConnection class, c) One CP-net for creating theconnection port used for subscribing messages on thesoftware bus. The CP-net implements this capability bymonitorine call events to the `subscribe' method of theConnection class, and d) One CP-net for attaching theports of publishers with subscribers. Two ports areattached if one party consumes the messages publishedby the other party. Matching the subject of the publishedmessage with the subscribed message is the key activityof this CP-net.

In order to discover the C-C view, we ran theconstructed CP-nets on events emitted by the runningsystem. We used the RECO component, which placeseach run-time event into the different places that areresponsible for holding call-events. Different parts of theCP-net processed the call-events, as explained above,and produced the C-C view as a collection of tokens.Here, we have manually drawn the C-C view by usingthe discovered high level events, see Figure 5 for anexample. In addition, we can see all connections to thesoftware bus that are created by each application andcan determine how many they are, for example.

Pid-7024(RECO)

rf , IPid 7720(SA) Pid 7252 (CAT)

Pid 4704(CATGUI)

Pid-3804 (GEOAT)

^ Connection port for publishing tothe software bus

0 Connection port for subscribing to the software bus

Figure 5 An example C-C view discovered using run-time events. Each box is a run-time process and thenaives of applications are placed in brackets.

All applications communicate with the RECDcomponent because it consumes the run-time events thatare published by the other applications. When weshowed Figure 5 to the GMSEC team, they mentionedthat this view is very useful as it nicely captures inter-communication among different applications at a highlevel of abstraction, a view that is normally difficult tocreate. The good news is that there are no surprisingdependencies between the applications. However, one ofthe developers mentioned that he did not know the factthat the CAT has 3 connections to the GMSEC bus forpublishing messages to other GMSEC applications.

Thus, this view can be also used by developers tounderstand exactly the dynamic architecture of acomplex system. In order to understand hoe r messagesare exchanged among different parties of the publisher-subscriber style, our CP-nets used the subjects of themessages that were subscribed by the subscribers andthe subjects of the messages published by the publishers.If the subjects of the messages match, then our CP-netsstore the connection between publishers and subscribers,the messages, and sending and receiving time of themessages. We visualized that output using the Dyn-SAVE tool, as shown Figure 6 for example. We canvisualize messages and their data fields, too.

d 725:

152467 rns

85 ms

92 ms

153267 rns

153907 rns

153255 rns

154797 rns

154806 ms

Figure 6 A snippet of the sequence diagram showingmessages exchanged among publishers and subscribers.It also shows the time at which messages are sentreceived. Contents of messages can also be visualized.

3.4.4. Detection of a High-Priority BugHere we briefly explain one of the bugs in the GMSECframework, which is due to inconsistencies in theimplementation of the same abstract interface(Connection) by different wrappers of middlewarevendors, see Figure 3. We developed three CP-nets thatcheck constraints of the publisher-subscriber style. OneCP-net keeps track of all calls to the "subscribe" methodof the Connection class, another CP-net keeps track ofall calls to the "unsubscribe" method of the Connectionclass. A third CP-net detects multiple calls to thesubscribe event, without an intermediate unsubscribe.

The CP-nets reported that the RECO componentsubscribed to the same message more than once. TheGMSEC API has a feature that allows applications tohave a call-back capability when a message arrives fromother applications. We used that feature and subscribedto the same message three times, because we wanted toprint "trace" messages in three different formats usingthree different call-backs. When we used the GMSEC's

software bus (i.e., "nib" in Figure 3) to send and receive"trace" messages, the return code of all three calls to the"subscribe" method was NO ERROR. We tested howactivemq behave for the scenario and switched from thenib to the activemq middleware wrapper. Its "subscribe"method returned MIDDLEWARE_ERROR reportingthat the RECO component makes multiple subscriptionsto the same message.

We showed the RECO implementation to theGMSEC team; and discussed the behavioralinconsistency between the two middleware wrapperimplementations of the same abstract interface (i.e., theConnection class, Figure 3), which caused the RECO tofail when we switched from one middleware wrapper toanother wrapper. They agreed that this is an importantbug and will fix so that all middleware wrappers willbehave in an equivalent way with respect to their returncode. Otherwise, applications cannot reliably chooseand/or switch between different middleware wrappers.We would not have detected this important bug unlesswe modeled and verified the run-time behavioralproperties of the publisher-subscriber style.

3.5. Answering the Questions

Question Answers/Comments1. Are there any middleware used Yes. The GMSEC software bus isfor implementing a software bus? implemented using middleware

technology.2. If middleware is used. is there Yes. There is air layerany middleware abstraction layer that "hides" vendor-specificthat hides the knowledge of a APIs.

articular middleware API?3. Carl and subscribers Yes. The core of the GMSEC isbe implemented in different implemented in C++. However,programming languages? If yes, there are interfaces for C, Java,how are the variants in the and Perl. Language variants arelanguages managed? managed using JNI [15] and XS

[14].4. Can publishers and subscribers Yes. Publishers and/orcome-and-go dynamically at nut- subscribers can freely enter/leavetime? the running system.

5. Carl subscribers, Yes. Publishers and subscribersand the software bus run on just need the IP address and thedifferent machines? port number of the software bus.6. Which subscribers receive The discovered sequencemessages from which publishers diagrams answers this questionand in what order? for the scenarios we have

executed.. Do subscribers receive No. However, we cannot

messages from connections that extrapolate because dynamicare not subscribed by them? analysis results are not

generalizable.8. Carl subscribe to Yes and No. This is a bu g thethe same message more than GMSEC team is currently fixingonce without air it.unsubscribe?9. Carl unsubscribe to No, not for the execution tracesmessages that are not subscribed we analyzed.by them?10. Are there timing delays in Currently.. we are analyzingdelivering messages to timing aspect for different

subscribers? middleware configurations usingthe discovered sequencediagrams.

3.6. Connecting the GMSEC's Business Goalswith Implemented Architectural Decisions

In order to understand the relationship between theGMSEC's business goals and the implemented high-level architectural decisions, we discussed with theGMSEC project manager, the product leader, and seniorengineers. Based on this discussion, we were able toexplicitly link the business goals and softwarearchitectural decisions (see Figure 7).

High-level Goals The GMSECApproach

Simplifydevel1p-1t, integrationand testing GMSEC does not dictate

components, butletsuserschoose

Facilitate technology infusionovertime

Provide publisher-subscriberSupport evolving development interfacesand operational concepts

Provide multiple languageAllow for mix of heritage, COTS bindingsand new comporre nts

Avoid Vendor lock-in Provide a middleware abstractionlayer

Allow developers to carry theirGMSEC knowledge between Standardize interfaces—notprojects/components components

Figure 7 Relationships between business goals andsupporting architectural decisions.

It is interesting to note from this study that importantarchitectural decisions were primarily influenced bybusiness goals. Therefore, it is advisable that theimplemented architecture needs to consistent with thespecified architecture, as shown to be true for theGMSEC with some exceptions mentioned above.

4. Brief Comparison to Existing Work

We will first list a few related articles and then highlightcountnon differences to our work. Riva et al. extract boththe module-structure and sequence diagrams byrespectively using static and dynamic analysis [17].Wendehals and Orso extract automata using executiontraces [22]. Giannakopoulou et al. use LTL to verifybehavioral properties of execution traces [10]. Schmerlet al. use the pair of architecture and implementationstyles to discover C-C views of a running system [19].Stroulia and Systa [21], and Cornelissen et al. providean in-depth survey on other dynamic analysis techniques[1]. Dong et al. review methods and research tools forrecognition of desi gn patterns from the source code [2].

Key differences between our work and the existingwork are: We extracted component-connector views,which showed the run-time structure of the software.

We used CP-nets to systematically tackle theinterleaving of runtime events with respect to thesoftware architecture. We discussed several adaptationsof the DiscoTect method in [7]. Our sequence diagramscan a) hide the software bus for analyzing the publisher-subscriber style, and b) show attributes/parameters ofmessages exchanged between parties. If we excludeparameters, like in many existing work, we cannotdistinguish calls to the subscribe method on twodifferent message subjects, for example. Cornelissen etal. mentioned that there is a short-coming of research, inreverse engineering, on systems that evolve at run-timelike the GMSEC. Regarding design pattern discovery;our focus was on bridging the abstraction gap betweenrun-time events and the publisher-subscriber style.

5. Conclusion and Future Work

We presented a practical approach for analyzing systemsbased on the publisher-subscriber architectural style. Wederived a set of analysis questions, which focused onboth the structural and behavioral constraints of thestyle. First, we performed the static analysis to answerthe questions related to the structural constraints.Second, we used the results of the static analysis toorganize the dynamic analysis for answering behavioralconstraints. We discovered component-connector viewsand sequence diagrams using execution traces, whichwere fed into our Colored Petri Nets, for tackling thechallenge of interleaving of run-time events. Using thisapproach on the NASA's GMSEC, we discovered thatthe GMSEC has a) a good middleware abstraction layer,which helps in avoiding vendor lock-in, and b) has somehigh-priority bugs due to behavioral discrepanciesamong different middleware wrapper implementation.Our future work will focus on analyzing timing aspectsof different middleware wrappers.

References

1. B. Cornelissen, A. Zaidman, A. Deursen, L.Moonen, and R. Koschke. A Systematic Survey ofProgram Comprehension through DynamicAnalysis. In IEEE TSE, 35(5), 2009.

2. J. Dona, Y. Zhao, and T. Peng. Architecture andDesign Pattern Discovery Techniques - A Review.International Conference on Software EngineeringResearch and Practice. 2007.

3. P. Eugster; P. Felber, R. Guerraoui, and A.Kernnarrec. The Many Faces of Publish./Subscribe.ACM Computing Surveys, 35(2), 2003.

4. K. Jensen, Coloured Petri Nets, Basic Concepts,Analysis Methods and Practical Use, SpringerVerlag, 1993.

5. L. Feijs, R. Krikhaar, and R. Van Ommering. ARelational Approach to Support Software

Architecture Analysis. Software Practice andExperience, 28(4), 1998-

6. D. Ganesan, M. Lindvall, D. McComas, and M.Bartholomew. Verifying Architectural Design Rulesof the Fli ght Software Product Line. In SoftwareProduct Line Conference (SPLC), 2009.

7. D. Ganesan, T. Kueler, and Y. Nishimura.Architecture compliance checking at run-time-Journal of Information and Software Technology(IST). 51, (2009).

S. D. Garlan, S. Khersonsky, and J. S. Kim. Modelchecking publish-subscribe systems. Internationalconference on Model checking software, 2003.

9. B. L. Ghezzi and C. L. Mottola. On AccurateAutomatic Verification of Publish-SubscribeArchitectures. In ICSE, 2007.

10. D. Giannakopoulou and K. Havelund. RuntimeAnalysis of Linear Temporal Logic Specifications.In ASE, 2001.

11. G. Kiczales, J. Lamping, A. Mendhekar, C. Maedar,C. Lopes, J.-F. Loinatier, J. Irwin, Aspect-OrientedProgramming, ECOOP, 1997.

12. O. Lehr. A Framework for the Detection andAnalysis of Software Connectors. University ofMannheim, Master Thesis, 2010.

13. M. Lindvall. Using sequence diagrams to detectcominunication problems between systems. In IEEEAerospace Conference; 2008-

14. XS Module. http://en.wikipedia.org/wiki/XS (Perl).15. JNI. http://java.sun.com/j2se/1.42/docs/miide/jni.16. A. Postma. A method for module verification and

its application on a large component-based system.In IST 45, 2003.

17. C. Riva, J. Rodriguez. Combining static anddynamic views for architecture reconstruction. InCSMR, 2002-

18. G. Salton, A. Wong, and C. S. Yang. A VectorSpace Model for Automatic Indexing.Cornmunications of the ACM. 18, 613-620, 1975-

19. B. Schmerl, J. Aldrich, D. Garlan, R. Kazman, andY. Hong, Discovering architectures from Waningsystems, IEEE Transactions on SoftwareEngineering 32 (7), (2006).

20. M. Shaw and P. Clements. A field guide toboxology: Preliminary classification of architecturalstyles for software systems. In COMPSAC, 1997-

21. E. Stroulia and T. Systa. Dynamic Analysis ForReverse Engineerin g and Program Understanding,Applied Computing Review, ACM, 10(1), 2002-

22. L. Wendehals and A. Orso. Recognizing BehavioralPatterns at Runtime using Finite Automata. InWODA, 2006.

Acknowledgements. Lisa Montgomery and herNASA IV&V team and Sally Godfrey NASA GSFC forsupporting this work.