# INTRODUCTION usiness organizations have a large investment in software written in legacy programming languages and architecture. Today, most of the organizations run systems that have been developed a long time ago and are still adapted and maintained to meet current needs [1]. Approaches used in legacy systems sometimes differ considerably from today's modern paradigms. Adapting legacy software systems to new requirements also requires their migration and integration with new technologies and applications. A Legacy Information System can be defined as "any information system that significantly resists modification and evolution" [1]. These Information Systems pose considerable problems including brittleness, inflexibility, isolation, non-extensibility, lack of openness on the enterprise IT infrastructure. They significantly resist further modification and evolution. Legacy systems were designed for internal, enterprise wide usage while today's enterprise demands for inter enterprise communications and support for agile business processes. There are various methods proposed including supplementing or replacing restrictive legacy applications and technology with newer, open standards-based applications and technologies, but still retaining existing business functions [2]. Legacy renovation is an expensive task. As the requests for modifications, new development and integration accumulate, it is very difficult to keep pace and enable a more agile enterprise. So it is advantageous to integrate legacy application with new applications while retaining the business logic intact. SOA models the enterprise business workflow as a collection of business services, these services can be easily Reused and integrated in the organization to address the application requirements [3] [4]. Rather than developing from the ground up every time a change is needed, new assets can be created easily from existing services, saving time and money [5]. The most important advantage of SOA is to provide a data bridge between incompatible and desperate technologies [6]. BPM is a set of technologies and standards for the design, execution, and administration and monitoring of complex, automated business processes BPM provides the facility to monitor, analyze, control and improve the execution of these processes in real time [7]. Existing Web Services can be integrated as the counterparts of steps in business processes. Examples are credit verification in an on-line order process [8]. Several approaches for Legacy application integration and migration towards Service oriented architecture have been proposed in the past but they B ©2011 Global Journals Inc. (US) include difficulties in identifying candidate services from legacy application and their alignment with the organizational business processes requirements. Wrapping functions of legacy systems for exposing as web services may be a fast way for migration towards SOA, However the services provided are technologyoriented and do not fully address business goal or scenario, which might lead to the services not being fully utilized as per the business goals. The top-down approaches analyze existing business processes in order to identify adequate services but services are business oriented and may failed to get the needed functionality in legacy applications. Our proposed method uses BPM and SOA together in order to make legacy participation in the enterprise business processes by means of exposing and orchestrating services. We used both top-down BPM driven and bottom up SOA driven service identification mechanism along with automated discovery of business logic in legacy codes to better align legacy application with business needs. The reminder of the paper is organized as follows: Section 2 provides background information needed to understand the paper, Section 3 presents the proposed approach for legacy service exposure and participation in enterprise business processes with a case scenario, section 4 describes Discussion of result and historical approaches for legacy system migration and integration. We conclude with summary and future directions in section 5. # II. # BACKGROUND INFORMATION An organization has a collection of interrelated business processes, which consist of a series of activities, jointly represent a business goal. For instance an order process in a B2B environment includes several activities networked with each other to complete the order process business goal. These business processes may have their span in several desperate applications in the enterprise and beyond. The ''service'' is an application logic or underlying computing resource with an abstraction of the underlying implementation [3], that is exposed through an interface and which can be invoked over a network with standard protocols [9]. The most important application of SOA is to align the services to the business requirements and to facilitate reusability of existing services connecting the various operational systems that automate an enterprise's business processes [10]. Bottom-up approaches examine legacy systems and standard software for the identification of services. The bottom-up approach analyses the existing application for all available functions that can be exposed as a web service. With a bottom-up approach the definition of services originates in the domain of the application [11]. This approach results in a large number of available functions which can be exposed as services but does not tell anything about their usability. In bottom-up approach Services are discovered, rather than defined as requirements, therefore it tends to lead to poor business services as it preserves the current solution instead of addressing business needs. The top-down approaches analyze existing business processes in order to identify adequate services. This approach looks at the processes in the business domain, decomposes them into sub process/tasks/functions until 'logical units of work' are defined, which we call services. The decomposition of the process in itself is not enough to discover services, because we will have to convert the 'candidate-service' into a real-world executable and discoverable service. This means we have to compare the functionality of the service with the available infrastructure but it does not reach deep into the architecture and implementation domain. By combining these two approaches together we may get the best of both eliminating the shortcomings of each one and integration with the current application infrastructure and readiness for the business needs we are looking for. Therefore, a hybrid approach combining both methods is applied in order to minimize the problems associated with these approaches [12] [13].The hybrid meet-in-the middle approach combines top-down and bottom-up techniques in order to identify services that better correspond to both the business requirements and the existing systems [14]. It provides a compromise between the top-down and bottom-up techniques that eliminates the most significant disadvantages. We proposed a meet in the middle approach with automatic discovery of prospective services in the legacy application for integration in business processes. # III. # PROPOSED APPROACH The proposed approach is a combined meet in the middle approach consists of BPM and SOA along with the reverse engineering of legacy application in order to identify the candidate services and their participation in the enterprise business processes. It eliminates the disadvantages of failure in getting the needed functionality in legacy applications and lengthy time of top down approach and non-business orientation of bottom up approach. Basically, we are proposing consolidated approach that provides guidance on the derivation of both business services and supporting software services to achieve a close business and IT alignment. The proposed method is influenced by meet in the middle approach by Inaganti and Behera with some improvements by minimizing the problem in finding of candidate service in legacy application [15]. This approach requires a comprehensive analysis of the legacy application and not just the mapping .In this paper we also presented a reverse engineering approach to extract the information of the legacy application through resource extraction from the application along to generate and publish the service. The proposed technique can be summarized as a methodology for mapping legacy application resources to modern enterprise environment by BPM and SOA with the help of Reverse Engineering to facilitate the identification and extraction of the key business logic from Legacy application and alignment with business requirements. Figure 1 shows the block diagram of proposed method. As an example scenario, here we introduced a prototype legacy banking application developed in C++. The Application is a monolithic standalone C++ application with no external interface for communication with other applications. The application stores the data in flat file system and provides various inbuilt functionalities like opening an account, deposit money, withdraw money, get balance, viewing of transactions and various reports. One can interact with it only through application GUI which is inbuilt in the code. We assume that there are certain situations arises due to business needs, in which above application is required to be integrate with some other modern applications and business processes. As stated earlier in the paper, it is not viable to replace or rewrite the legacy application with new code. As the legacy application is standalone and the logic is embedded deep in the form of functions, it is very difficult to handle this situation. Our approach resolves the problem without rewriting the legacy code and without interrupting the operation or maintenance of the legacy system. We presented a business process of ATM here. The ATM process resembles the new business requirement and we have to address it by using core business logic of legacy application. The ATM application will be a thin client with only GUI. The ATM GUI will provide only the user interface and the orchestrator takes care of proper sequencing of operations and calling of web services from legacy application. Various new business conditions and constraints, which are not present in legacy application may be addressed with the orchestrator, for example prohibiting withdraw operation in case of insufficient balance or not allowing a certain transaction if the number of transaction exceeds, without rewriting of the core component of the legacy application. The methodology is mentioned in following steps. Analyze the Core Business process. In the first step, it is necessary to analyze functional domain of business process and understand the business requirements. During the initial analysis phase, basic decisions regarding identifying the most important functions of the domain and showing their interrelationships is identified. The business structure and the functions of the business process are specified [16]. A business process reveals how an individual process activity is linked with another in order to achieve a business objective. We have to identify the start and end events of a particular business activity, human interactions with the process, automated activities and links with the other applications and organization's processes. This step results in a core coarse grained business process. This analysis results in the development of the "to-be" process model that an SOA solution is intended to implement [8]. In the context of our scenario we analyzes how a user will interact with ATM, how the business process will progress with the user interaction. This step results in the use case of ATM process, actors, activities and the flow of business. ii. # Model the core business processes In this step we design the core business process found in previous step into a graphical model using a BPM modeler, as in our case Intalio [7]. At first, the business process is modeled at a high level where activities in the Business Process Diagram usually aggregate sub processes, which are graphically evaluated in another sub process BPM diagram. A [+] sign inside an activity denotes a process that can be decomposed into sub-processes [17]. We marked each task which requests an external service as service task. One of the purposes of the process model is to define process execution and to create the BPMN notation for this purpose. The BPMN defines both the graphical notation and the semantics of a Business Process Diagram, We model the diagram with core elements of a BPD which comprises Flow Activities, Tasks represented by a rounded-corner rectangle which is a generic term for work that has to be performed, Events which are diagrammed as a circle, Gateway Objects represented by a diamond symbol which are used to control the divergence and convergence of a sequential flow. By means of these basic Flow Objects. The core process contains at least one POOL which is executable and can be deployed on orchestration Engine. The core business process acts as an orchestrator which will direct and invokes the various Web services from legacy and other third party applications to form and execute a complete business activity [18]. iii. # Business Process refinement In this step we perform decomposition or refinement of sub processes of core BPM Diagram into elementary or atomic business functions. Business process refinement identifies service tasks, message activities, and events and actions in the sub process [11]. When the business process is subdivided into sub-processes or decomposed into granular activities the lowest level tasks will consist of small, cohesive "logical units of work", that are supported by the functionality offered by distinct services. It results in discovery of elementary business functions which can be addressed by web services in the application domain [19]. Delegating functionality into sub business processes prevents business processes from becoming overly large, complex and difficult to maintain. The refinement can be seen in authorization process diagram. After refinement of sub processes the next step is to find out the Service Tasks which provide some sort of service which could be calling a Web service or an automated application. We will find the task which will call the legacy and other web services process. This service tasks will call atomic (single) web service interfaces of legacy application. In the case of authorization sub process the call authorize task invokes the authorize function of legacy application as shown in yellow color in figure 2. # c) Existing asset analysis and Service identification in Legacy Application The purpose of this step is to identify assets in the legacy application i.e. business logic and legacy functionality which are capable of supporting the realization of services that meet business needs. The focus is on existing assets that play a role in business processes 14]. We initially perform a coarse-grained mapping of business processes and process activities to the portfolio of existing applications and application interfaces. Later in the specification, we perform a more fine-grained mapping, including message specification. We also identify various system resources so that the performance can be measured. i. # Component identification in legacy application Service identification On the one hand, it is to determine what business functionalities should be provided by the target service in the application domain. On the other hand, the business functionalities embedded in the legacy system should be identified in order to be reused in the target service [20]. In this step the legacy application will be reverse engineered and we will find the various resources and embedded business logic to be exposed as web services by adopting bottom up approach. The analysis reveals the reuse potential of existing legacy components. The results of this step include information on system architecture, system components, infrastructure details and interfaces. The proposed work identifies that this is a tedious process and the complexity grows with the line of code that reflects the business logic. Therefore a summary of the business logic present in the code is of extreme important. Here it is performed by a automatic reverse engineering tool. The working description of the tool is as given below. First the tool Scans the program and tokenizes the program. Thereafter it removes the comments and blank sections. It Extracts the function definitions and other resources using following logic:-1. Check if there is a "(" token in the line or not If so, extract the previous token ( which can be function name or a predefined function or key words like if, for and so on) 2. Check if the token is a key word or not. If not, scan till the end and look for a ";" if it is not there, scan for another token appeared before the current token with space separation. 3. If the previous token is a key word (which reflects the return type) then marks the current line as the function definition. Extract the arguments and return types. An approach for exposing legacy applications for integration in modern enterprise business processes ©2011 # Identify the point of functionality in legacy application In the previous step we found the information about application resources and various functions present in the Legacy application through reverse engineering. Now we identify the points of functionality of the legacy application that may be useful to implement the needed web services to interact with service task in the Orchestrator [15]. In the output of automated tool we find the independent functions calls so that it can be used to designate or make as a point of functionality, it means, among several functions we found the one that contains the functionality of interest for service tasks found in top down approach. For example found_account function may be used to make authorize function wrapper that can be used as point of functionality and can be exposed as web service and mapped with service task. iii. Exposure of identified functions as web service. The functions identified in previous step as the point of functionality are now exposed as web services [19]. The Service interface defines the types of messages and the message exchange patterns that are involved in interacting with the service, together with any conditions implied by those message.. The definition of functions which has to be called by service task has been written in a single header file test.h. The header file guides the GSOAP tool to generate stubs for needed web services. Now we write the web service module by using identified functions of previous step and with the help of GSOAP supporting files. All the exposed web services can be called through the WSDL Interface and the Service end point URL [20]. WSDL describes the operations that a service can support, and the parameters each operation accepts and returns. End point URL serves as a service provider. The application web service will provide the response to service task upon calling with appropriate parameters. Figure 4 describes the wsdl portion for input and output parameter for Authorize operation. The service matching activity maps the service task to corresponding atomic web service in the application layer. Each atomic service task exactly maps single web service [15]. There may be some situation in which a service task will be divided in more than one service task and it may comprised of more than one point of functionality. We will map the service accordingly, for example the fund transfer service task will be associated to two services i.e. deposit and withdraw. Several service task may be associated to same service, for example a withdraw service may be associated to both withdraw and fund transfer service tasks. These concepts can be seen in Fig 1 and Fig 6. At the end of this step we complete the matching and mapping of all the service task and corresponding web services with each other. # e) Service realization and orchestration All the web services exposed from legacy system were atomic and asynchronous, that means there is no such execution or sequence order is set by default. In a business process there are several operating conditions upon which a business activity relies. For example a withdraw service can only be happened after authentication service, it must not happened before. Assembling services in order to accomplish business logic and business processes is called orchestration. [3] Explains orchestration as "the implementation of a business related workflow owned by a single entity through the combination of business relevant services". The orchestrator is deployed as a BPEL program in the Orchestration director engine. In this step we define orchestration logic as the business logic that sequences, coordinates and manages conversations among Web services. This entire thing is expressed in BPEL. To execute a BPEL process a BPEL engine is needed which parses the BPEL code and executes the contained instructions. The Core Web services that are used by the BPEL program have to be deployed in advance. The whole orchestrator is deployed on Intalio BPMS server which acts as an Orchestration director engine. The orchestrator may be called in presentation mechanism through its WSDL and endpoint URL. In the ATM application a Java GUI reforms the presentation task which uses the orchestrator. # DISCUSSIONS AND RELATED WORK The implementation and results of the proposed method may be understood by following demonstration of the case scenario. In figure 5 an account summary page is displayed. We can understand that all the logic is embedded deep in the code of legacy application. In figure 6 the composite fund transfer service task in the orchestrator is elaborated. New business process requires a fund transfer mechanism, which needs to be achieved from the existing code. This is done in the modeler by calling and sequencing two web services from legacy application thus making a composite process. In the sample banking application no individual authentication is required as the software interacts only through its GUI and it is accessed by bank authorities. But as per the requirement of ATM business process as the application is exposed to an external world then it is very important to put an authentication mechanism. This is incorporated in the orchestrator as shown in figure 7. The results demonstrate the process proposed in this work with a sample banking application as elaborated in the case description. The system can map legacy application at par with the requirement of business using exposure of functionality through web services and the usability by orchestration of BPM process. Further the released services can be used by any language or application like Java and C# through the service description. This also proves that by adopting the proposed technique one would be able to integrate new logics with the existing business logic or would be able to seamlessly upgrade the existing services without having to make any changes in the coding in the legacy application. Therefore the architecture minimizes the maintenance cost by maintaining the business logic in the middle layer independent of the implementation. In the past several methods for legacy system modernization have been proposed and discussed. [21] elaborated the white-box modernization and blackbox modernization approaches comparisons. Fig. 7 Intalio ATM orchestrator process with interfaces [22] Proposed a method to address the issues on migrating legacy systems into a Web enabled environment by using CORBA. [23] Used reverse engineering techniques to encapsulate the logic with JNI wrapper. [24] Proposed a method to make interactive legacy systems accessible by wrapping interactive functionalities. [25] Proposed a tool based approach to wrap the legacy codes. All of the methods were focused on the application modernization only rather than addressing the business domain. In our approach we emphasized on a close business and IT alignment. # V. CONCLUSION In this work a legacy application mapping technique by combining top-down approach with bottom-up approach is proposed using SOA and BPM. The method defines how a legacy application should be exposed as services and how these services can be used to fulfill business goals. The solutions principles are demonstrated through the results. Instead of using the manual functionality discovery in the legacy service identification stage, a tool is developed to automatically identifying the services. The interoperability of the entire solution is shown in the result section. The prime criteria and objective of the work has been to prove the proposed design of legacy application mapping and integration to participate in enterprise business processes. As the services are exposed to be used on network, performance calibration and tuning is another aspect and the speed and processing capabilities of the environments used must be taken into consideration. The proposed approach performance and speed issues are some of the work that can be associated with the future direction of research for this work. 1![Fig. 1 Block diagram of proposed method a) Problem Scenario](image-2.png "Fig. 1") ![b) Top down Business process Analysis and identification of services in the Business domain i.](image-3.png "") 5823![Fig. 2 Authorization sub process](image-4.png "58 MayFig. 2 Fig. 3") 4![Fig. 4 part of a wsdl for legacy application web service interface](image-5.png "Fig. 4") 5![Fig. 5 Legacy application account statement](image-6.png "Fig. 5") 6![Fig.6 Composite service for fund transfer](image-7.png "Fig. 6") ![](image-8.png "") * Legacy information systems: issues and directions JBisbal DLawless BWu JGrimson IEEE Software 16 5 Sept/Oct 1999 * The Modernization Imperative Oracle Magazine * Service-Oriented Architecture: Concepts, Technology, and Design TErl 2005 Prentice Hall PTR Upper Saddle River, NJ, USA * Finding Services in the Mainframe A SRao Linux for you December 2008 5. May 2007 SOA Magazine Issue VII * Introduction to Service Oriented Architecture. (SOA) JChatarji * Services/Introduction-to-Service-Oriented-Architecture-SOA/ An approach for exposing legacy applications for integration in modern enterprise business processes ©2011 Global Journals Inc US * Global Journal of Computer Science and Technology Volume XI Issue X Version I * Business-driven development TMitra 2005 IBM IBM developerWorks article * The Role of Visual Modeling and Model Transformations in Business-driven Development JKoehler RHauser JKuster KRyndina JVanhatalo MWahler Electronic Notes in Theoretical Computer Science 211 28 April 2008 * Service-Oriented Computing MPapazoglou DGeorgakopoulos Communications of the ACM 46 10 2003 * Understanding SOA with Web Services EricNewcomer GregLomow * Addison-Wesley 2005 * Service-Oriented Design and Development Methodology MPPapazoglou WJVan Den Heuvel Int.J. of Web Engineering and Technology 2006 * Service-oriented modeling and architecture, How to identify, specify, and realize services for your SOA AliAsranjani November 2004 IBM Developerworks * Fastening the SOA/SOMA Service identification approaches with project environments SGandhi IBM Developerworks March 2010 * SOMA: a method for developing service-oriented solutions AArsanjani SGhosh AAllam TAbdollah SGanapathy KHolley IBM Systems Journal 47 3 2008. 2008 * Service Identification: BPM and SOA handshake SInaganti GBehara BPTrends 2007 * Analysis and Design Techniques for Service-Oriented Development and Integration OZimmermann NSchlimm GWaller MPestel Proc. GI Jahrestagung GI Jahrestagung 2005 * Development of SOA-Based Software Systems -an evolutionary Programming Approach CEmig JWeisser SAbeck IEEE Conference on Internet and Web Applications and Services ICIW'06 Guadeloupe / French Caribbean February 2006 * OMG Business Process Modeling Notation 2009 * Service Identifi cation Approach to SOA Development NFareghzadeh Proceedings of World Academy of Science, Engineering and Technology 35 2008 * Service identification and packaging in serviceoriented reengineering ZZhang LRuimin HYang Proc. of the 17 th International Conference on Software Engineering and Knowledge Engineering of the 17 th International Conference on Software Engineering and Knowledge Engineering IEEE Computer Soc 2005 * A survey of black-box modernisation approaches for information systems SComella-Dorda KWallnau RCSeacord JRobert Proceedings of the International Conference on Software Maintenance the International Conference on Software Maintenance IEEE CS Press 2000 * YingZou KostasKontogiannis Web-based Legacy System Migration and Integration" the 4th International Conference in Systematic, Cybernetics and Informatics (SCI) Orlando, USA July 2000 * A grid oriented approach to reusing legacy code in ICENI framework LJianzhi ZZhang HYang Proc. of the 2005 , IEEE I nternational Conference on Information Reuse and Integration of the 2005 , IEEE I nternational Conference on Information Reuse and Integration IEEE Computer Soc 2005 * GCanfora ARFasolino GFrattolillo PTramontana A wrapping approach for * Integrating legacy software into a service oriented architecture HMSneed Proc. 10th 10th * European Conference on SoftwareMaintenance and Reengineering 2006 IEEE Computer Soc