Keywords

1 Introduction

As computer software grows in power, users demand ever more powerful and reliable programs, resulting in ever larger and seemingly more complex software systems. Thus a major challenge in large-scale software development is managing the complexity encountered during the construction of new applications that is partly attributable to frequent customizations due to requirement changes.

This complexity can potentially be reduced if applications could be implemented based upon an open standard-based interface and communication protocol. From this, all applications can be accessed more efficiently and easily, thus enabling businesses to leverage their existing software systems. In addition, since business requirements are typically subject to frequent changes, the demand on existing systems to evolve is inevitable. Consequently, there is a need to have an efficient method to support the software evolution process. Service Oriented Architecture (SOA), a new approach to developing software systems, has been eventually invented to fulfill this demand.

SOA has gained significant popularity for achieving business goals and implementing business processes in a flexible manner. SOA is becoming a mainstream approach for software development. Abrams and Schulte [1] indicated that during 2007, more than 50 % of large, newly-developed systems and business processes were designed and developed based on the Service Oriented Architecture paradigm. Lublinsky [2] suggested there are three primary reasons that businesses are interested in SOA. First, by adopting SOA they can achieve better alignment between business and Information Technology (IT). Second, SOA enables them to construct more flexible and responsive IT infrastructure. And last, that SOA can simplify the implementation of data integration among a business' applications. Based on this argument, in order to sustain their competitiveness to be leaders in the market, businesses need to transform their legacy systems to SOA applications toward providing more efficient services to their customers.

Generally, migration from legacy systems to SOA applications is carried out manually by domain experts with subject-matter knowledge with some training in software development or with the assistance of software developers [3, 4]. The problem of migrating (i.e., transforming/adapting/retargeting) large-scale legacy software systems to a modern environment, to new hardware platforms, and to new run-time support is a major issue facing the software industry. The focus of this work was to investigate the existing migration approaches and capture the significant features of each approach so as to give the guideline for businesses to choose a tailor-made migration approach suiting them.

2 General Migration Processes

2.1 Legacy System Assessment

Sommerville [6] presented four strategic options for software evolution as illustrated below.

As shown in Fig. 1, there are four clusters for legacy systems as described below.

Fig. 1
figure 1

Legacy System Assessment (Source: Software Engineering, 9th edition, p.253)

Full size image

  • Low Quality, Low Business Value: These systems should be discarded since it is costly and unproductive for businesses to keep them.

  • Low Quality, High Business Value: These systems are still productive but costly to maintain. Therefore they should be transformed to a system with a new SOA architectural style.

  • High Quality, Low Business Value: Although they are inexpensive to maintain, these systems should be discarded as they are unproductive.

  • High Quality, High Business Value: It is cost-effective to maintain these systems. So these systems should be kept without making any changes the system.

Several criteria need to be defined and quantified so as to measure the quality of an SOA system. This can be performed by interviewing some domain experts or using a questionnaire. Fortunately, there are a lot of researchers working in this area by defining a number of criteria to assess legacy systems. Four basic attributes of a legacy system, namely Business Value, Decomposability, Obsolescence, and Deterioration, and guidelines to measure each attribute were introduced by Cimitile et al. [25]. Ransom et al. [26] presented a method to assess legacy systems namely technical, business, and organizational aspects. This method could help businesses to assign a value to each assessment characteristic and also to interpret these values. They indicated that their method can be tailored to specific organizations.

2.2 Feasibility Analysis

Khadka et al. [12] proposed the seviciFi method using method engineering to determine the economical and technical feasibility of the migration based on the legacy system's charactersitics and the requirements of the target SOA application. Erradi et al. [13] proposed a decision framework to help organizations to select the optimal combination of legacy modernization options. Aly and Amir [14] presented a decision making tool using decision theory and the weighted sum methodology to generate the most optimal strategy to be used in modernizing legacy systems. They also proposed an automated decision making process for choosing a migration strategy using a combination of the approaches proposed in [23] and [13]. Aversano and Tortorella [27] proposed a strategy to help businesses define the evolution requirement to SOA based on characteristics of their legacy systems. They specified nine steps in software evolution: analyze the organization, reconstruct processes, identify and analyze the processes, identify technology, formulate evolution requirements, assess the legacy software system, define software system evolution requirements, reengineer the processes, and perform the system evolution. The authors reported the first stage of testing their method with two different systems: a bank system and a public administration system. According to their result from the first stage, this method is certainly applicable however it needs additional information and it also needs to be supported by a specific integrated and Web-based software environment.

2.3 Migration

Migration refers to any approach that can be applied to a legacy system in its entirety in the process of transforming it to SOA architecture. This section discussed how legacy code components are identified, decomposed, and extracted using several techniques. The User interfaces of legacy systems are reengineered to be SOA-based system compatible. Migration strategies incorporate both top-down and bottom-up approaches and aim to produce a system with an improved SOA-compatible design.

Aly and Amir [14] proposed a method which automatically generates a modular software structure from a given source code by using spectral clustering. First, undirected graphs are generated based on the existing dependencies among the components and then spectral clustering is performed to generate the component structure of the target system. To evaluate this method, they applied it to CoCoME, a small and well-documented software system. They compared the resulting software structure to the one created by an expert. They reported that the result were similar. However, the component structure resulting from their approach cannot be represented by any architectural style. In their case study, the legacy system is a three-tier architecture but the result is a single-layer architecture.

Chen et al. [8] and Millham [11] presented a service oriented reengineering approach using feature analysis to extract candidate services from legacy systems. Feature analysis addresses the understanding of features in software systems and defines mechanisms for carrying a feature from the problem domain into the solution domain. In [8], the specified feature analysis activities are: identifying system features, constructing a feature model to organize the defined features, and identifying their implementation in the legacy system through feature-location techniques. Based on a feature model, certain service identification and packaging processes are performed that result in service delegation.

In a research conducted by Millham [11], data and control dependencies among the component files of a legacy system are analyzed and then clustered into groups. Cuadrado et al. [9] described a case study of the evolution of an existing legacy system towards a more maintainable SOA system. To define the specific evolution plan, the architecture of the legacy system was recovered. This approach was applied to a medical imaging system evolving it into an SOA-based application. Matos and Heckel [3] proposed the new methodology for migration based on source code analysis for identifying the contribution of code fragments to architectural elements and a graph transformation approach for architectural migration. Alahmari et al. [10] introduced a framework to identify optimal services from legacy code with the appropriate level of granularity, by focusing on the significance of the classification of service types, to define service properties.

Reddy et al. [15] proposed guidelines for evaluating the suitability of existing assets by identifying the core principles of SOA, namely cohesion, reusability, discoverability, loose coupling, abstraction, formal contract, composability, and statelessness. They argued that organizations can use their guidelines to improve the quality of their migrations by considering their defined metrics and guidelines. Stroulia et al. [16] described the overall process for legacy system migration to a Web-based system using the CelLEST method. This method addresses the issue of migration based on understanding and modeling the users' interaction with the legacy system’s interface. There are three main steps in this method. The first step is to model the behavior of the old system using a state transition diagram. The second step is to find the users' tasks as frequently-occurring interaction patterns to recover the specifications of the application's functions. The last step is to construct the new user interface allowing the legacy functions to be accessible over the Web.

Aversano et al. [17] presented a migration project aiming to integrate a COBOL system into a Web-enabled system. The legacy system was dissected into user interfaces and server (application logic and database) components. The user interfaces were migrated into a Web browser shell using Microsoft Active Server Pages (ASP) and VBScript. All server components were wrapped with dynamic load libraries written in Microfocus Object COBOL, loaded into Microsoft Internet Information Server, and accessed via the ASP pages.

Werth et al. [18] introduced Business Service Management as an interdisciplinary approach for business-driven deployment of SOA. The main purpose of this work was to represent a business' characteristics and requirements toward IT as business processes. Bhallamudi and Tilley [19] presented the Evolution Process Framework for SOA (a mechanism for analysis of existing SOA migration projects) to learn about factors such as technology selection, migration approach utilized, legacy system type, and SOA governance that influence the success or failure of each project.

Mohagheghi and Sæther [20] applied the model-driven approach to construct a methodology and a tool for transforming a legacy system into a service oriented application. O’Brien et al. [21] used architecture reconstruction in the process of migration. To accomplish this, dependencies among components in the legacy system were identified. Based on this information, an essential step in making decisions regarding migration of legacy components to services was devised. They also suggested that using architecture reconstruction techniques in conjunction with other analytical methods could provide an essential set of analytical methods for decision making.

Marchetto and Ricca [22] proposed a stepwise approach based on testing to migrate Java application into SOA-based application. This approach, which is a hybrid top-down and bottom-up approach, was applied to four Java applications. Lewis et al. [5], [23] described their Service Oriented Migration and Reuse Technique (SMART), a technique helping businesses to analyze legacy capabilities for use as services in an SOA. Their technique considers the specific interactions that will be required by the target SOA and any changes that must be made to the legacy components. They described a wide range of information about legacy functionalities, the target SOA, and the potential services that were aggregated to produce a service migration strategy.

2.4 Evaluation

Shim et al. [24] suggested that, in order to evaluate the quality of an SOA application, a quality assessment model is needed that defines the desired quality attributes and measures them. From this, design problems can be detected and resolved before the development of the system. The relationship between design properties and quality attributes is described in Table 1. Shim et al. [24] also defined three metric groups that can be directly applied to design components. The metrics in the first group, service internal metrics, use service internal elements such as service name, operations provided by the service, and characteristics of the messages defined in the service. The second group of metrics is service external metrics that use information from services they are connected to. Metrics in this group are used to measure the characteristics of the consumer and producer services that are either directly or indirectly connected to a given service. The last group is system metrics. The metrics in this group are used to measure the characteristics of the entire system in general.

Table 1 Relationship between Design Properties and Quality Attributes [24]
Full size table

In Table 1, an up/down arrow means increase/decrease of the attribute vis-à-vis an increase/decrease of the respective property.

3 Existing Migration Techniques/Tools

From Section 2, we can summarize the techniques and tools that support the migration as follows.

The information summarized and tabulated in Table 2 can be used to choose from among the techniques and tools available for each step of the migration process.

Table 2 Methods/Techniques Used in the Migration Process
Full size table

4 Conclusions

In this paper, several approaches for migrating legacy systems to SOA architecture are investigated and the main processes and tools of each approach are captured and analyzed. The different approaches are compared and contrasted based on their key features and their target legacy system types. Using this comprehensive comparative analysis, businesses can create tailor-made approaches that could best fit their needs and satisfy their requirements.