Document not found! Please try again

LNCS 5214 - Service Extraction from Legacy Systems - Springer Link

7 downloads 6685 Views 227KB Size Report
systems towards Service-Oriented Architectures. This approach is based .... Service Extraction from Legacy Systems. 507. Code View. Logic. Data. UI. External.
Service Extraction from Legacy Systems Carlos Matos1,2 1

Department of Computer Science, University of Leicester, United Kingdom [email protected] 2 ATX Technologies Ltd, United Kingdom

Abstract. This paper presents a methodology for migration of legacy systems towards Service-Oriented Architectures. This approach is based on source code analysis and graph transformation with a central goal of allowing a high degree of automation. The work presented here is developed in the context of a collaboration between academia and industry and is targetted to be applied systematically in software reengineering projects.

1

Introduction

The frequent changes of business requirements and evolution in technology occurring nowadays result in the need to develop new methods to support software evolution and, in particular, the transition of legacy systems to modern architectures. This need is observed frequently over the years and examples include the adoption of object-oriented programming languages, the advent of Web technologies and Service-Oriented Architectures (SOAs). The adoption of SOAs has been growing and is becoming a prevailing software engineering practice [1]. However, experience indicates that SOA initiatives rarely start from scratch. The properties that derive from Service-Orientation include major challenges for reengineering of legacy systems: 1. The separation of business logic from presentation logic 2. The loosely coupled relationship between services 3. The coarse-grained nature of services Legacy systems were not built with these concerns in mind thus much effort is necessary to accommodate them. This paper presents a methodology to address migration of legacy software to SOA while complying to the above properties.

2

General Methodology

Architecture migration involves different types of restructuring. Depending on the intended target, these are made along either technological and functional dimensions or both. The latter is the case of SOAs. Technological restructuring is used in the layering of software systems and may lead to a 3-tiered architecture, H. Ehrig et al. (Eds.): ICGT 2008, LNCS 5214, pp. 505–507, 2008. c Springer-Verlag Berlin Heidelberg 2008 

506

C. Matos  

 

 

!   ! "    !  ! # $  % 

  



     



   









   

     



   

Fig. 1. General methodology

separating logic, data, and user interface (UI). Functional restructuring separates components which, after having replaced their UI tier with an appropriate interface and being grouped according to specific parameters, represent services. The general methodology instanced for both technological and functional dimensions is presented in Figure 1. This consists of the steps: (1) code annotationcategorises blocks of source code according to the different elements of the target architecture they will be mapped to - in the technological dimension this is achieved by using code patterns to identify the parts of the code that belong to UI, Logic and Data; (2) reverse engineering - obtains a graph representation of the annotated code; (3) redesign - uses graph transformation rules to achieve the target architecture - in the technological dimension the rules aim to re-organise the model into a 3-tier architecture, thus complying to the first SOA property from the Introduction; and (4) forward engineering - uses the result of step 3 and traceability to the code (relations R1 and R2 ) to obtain the target code. One of the main goals of this methodology is to allow a high degree of automation. The manual intervention is in step 1 even though this is highly automated as well. A more detailed description of the methodology, and technological dimension, can be found in [2]. The next section details the functional dimension, except steps 2 and 4 as these are similar to the technological dimension.

3

Identification of Services

The functional code annotation phase is performed by two tasks: 1. operation identification and 2. grouping of operations into services. Identifying operation entry points is performed by using a combination of techniques that include: – – – – –

Code belonging to the Logic layer that is invoked by the UI (Figure 2); External API’s (e.g. from IDL files); Code that falls into a typical pattern of control / data flow; Entry point for code that is mapped to more than one operation; Known feature location techniques such as LSI [3] and SBP [4].

The dependencies between each operation entry point and the remaining code can be determined using slicing techniques. The second task of service extraction is where the operations previously obtained are grouped into coherent services. Ranked groupings of operations are proposed by using metrics, including: overlapping between operations, actors involved, information about data accessed

Service Extraction from Legacy Systems

Code View

External interface

507

UI

Logic

Data

Fig. 2. Identification of operations

and similarity measure (e.g. using LSI). The graph transformation rules used in this dimension are designed so that operations are grouped in meaningful services (as per the categorisation) and that services have loosely coupled relations, thus complying to the two last SOA properties mentioned in the Introduction.

4

Conclusion

The main contribution of this work is the definition of a methodology that can be used for service extraction from legacy systems, while having a high level of automation. Code pattern matching and graph transformation are central to achieve this. By applying those in the technological and functional dimensions, the result is a concrete process of addressing SOA migration projects in a systematic way. This work is still ongoing but originated from problems found in projects and is developed in collaboration with the industry. Acknowledgments. This work is partially supported by the IST-FET IP SENSORIA (IST-2005-16004). Thanks to Rui Correia (ATX Software), Prof. Reiko Heckel (University of Leicester) and Dr. Mohammad El-Ramly (Cairo University) for their participation.

References 1. McCoy, D., Natis, Y.: Service-oriented architecture: Mainstream straight ahead. Technical Report LE-19-7652, Gartner Research (April 2003) 2. Correia, R., Matos, C., Heckel, R., El-Ramly, M.: Architecture migration driven by code categorization. In: Oquendo, F. (ed.) ECSA 2007. LNCS, vol. 4758. Springer, Heidelberg (2007) 3. Marcus, A., Sergeyev, A., Rajlich, V., Maletic, J.I.: An information retrieval approach to concept location in source code. In: WCRE, pp. 214–223. IEEE Computer Society, Washington (2004) 4. Antoniol, G., Gueheneuc, Y.G.: Feature identification: A novel approach and a case study. In: ICSM, pp. 357–366. IEEE Computer Society Press, Washington (2005)