A structured legacy to SOA migration process and its evaluation in practice

Method Engineering 2014Presentation by Casper van Schuppen

Background paper

• “A structured legacy to SOA migration process and its evaluation in practice”

• By Khadka, R., Saeidi, A., Jansen, S., & Hage, J. • Conference proceedings; September 2013• Department of Information and Computing

sciences at Utrecht University • ServiciFi project

Purpose

• Legacy systems: potential reuse• Migration of legacy to SOA migration• Deal with multiple perspectives– Technological– Organizational– Business

• Both planning and excecution• Overall process

Six phases

1. LSU: Legacy System Understanding2. TSU: Target System Understanding3. MFD: Migration Feasibility Determination4. CSI: Candidate Service Identification5. Implementation6. D&P: Deployment & Provisioning

Related literature

• Bennett, 1995: one of first reporting on Legacy to SOA migration

• Much published on approaches and techniques– SMART method by Lewis, Morris & Smith (2005)– SOAMIG method by Zillman et al. (2011)

• Prior a SLR by the authors was published resulting in this structured process

• No citations of this paper, because of recency

PDD

• Phases clearly visible• 15 sub-activities• 23 concepts• Additional rules

• But now let’s zoom in!

PDD

PDD

Example

Legacy system at a bank – COBOL based

1. Use tool to extract features from COBOL code2. Features and QA’s: transaction handling & security3. Cost Benefit Analysis: proposed migration realistic?

If so:4. Similar techniques as 1 to extract candidate services5. Architectural appraoch: produce a redeveloped arch.6. WSDL: specify discovery and how to interoperate

References (1/2) Almonaies, A., Cordy, J. R., & Dean, T. R. (2010). Legacy system evolution towards service-oriented architecture. Proceedings of the International Workshop on SOA Migration and Evolution, Madrid, Spain, 53-62. Bennett, K. (1995). Legacy systems: coping with stress. IEEE Software, 12(1), 19-23. Binkley, D. (2007). Source code analysis: A road map. In L.C. Briand and A.L. Wolf (Eds.), 2007 Future of Software Engineering (pp. 104-119). IEEE Computer Society. Brodie, M. L., & Stonebraker, M. (1995). Migrating legacy systems: gateways, interfaces & the incremental approach. San Francisco: Morgan Kaufmann Publishers Inc.. Brown, A., Johnston, S., & Kelly, K. (2002). Using service-oriented architecture and component-based development to build web service applications. Santa Clara, CA: Rational Software Corporation. Cuadrado, F., García, B., Dueas, J. C., & Parada & H. A. (2008). A case study on software evolution towards service-oriented architecture. In Mens, T, Kanellopoulos, Y, Winter, A. (Eds), 2008. AINAW 2008. 22nd International Conference on Advanced Information Networking and Applications-Workshops, (pp. 1399-1404). Glinz, M. (2007). On non-functional requirements. In A.T. Borgida, V.K. Chaudhri, P. Giorgini & E.S. Yu (Eds.), Requirements Engineering Conference, 2007. RE'07. 15th IEEE International (pp. 21-26). Berlin, Germany: Springer-Verlag. Khadka, R., Saeidi, A., Idu, A., Hage, J., & Jansen, S. (2012). Legacy to SOA Evolution: A Systematic Literature Review. In A. D. Ionita, M. Litoiu, & G. Lewis (Eds.), Migrating to SOA and Cloud Environments: Challenges in Service Oriented Architecture and Cloud Computing Environments, (pp. 40 – 70), Hershey: IGI Global. Khadka, R., Saeidi, A., Jansen, S., & Hage, J. (2013a). A structured legacy to SOA migration process and its evaluation in practice. Proceedings of the 2013 IEEE 7th International Symposium on the Maintenance and Evolution of Service-Oriented and Cloud-Based Systems (MESOCA), Eindhoven, The Netherlands, 2-11.

References (2/2) Khadka, R., Saeidi, A., Jansen, S., Hage, J., & Haas, G. P. (2013b). Migrating a large scale legacy application to SOA: Challenges and lessons learned. Proceedings of the 2013 20th Working Conference on Reverse Engineering (WCRE), 2013. Koblenz, Germany, 425-432. Lewis, G., Morris, E., O'Brien, L., Smith, D., & Wrage, L. (2005). SMART: The service-oriented migration and reuse technique (No. CMU/SEI-2005-TN-029). Pittsburgh: Software Engineering Institute. Lewis, G., Morris, E., & Smith, D. (2006). Analyzing the reuse potential of migrating legacy components to a service-oriented architecture. Proceedings of the 10th European Conference on the Software Maintenance and Reengineering, 2006. Bari, Italy, 9-23. Nasr, K. A., Gross, H. G., & van Deursen, A. (2013). Realizing service migration in industry—lessons learned. Journal of Software: Evolution and Process, 25(6), 639-661. Razavian, M., & Lago, P. (2010a). Towards a conceptual framework for legacy to soa migration. In Dan, A., Gittler, F., Toumani, F. (Eds.), Service-Oriented Computing. ICSOC/ServiceWave 2009 Workshops (pp. 445-455). Springer Berlin Heidelberg. Razavian, M., & Lago, P. (2010b). A frame of reference for SOA migration. In Di Nitto, E., Yahyapour, R. (Eds.), Towards a service-based internet (pp. 150-162). Springer Berlin Heidelberg. Sneed, H. M. (1995). Planning the reengineering of legacy systems. IEEE software, 12(1), 24-34. Weerd, I. van de, Brinkkemper, S. (2008). Meta-modeling for situational analysis and design methods. In M.R. Syed and S.N. Syed (Eds.), Handbook of Research on Modern Systems Analysis and Design Technologies and Applications (pp. 38-58). Hershey: Idea Group Publishing. Zillmann, C., Winter, A., Herget, A., Teppe, W., Theurer, M., Fuhr, A., Horn, T., Riediger, V., Erdmenger, U., Kaiser, U., Uhlig, D. & Zimmermann, Y. (2011). The SOAMIG Process Model in Industrial Applications. Proceedings of the 2011 15th European Conference on Software Maintenance and Reengineering, Oldenburg, Germany, 339-342.

Appendix

Functionalities A description of the functionalities of the target system. Subsequently this list is reduced to a list of more vital (core) f unctionalities.

Long list of functionalities <a long list of all the desired functionalities of the “to-be” system>

Selection of (core) functionalities <a shorter list of the main (core) functionalities of the target system>

Non-functional requirements For each of the non-functional requirements, an overview of the different expectations and requirements are given below.

Quality of Service expectations <expectation on the QoS>

Other non-functional requirements <for each relevant non-functional requirement provide information of the expected demanded>

Example TSU document template

Appendix

Non-functional requirements For each of the relevant non-functional requirements, an overview of the different expectations and requirements are given below.

Non-functional requirements

Security Every connection needs to be secure in the system. This is by far the most important quality of service and it is expected this to be, both in communication to other services (acting as a service) and the architecture or software itself.

Performance The transactions need to be completed within a certain time frame, this should not take more than a second. Furthermore, at peeks the architecture would require much transactions to be processed concurrently. This requires the software, and thus architecture, to facilitate a certain (estimated) capacity.

Availability During working hours the systems needs to be available, because the bank employers rely on the use and correct functioning of the system and cannot do their job properly. Scheduled downtime for system maintenance is acceptable. If services, such as internet banking, are linked to the software, it should however be taken into account to announce scheduled downtime.

Interoperability

Non-functional requirements from the Bank case