Re-engineering a Reverse Engineering Portal to a Distributed SOA

William M. Mongan, Maxim Shevertalov and Spiros MancoridisDrexel University

Department of Computer Science3141 Chestnut Street

Philadelphia, PA 19104{wmm24, ms333, spiros}@drexel.edu

Abstract

REportal is an existing web-based reverse engineeringportal web site that provides access to a suite of reverseengineering and program comprehension tools via a webbrowser. This abstraction was intended to allow ease ofsystem maintenance by adding and upgrading tools with-out involving the end user. However, the software tools andserver technologies used became deprecated so quickly thatit was not possible to take full advantage of the architec-tural vision. Using a service-oriented architecture, we ab-stract the process flow of the system from the underlyingtools, enabling a wizard-style method of adding services tothe system, and facilitating more “hands-off” maintenance.In this paper, we describe the challenges and benefits of thisarchitectural migration.

1. Introduction

REportal1 [16] is a Reverse Engineering portal web sitethat facilitates software architecture decomposition, pro-gram analysis, and understanding with a minimal amountof user intervention.

Although there exists a wide variety of tools enablingsuch software analysis, they typically represent a heteroge-neous suite. Some tools have simple command-line pipeand filter architectures for some particular platform, whileothers have an elaborate API for some language. Moreover,many tools have feature overlap: one tool provides featuresA and C, while another provides features A and B, thougheach tool has a proprietary or graphical output format. Asa result, obtaining a comprehensive view of a software sys-tem requires considerable tool configuration on the part ofthe user.

1http://reportal.cs.drexel.edu/

The vision behind REportal was that the tool configu-ration would occur behind the application server, and thatREportal would act as a thin client that exposed the fea-tures of those services. Tools were presented to the useras common tasks with a familiar web browser interface.The result was a cohesive set of features that allowed forentity browsing, querying relationships in the system (forexample, inheritance graphs, and call graphs), performingtransitive reachability queries using the results of relation-ship queries, and browsing the cross-referenced source codeof discovered entities in the system. These features wereexposed mostly through the CIAO [5] command-line Unixtool suite from AT&T Labs Research. A Java-based APIfor Bunch [15] was used to cluster these results in order toautomatically discover software modules and subsystems,and GraphViz [8] was invoked to display graphical resultsin an applet view. Source code browsing and text searchare available, and source code metrics such as CyclomaticComplexity and inheritance tree depth are provided via ad-ditional tools (see Section 5).

Despite the utility and ease-of-use benefits of the portal,there exist a number of challenges pertaining to the mainte-nance and extensibility of the system. The original REpor-tal was written as a single Java Servlet, which resulted in atight coupling between user management, the tools, and theuser interface. In addition, some of the primary tools are nolonger maintained and, thus, do not effectively parse newlanguage extensions or JDK versions. The system was de-signed with tool upgrade in mind, but the tight coupling ofthe portal as a whole made complete tool overhaul difficult.

To promote this easy extensibility as well as flexibilityin the use of the underlying tools, we propose a distributedService Oriented Architecture (SOA) for the new REportal.This not only facilitates much easier maintenance and ex-tensibility on the system, but it also serves as a microcosmthat enables further research in automated service orches-tration.

The rest of this paper is organized as follows: SOA is

described in Section 2. We discuss related work and re-search areas in Section 3. Section 4 discusses our generalapproach of service-wrapping around the legacy tools andAPI’s. Section 5 describes the tools that we include in thisnew version of REportal. Section 6 talks about the poten-tial and maintenance benefits of switching to an SOA. Wedescribe future related research areas in Section 7, and con-clude in Section 8.

2 Background: Service Oriented Computing

Service Oriented Computing (SOC) is a movement to-wards an implementation-independent architecture for dis-tributed computing. According to the OASIS SOA Ref-erence Model [18], “Service Oriented Architecture is aparadigm for organizing and utilizing distributed capabil-ities that may be under the control of different ownershipdomains.” Rather than an object-based design and func-tionality, SOA raises the level of abstraction towards higherlevel business logic. Although SOA allows for a bottom-up design amicable to the integration of legacy systems, thereal benefit is realized from a top-down, implementation-independent approach. By using XML schemas to de-fine abstract data types and an XML document to definebusiness-logic operations in terms of these abstract types,a complete interface is derived for a system that naturallyhides implementation details and business secrets.

3. Related Work

The idea of migrating a legacy system to an SOA hasbeen explored in the literature. For example, one relatedproject provides a mechanism to migrate grid applicationcomponents to web services automatically [6]. Another in-troduces a wrapper technique similar to our own for migrat-ing legacy systems to an SOA, using a finite state machineand a terminal emulator to allow for the migration of in-teractive tools [4]. Our goal, however, is to migrate legacydistributed systems, or to migrate a number of legacy toolsinto a cohesive distributed suite of services, and then createa business process that finds, selects, coordinates and exe-cutes those services on the fly. The multi-server distributedapproach is selected for two reasons: primarially due to theheterogeneous nature of the tools, but also to support paral-lel execution of the tools in question.

The Purdue University Network Computing Hubs(PUNCH) [11] project exposes computer architecture simu-lation and design tools for education via a web portal. Likethe original REportal, the spirit of PUNCH is to provide ac-cess to these tools regardless of the user’s physical locationor available computing resources. without the user’s inter-vention. PUNCH works by specifying the inputs required

by a particular tool, and how to map those inputs to thetool’s interface, via HTML and CGI “templates” specifiedby a high level language. Process flow is enabled by a finitestate machine structure.

Other research in automatic software modularization in-cludes work that clusters based on data use by subsys-tems [10]. Data bindings are identified in which a modulewrites to a variable that is read by another module. Thisidea serves as the basis for identifying potentially interest-ing subsystem interactions for clustering purposes [21, 15].

Legacy migration to SOA is also discussed by Sneed [20,19] and Lewis [14]. Sneed points out that new architec-tures such as SOA cannot be successful if they cannot “take[legacy] programs along.” The problem is compounded bythe use of programming languages that have dependencieson the user environment; particularly, those that also pro-vide the runtime environment. Despite this complexity anddependency, it is desirable to create services that are simpleand easy to use. He proposes an automated tool that wrapslegacy code in WSDL that exposes the high level features,and then the creation of higher level, more abstract and sim-ple services (based on features) that invoke them. Lewis de-scribes the Service-Oriented Migration and Reuse Techique(SMART) [14].

4. Approach to an SOA-Based REportal

The approach taken to compose the new REportal is amore tool-centric one. Rather than building a presentationlayer that is coupled to the tools, we instead create a genericpresentation framework that accepts and queries XML doc-uments, using tools wrapped as web services. These XMLdocuments may be repositories of software systems, Mod-ule Dependency Graphs (MDG), call graph representations,and so on. If a new tool is integrated, it is only neces-sary to represent its output as an XML document and queryit at the presentation layer for display. Graphical outputis created by the Bunch clustering system, accepting anMDG graph as input and ouputting a Graph Exchange Lan-guage (GXL) [22] graph, which is an XML graph format.This format is used by the ClusterNav visualization pro-gram which uses GraphViz as its underlying drawing tool.

Because each tool is wrapped as a web service, a stan-dalone non-web client can be easily created on any platformby creating an implementation based on the WSDL and theXSD type definitions. We chose instead to implement ourclient as yet another server, created using JSP documents torepresent the presentation layer. SOA client stubs invoke theservices and return their results, possibly after some filter-ing and logistics (including, for instance, unzipping a user’sproject on the file system). The JSP presentation layer in-vokes the client stub, queries the resulting XML document,and displays the results on the web page or graphically us-

ing the ClusterNav tool.To integrate the tools, the primary tool functionality is

first identified; we find its appropriate customization param-eters, inputs, and output format. These inputs and outputsmay be file-based via a command line, or string-based viaan API. In either case, a web service is created that wrapsthis primary functionality. An XSD is created to representthe parameters, input and output of the tool, and a WSDLexposes a high-level interface that uses the parameters, in-puts and outputs. The service architecture allows for trans-parent passing of parameters and results from service hostto service client, given the host’s service URL. This is a crit-ical element of REportal’s new architecture, because someof these tools only run on a particular platform, or on a par-ticular JDK, making it essential to support tools that existon various hosts. In this case, the JSP Presentation com-ponent represents the service orchestration entity: based onthe user’s desired execution task (a call graph relationship,for instance), it chooses the services to invoke and runs themin the proper order, passing the result from each one to thenext service until the final output is obtained. Ultimately,this process will be automated with BPEL. With an auto-matically generated BPEL, services are selected and orches-trated for a particular execution task. Once an RE businessprocess is established that creates a process thread for theseservices, it becomes possible to execute these services inparallel. The BPEL process and its potential for SOA isdiscussed in Section 6.

5. Tools

In this section, we describe the core tools that have beenwrapped into REportal services.

5.1 Source Code Browsing

Source Code Browsing features for the Java language areprovided by Sorcerer2. The source code browser is differentfrom the other tools in that, instead of returning an XMLdocument to be queried, it returns a set of HTML pagesthat are either displayed on a web browser or downloadedfor display. To accomodate this, REportal displays the webpages in its presentation layer via Ajax (see Figure 1).

5.2 Static Analysis

Static analysis features are currently offered for the Javalanguage, and are provided by the BAT static analyzer [7].BAT parses the Java bytecode and produces a representationof the code structure and behavior as an XML document ina schema defined by BAT. Using BAT, we created a query

2https://sorcerer.dev.java.net/

Figure 1. The REportal Source Code Browser,provided by a service wrapped around Sor-cerer. Sorcerer’s results are displayed in aniFrame in REportal via Ajax.

engine that performed common software analysis queries onthe document, either using XSLT transformations or equiva-lent XQuery operations [17] (discussed in Section 5.7). Theresult of these queries is represented in a JDOM3 document,using an XML representation that is currently internal toREportal but will ultimately be developed into a compre-hensive XML Schema (see Section 7).

5.2.1 Clustering Analysis Results to Obtain Subsys-tems

Querying the resulting XML document from any of theseservices (most commonly the Static Analyzer service), aModule Dependency Graph (MDG) is obtained that theBunch clustering system [15] converts into a clusteredgraph in GXL [23, 9] format. This clustered graph providesa hierarchy of graph abstraction that, with an appropriateviewer (see Section 5.4), one can “drill into.” For staticanalysis graphs, this clustered abstraction provides a viewof the subject program’s subsystem structure, derived fromthe relationships found between its entities.

5.3 Dynamic Analysis via Aspect Instru-mentation

Aspect Instrumentation modifies the program’s sourcecode such that a logger traces the method invocations of asoftware system, yielding the dynamic call graph for a par-ticular feature. This is accomplished by creating an aspectusing AspectJ [12] for Java code, which runs behind a ser-vice and uses the static analysis results of the system to ob-tain a list of methods that the aspect should instrument. For

3http://www.jdom.org/

security reasons, the user downloads the aspect, instrumentshis own code, and uploads the result which is generated bythe aspect. That result is further analyzed to produce anXML graph that is visualized as described in Section 5.4.

5.4 Graphical Display

Graphical display of query results is obtained by visu-alizing GXL graphs, with clusters represented by specialnodes that can be clicked to expand them into their fullgraph view. This is accomplished with an internally de-veloped tool called ClusterNav, and allows for visualiza-tion of the software system at various levels of abstraction.The tool runs as a Java applet at the JSP presentation layer.Examples of this graphical output is depicted in Figures 2and 3.

Figure 2. Collapsed view of a class relation-ship graph.

Figure 3. Expanded view of a class relation-ship graph.

ClusterNav works by performing XML queries on the

GXL graph produced by Bunch. By double-clicking onthese clusters the user can expand or collapse clusters into asingle node view, causing the graphical display to representthe entire graph at various levels of abstraction.The clusternodes are color coded using a spectrum from green to red,showing their relative weight.

5.5 Metrics Service

The Metrics service is provided by a metrics frameworkthat currently runs JavaNCSS4 on Java code. Metrics in-clude fan-in and fan-out for classes, inheritance hierarchysize, method Cyclomatic Complexity, and others.

5.6 Database Management

Project and user logistics management is provided bya language-independent service that drives a database andmaintains the repository on the local file system. Thisdatabase is queried both to locate the user’s project, andalso to ensure that the project is owned by the user associ-ated by the login token obtained when the user first authen-ticated. The database management layer does not depend ona particular platform or database engine, but the underlyingdatabase is provided by mysql5.

5.7 Querying the XML repositories

The Saxon6 open-source XSLT engine was used to querythe XML repositories obtained by the the tools described inSection 5. At present, the majority of the XML represen-tations are simple wrappers around MDG graphs, but someXML representations, such as the BAT class file representa-tion, are more complex and enable custom queries to returninformation such including reachability queries from a par-ticular class. It is possible to use XSLT transforms to querya data repository such as the XML Java class representationprovided by BAT. Using XSLT, one can use regular expres-sions to query data, as well as more verbose loop constructsthat are typically easier to read and modify. So far, we havecreated XSLT transforms for the BAT repository to supportentity and relationship queries among classes, methods andvariables.

6. Benefits

6.1 Maintenance

The service-oriented, tool-centric architecture better en-ables the usability of the portal and tools, as well as for the

4http://www.kclee.com/clemens/java/javancss/5http://www.mysql.com6http://saxon.sourceforge.net/

extensibility of adding or upgrading tools. If, as was expe-rienced in the past, a tool becomes incompatible with cur-rent compilers, or a presentation feature becomes incompat-ible with current web browsers, only a simple drop-in codereplacement is required. New tools do not depend on orimpact existing features due to the separation created by aservice based approach.

6.2 Deployment

It is also easy to deploy the system as a whole. Clientdeployment involves distributing a single web client whoseservice URL’s point to the deployed service locations on theweb. Customers who are not comfortable with uploadingtheir code to a remote service location for analysis may de-ploy the entire system on their local machines; this is also asimple matter of updating the web client’s service URL’s topoint to these internal locations. The only requirements area system with the required JDK, tools and any tool depen-dencies, and an application server like Apache Tomcat. In aheterogeneous tool environment such as ours, multiple ver-sions of JDK and/or multiple instances of Tomcat may berequired to run the tools. If the user desires to distribute theservices among multiple servers, it is simply necessary toedit the reportal.ini file to reflect the new service WSDL andmySQL database URLs, and, if needed, change the Tomcatports and REportal startup script to reflect those ports.

6.3 Heterogeneous Clients

It is also important to note that web services do not nec-essarially imply a web-based solution as REportal provides.This is the most logical client to offer to users due to its easeof use and access; however, it is possible to write local com-mand line tools or custom GUI applications in any languagethat run on any platform. To do so, one would direct SOAclients to the deployment locations of the individual toolsbeing used.

6.4 Contributions to SOA Research

The primary contribution of a service-oriented web por-tal is to serve as a case study for ongoing research intoService Oriented Architectures. For example, in creatingREportal, we have also described the “business model” forperforming software analysis on a subject system. Thismodel includes uploading the project, performing one ormore common queries for relationships, metrics, dynamicanalysis data, etc., and then visualizing that data. REpor-tal provides an extensible framework for carrying out thisbusiness model, much like a travel agent provides genericfunctionality for booking travel details. The implementa-tion methods themselves are not important as long as thedata output from these tools can be made compatible.

This service-based portal also enables semi-automatedservice addition, binding, and orchestration. Currently,given a new service to be integrated, one must automaticallyconstruct a service client that invokes the service and wrapsits results in a data structure, invoke that service client froma menu in the presentation layer, and display its results. Ifthe tool does not have a corresponding service, a WSDLproviding a few methods to exercise the primary features ofthe tool is constructed, resulting in a service wrapper com-patible with REportal. To display a graphical representationof the tool’s output, an adapter is needed to construct anMDG graph from the tool’s output, and this MDG graph isrun through the Bunch service, producing a GXL graph thatis displayed in the ClusterNav applet. However, even thisprocess can be improved, and the new REportal provides atestbench for such improvements. For example, since ser-vice generation for existing tools is a nearly automated pro-cess, a configuration file might specify the interfaces to atool’s primary functionality (or they can be obtained by per-forming static analysis to find system methods invoked bythe main() function), and the WSDL wrapper would ex-pose those features along with their input and output types.This is the focus of current research, using a configurationfile that specifies how the service dispatcher should handlethe input and output types of the tool, and is described inSection 7.

7. Future Work

Section 6 described a number of contributions to both theREportal system and to users of reverse engineering tools. Italso serves as a “proof of concept” for automating a serviceoriented business process, and provides a case study uponwhich SOA automation techniques can be applied. There issome current research on automation of SOA BPEL mod-els, and automating service orchestration; however, for ourlong term research goals in SOA, it is helpful to have a welldefined universe in order to avoid the details of semantic de-scriptions. We are more interested in working with dynamicselection and binding of tools, in which an important detailis to identify the interfaces, input and output types.

To facilitate this, however, an XML Schema is neces-sary to provide a common adapter between the tools. Theservices must provide either a common interface to the pri-mary data artifacts, have a configuration that specifies howto get this data, or have a semantic description by which thisinformation can be determined at runtime.

8. Conclusion

In this paper, we discussed the original spirit of the RE-portal system. We detailed the challenges that we faced in

maintaining REportal and its underlying tools as they andtheir technologies evolved. We re-engineered REportal bytaking its underlying tools and creating service wrappersaround them, and then integrating those services using aJSP-based web service client. This new architecture allowsus to maintain REportal by using abstract XML queries forand representations of data, facilitates adding new tools tothe system by insulating them in a decoupled service layer,and permits heterogeneous REportal client instances that in-dependently invoke the portal’s services. Using REportal asa case study, a great deal of potential in the area of SOAresearch was also provided, including a business processmodel for reverse engineering and an XML representationfor program understanding.

Acknowledgements: The author is supported by NSFgrant DGE-0538476.

References

[1] C. Anslow, S. Marshall, R. Biddle, J. Noble, and K. Jack-son. Xml database support for program trace visualisa-tion. In APVis ’04: Proceedings of the 2004 Australasiansymposium on Information Visualisation, pages 25–34, Dar-linghurst, Australia, Australia, 2004. Australian ComputerSociety, Inc.

[2] C. Anslow, S. Marshall, J. Noble, and R. Biddle. Softwarevisualization tools for component reuse. In 19th AnnualACM Conference on Object-Oriented Programming, Sys-tems, Languages, and Applications, 2004.

[3] Apache. Apache tomcat, May 2007.[4] G. Canfora, A. R. Fasolino, G. Frattolillo, and P. Tramon-

tana. Migrating interactive legacy systems to web services.In CSMR ’06: Proceedings of the Conference on SoftwareMaintenance and Reengineering, pages 24–36, Washington,DC, USA, 2006. IEEE Computer Society.

[5] Y.-F. R. Chen, G. S. Fowler, E. Koutsofios, and R. S. Wal-lach. Ciao: A graphical navigator for software and docu-ment repositories. In Proc. Int. Conf. Software Maintenance,ICSM, pages 66–75. IEEE Computer Society, 1995.

[6] J. Dunnweber, S. Gorlatch, F. Baude, V. Legrand, andN. Parlavantzas. Towards automatic creation of web ser-vices for grid component composition. In V. Getov, editor,Proceedings of the Grids@Work Plugtest, Sophia-Antipolis,France, October 2005.

[7] M. Eichberg. Bat2xml: Xml-based java bytecode represen-tation. Electronic Notes in Theoretical Computer Science,141(1):93–107, December 2005. Proceedings of the FirstWorkshop on Bytecode Semantics, Verification, Analysisand Transformation (Bytecode 2005).

[8] J. Ellson, E. Gansner, E. Koutsofios, S. North, and G. Wood-hull. Graphviz and dynagraph – static and dynamic graphdrawing tools. In M. Junger and P. Mutzel, editors, GraphDrawing Software, pages 127–148. Springer-Verlag, 2003.

[9] R. C. Holt, A. Winter, and A. Schurr. GXL: Towards a Stan-dard Exchange Format. Technical Report 1–2000, Univer-sitat Koblenz-Landau, Institut fur Informatik, Rheinau 1, D-56075 Koblenz, 2000.

[10] D. H. Hutchens and V. R. Basili. System structure analy-sis: clustering with data bindings. IEEE Trans. Softw. Eng.,11(8):749–757, 1985.

[11] N. H. Kapadia, R. J. Figueiredo, and J. A. B. Fortes. Punch— Web portal for running tools. IEEE Micro, 20(3):38–47,/2000.

[12] G. Kiczales, E. Hilsdale, J. Hugunin, M. Kersten, J. Palm,and W. G. Griswold. An overview of aspectj. In Proceedingsof ECOOP 2001 - Object-Oriented Programming: 15th Eu-ropean Conference, Budapest, Hungary, June 18-22, 2001,pages 327–354, Heidelberg, June 2001. Springer Verlag.

[13] M. Lanza. Codecrawler — lessons learned in building a soft-ware visualization tool, 2003.

[14] G. Lewis, E. Morris, D. Smith, and L. O’Brien. Service-oriented migration and reuse technique (smart). In STEP’05: Proceedings of the 13th IEEE International Workshopon Software Technology and Engineering Practice, pages222–229, Washington, DC, USA, 2005. IEEE Computer So-ciety.

[15] S. Mancoridis, B. S. Mitchell, Y. Chen, and E. R. Gansner.Bunch: A clustering tool for the recovery and maintenanceof software system structures. In ICSM ’99: Proceedingsof the IEEE International Conference on Software Mainte-nance, pages 50–59, Washington, DC, USA, 1999. IEEEComputer Society.

[16] S. Mancoridis, T. S. Souder, Y.-F. Chen, E. R. Gansner, andJ. L. Korn. Reportal: A web-based portal site for reverse en-gineering. In WCRE ’01: Proceedings of the Eighth Work-ing Conference on Reverse Engineering (WCRE’01), pages221–230, Washington, DC, USA, 2001. IEEE Computer So-ciety.

[17] J. Melton and S. Buxton. Querying XML,: XQuery, XPath,and SQL/XML in context (The Morgan Kaufmann Series inData Management Systems). Morgan Kaufmann PublishersInc., San Francisco, CA, USA, 2006.

[18] O. C. on Service Oriented Architecture. Reference modelfor service oriented architecture, 2006.

[19] H. M. Sneed. Integrating legacy software into a service ori-ented architecture. In CSMR ’06: Proceedings of the Con-ference on Software Maintenance and Reengineering, pages3–14, Washington, DC, USA, 2006. IEEE Computer Soci-ety.

[20] H. M. Sneed and S. H. Sneed. Creating web services fromlegacy host programs. wse, 00:59, 2003.

[21] T. A. Wiggerts. Using clustering algorithms in legacy sys-tems remodularization. In WCRE ’97: Proceedings of theFourth Working Conference on Reverse Engineering (WCRE’97), page 33, Washington, DC, USA, 1997. IEEE ComputerSociety.

[22] A. Winter. Exchanging Graphs with GXL. Technical Re-port 9–2001, Universitat Koblenz-Landau, Institut fur Infor-matik, Rheinau 1, D-56075 Koblenz, 2001.

[23] A. Winter. Exchanging Graphs with GXL. Technical Re-port 9–2001, Universitat Koblenz-Landau, Institut fur Infor-matik, Rheinau 1, D-56075 Koblenz, 2001.