Abstract-Rule-based methods have traditionally been applied to develop knowledge-based systems that replicate expert performance on a deep but narrow problem domain. Knowledge engineers capture expert knowledge and encode it as a set of rules for automating the expert's reasoning process to solve problems in a variety of domains. We describe the development of a knowledge-based system approach to enhance program comprehension of Service Oriented Architecture (SOA) software. Our approach uses rule-based methods to automate the analysis of the set of artifacts involved in building and deploying a SOA composite application. The rules codify expert knowledge to abstract information from these artifacts to facilitate program comprehension and thus assist Software Engineers as they perform system maintenance activities. A main advantage of the knowledge-based approach is its adaptability to the heterogeneous and dynamically evolving nature of SOA environments. Keywords-expertise; rule-based system; knowledge-based system; service oriented architecture; SOA; software maintenance; search tool. Rule-based methods have been very effective in supporting decision making in many complex domains. Can they also assist Software Engineers in dealing with the emerging complexities of Service Oriented Architecture (SOA) applications? SOA is not a single software architecture, but rather a style for constructing complex systems, especially those that need to cross organizational boundaries. SOA systems, often called composite applications, typically resemble Fig. 1 . An organization, whether governmental, non-profit, or private, finds that it needs to work with other organizations to carry out key workflows. For example fulfilling a purchase order requires getting stock from a partner company, planning employee travel involves reservations on several airlines, or providing a doctor with a patient's medical history entails assembling information from many medical records systems. As shown in Fig. 1 , in a SOA architecture the software to support these workflows is organized as services having defined interfaces, running on different nodes and communicating via message passing. Some of these services will be owned and managed by the home organization but others will belong to partners or be offered by commercial vendors. Most commonly the Web Services group of standards is used to define the service interfaces and protocols [1] . In theory, these standards are supported by a broad group of providers so that services can interoperate across many different programming languages, operating systems, and data definition schemas. However, the standards have turned out to be both very complex and very loose, leading different implementers to create services and interfaces having vastly different styles. SOA composite applications began to appear at the start of the twenty first century and by now are very widespread. They have faced many technical and managerial difficulties, but perhaps none will be more difficult than the challenge of software maintenance as these systems begin to age. Traditionally, maintenance of large software applications has been particularly expensive and slow because typically: a) There is a large code base of existing, legacy software. Vol. 2, No.3, 2013 45 | P a g e www.ijarai.thesai.org SOA Software Engineers will thus have to respond to continual and often unpredictable change as they maintain large heterogeneous applications exhibiting a bewildering variety of programming styles. This research explores how knowledgebased methods can help provide the necessary expertise to help SOA systems evolve at reasonable cost. In this paper we describe a knowledge-based approach to this problem, in which a rule-based system is used to enhance search techniques so that a Software Engineer can more rapidly understand a given composite application. The rule-based system generates abstractions, snippets of information that summarize complex application relationships to provide context quickly. The main benefit of the rule-based method is adaptability; different application styles and changing environments may be handled by relatively simple modifications to the rules. Thus a rule set can itself dynamically evolve as the composite application evolves to meet changing needs. In the next section the article reviews related work followed by a presentation of an illustrative example to motivate the need for SOA abstractions. Then it describes the design principles appropriate for search in a SOA context, discusses the knowledge-based approach to SOA abstraction, and presents the results of an evaluation case study. The article concludes with a summary of key contributions and suggestions for future work. Although little literature is available regarding the use of rule-based systems for SOA system maintenance, rule-based systems have been applied more broadly to software understanding. Canfora and Di Penta [4] describe two tools, Design Maintenance System [9] and TXL [10] which parse source code and, through rule-based transformations, produce artifacts that facilitate program understanding. Braun [11] describes a server-based analysis system based upon rules that is designed to play a role in configuration management of software. The idea is that checked-out versions can be subjected to rule-based checks for various attributes before they are committed to a version control system. Rule-based information extraction akin to the idea of summarizing software abstractions in the current work appears to be an area of increasing interest. Zaghouani [12] describes a system for named entity extraction from text in natural language processing. Wang [13] describes named entity extraction with rules and a machine learning approach using "conditional random fields." Michelakis et al. [14] describes rule-based information extraction in which structured objects are extracted from text, based on user-defined rules. Research on tools to support maintenance of SOA systems has been fairly limited. Most of the proposals involve dynamic analysis, usually of a trace from a running system. A group from IBM has described a tool called Web Services Navigator that uses dynamic analysis to provide five different views of an executing system [15] . Two papers describe ways of locating user features within a SOA system. One approach produces a sequence diagram showing the feature [16] while the other does an analysis of dynamic call trees [17] . Halle et al. have a somewhat different approach that starts from a hypothesized service contract and automatically sends a series of trial invocations to see if the service actually conforms to the hypothesis [18] . Dynamic analysis is a powerful approach to understanding a system; the main difficulty is that it is frequently impractical to gather the needed data from a large system running across multiple nodes. III. SOA MAINTENANCE CHALLENGES: AN ILLUSTRATIVE EXAMPLE To illustrate the problem of understanding SOA, consider an example from WebAutoParts.com, one of the composite applications in our Open SOALab collection of resources for SOA teaching and research [19] . WebAutoParts.com (Fig. 2) is a hypothetical online automobile parts supplier that uses external services to facilitate agile development. As is true for many SOA composite applications that are based on the Web Services standards, the main artifacts that describe WebAutoParts are BPEL program code, WSDL service interface descriptions and XSD data type definitions. Vol. 2, No.3, 2013 46 | P a g e www.ijarai.thesai.org BPEL, the Business Process Execution Language, is an XML formatted language that describes how services are orchestrated together to perform a complete workflow [20] . Each BPEL program itself becomes a service when it is interpreted on an application server. WSDL stands for Web Services Description Language [21]. WSDL files, which again have an XML format, describe the interface that a service presents to its clients. XML Schema Descriptions (XSDs) are an XML language used to describe the data types for the message data that is passed between services [22] . The data type descriptions for a particular service may either be incorporated into the <types> section of the service's WSDL file or else included from an external XSD file. WebAutoParts has an order processing workflow shown in Fig. 2 . There are two "stubbed" in-house services written in BPEL (Order Processing and Inventory Repository) and four external services from three well-known vendors:  Amazon Web Services -Amazon Simple DB (database) and Message Queue (message queuing)  StrikeIron.com -Tax Data Basic (sales tax rates)  Ecocoma -USPS (shipping costs) In this workflow, an incoming order is first checked against inventory to confirm that it can be processed. Then sales tax is computed based on the rules of the state where the customer resides. Shipping costs are then computed and added and finally the order is added to a message queue to be picked up by the order fulfillment service. While the WebAutoParts application does not actually execute, it consists of syntactically correct BPEL code which deploys successfully to the Ode BPEL environment along with XSD and WSDL documents typical of current industrial practice. Suppose a Software Engineer unfamiliar with this application is trying to implement a change to the database design and needs to know what data is passed when Order Processing checks inventory levels. If he has extensive BPEL/Web Services experience he might figure this out using a series of searches (Fig. 3) . In these searches he must match the names appearing in different XML elements and navigate up and down the containment hierarchy of these elements: Even for a Software Engineer who is an expert in Web Services, tracing such chains of relationships requires a tedious and error-prone sequence of searches. Furthermore, the heterogeneity of SOA services will mean that expertise may not generalize well from one composite application to another. Each such application may use a different combination of technologies and apply them in different ways. There are, for example, many textually different ways to describe essentially the same message data using WSDLs and XSDs. Worse, the Web Services standards themselves are evolving so it is likely that a maintainer will encounter fielded systems based on different versions. Finally, since the WSDLs, XSDs, and configuration files that describe a composite application are often machine-generated, they contain "clichés" or patterns that are peculiar to a particular development environment. For example, an XSD generated by Microsoft's WCF framework contains five-tag sequences of XML to simply declare a void return type for an operation [23] . There is a lot of information contained in the artifacts describing a SOA composite application. Experts with long application-specific experience may be able to navigate these artifacts, but such experts will be scarce. Thus, the focus of this research is to develop a rule-based system that mimics expert reasoning on the SOA artifacts to provide useful information for a wider range of Software Engineers lacking specific knowledge in handling the artifacts. Intelligent search tools can help users find the kinds of information in SOA composites that maintainers may need. Search tools based on text matching are usable on a variety of document types making them a good fit for the heterogeneous world of SOA composite applications. Our group has been conducting research on the application of intelligent search for SOA maintenance using SOAMiner, a prototype SOA-specific search engine. Case studies with different groups of academic and real-world programmers have been exploring "what SOA maintainers will want to know" [23] [24]. The results of these studies have shown that participants found it easy and natural to search a large corpus of artifacts from a SOA composite application. They quickly found relevant snippets of information, such as all the XML tags containing a keyword such as "inventory". However search Vol. 2, No.3, 2013 47 | P a g e www.ijarai.thesai.org identified each snippet in isolation and did not show its context within the application as a whole. In some cases it was sufficient to simply show more of the surrounding text, but it is clear that for other problems a Software Engineer would need to make a tedious sequence of searches such as those in the example given earlier. We conclude that, for SOA, search needs to be enhanced with a process of abstraction. For example, a search should take the user to relevant fragments of a BPEL, WSDL or XSD, and then provide a higher-level abstraction that shows how that fragment fits into a wider reality. A difficulty, of course, is that in SOA's open environment the relevant abstractions will vary from system to system and over time as standards, practices, and tools change. Thus we need an adaptive and dynamic abstraction mechanism to complement SOA search. An ideal tool would index the collection of artifacts from a composite application and: 3) Allow the definition of additional abstractions so that more and more searches can be moved into the first category. Such a tool should be flexible to adapt to a wide range of SOA artifacts from different environments and allow for the inclusion of new abstractions as they are discovered. Knowledge plays a key role in achieving intelligent behavior. Knowledge-based systems capture human knowledge, represent it in a machine readable form, and facilitate reasoning with it for solving problems. The following describes our approach to capture human expertise in SOA code analysis and to use that expertise for analyzing SOA artifacts and providing intelligent search support. Rule-based systems have traditionally been used to capture human expertise as a set of rules to draw conclusions from chains of rules applied to initial facts stored in a working memory. As the rules execute, new facts are being generated and added to the working memory causing other rules to execute. Eventually, the rules have completely transformed the facts in memory and no rule can execute. The working memory contains the conclusions that the rules derived. This flexible control, inherent to rule-based systems, differs from predefined control structures found in programs of traditional programming languages. Rules can be easily modified or extended to adjust the performance of the rule-based system. Thus, rule-based systems are an ideal method for dealing with the heterogeneous nature of SOA applications and their evolving artifacts, to identify and extract abstractions automatically and make them available for inspection. Through experiments and case studies involving domain experts we create a set of rules that identify abstractions within the SOA artifacts, and extract and transform these abstractions into machine-readable representations. In essence, the rules capture an expert's knowledge and skills to identify useful excerpts of information relevant to software maintenance tasks and the reasoning engine automates the process of the expert's analysis of SOA artifacts by executing chains of rules on the artifacts once they are committed to the engine's working memory. Fig. 4 shows the system architecture of the knowledgeenhanced search tool. The tool is composed of an XML annotator, a search indexer, and a reasoning engine. It processes XML Files since many SOA artifacts have XML structure (WSDL, XSD, BPEL and many configuration files). As a first step, the tool annotates every element in the input XML files with a unique identifier so that it can be referenced in the reasoning engine and during searches. After annotation, the files are loaded both into the search indexer and the reasoning engine. This engine runs the DROOLS Expert rulebased system to identify and construct abstractions from the input sources [25]. The engine executes rules on XML elements in the imported files to identify abstractions existing within the artifacts and build them in working memory. As abstractions are committed to the working memory as temporary results the rules may subsequently discover new abstractions and relationships between them. Finally after all rules have fired, working memory is queried to store the abstractions in files that can then be displayed in response to searches in support of maintenance tasks. Each abstraction is formatted as an XML snippet that includes constituents and relations from the SOA artifacts to model the abstraction. The final output is in the form of three XML files, one containing the set of abstractions, another containing cross-references when one abstraction refers to another, and a third describing the search index for the Apache Solr search platform [26] . Our case study produced three types of abstractions to support maintenance activities: A) data type summaries, B) services, and C) BPEL invoke relationships. Based on these findings, we analyzed artifacts from the WebAutoParts SOA composite application to look for abstractions and to identify the information that is needed to produce them. From this information, rules and representations were built that match XML elements in the SOA artifacts and transform them into new representations to describe the different abstractions.
However, some research has looked at static analysis of the artefacts that describe services, such as WSDL interface descriptions and XSD data schemas REF .
A Knowledge-Based System Approach for Extracting Abstractions from Service Oriented Architecture Artifacts
International Journal of Advanced Research in Artificial Intelligence
Computer Science