Web Service Candidate Identification Using the Firefly Algorithm

Web Service Candidate Identification Using the Firefly Algorithm

Negar Abbasi (Department of Computer Engineering, University of Tehran, Kish International Campus, Kish Island, Iran), Ali Moeini (Department of Algorithms and Computation, Faculty of Engineering Science, University of Tehran, Iran) and Taghi Javdani Gandomani (Department of Computer Engineering, Boroujen Branch, Islamic Azad University, Boroujen, Iran)
Copyright: © 2018 |Pages: 16
DOI: 10.4018/IJWSR.2018100103
OnDemand PDF Download:
No Current Special Offers


Identification of web service candidates in legacy software is a crucial process in the reengineering of legacy systems to service oriented architecture. Researchers have proposed various automatic and semi-automatic methods for this purpose, some of which have proved to be quite efficient, but there are still certain gaps which need to be addressed. This article discovers the strengths and weaknesses of previous methods and develops a method with improved service candidate identification performance. In this article, service identification is considered as a search and optimization problem and a firefly algorithm is developed accordingly to give high-quality solutions in reasonably short times. A filtering method is also developed to remove excess modules (false positives) from the algorithm outputs. A case study on a legacy flight reservation system demonstrates the high reliability of the outputs given by the proposed method.
Article Preview

1. Introduction

A brief review of information system development paradigms such as structured development, object-oriented development and component-based development reveals a shift in these paradigms toward features such as higher usability and looser coupling of software components, coarse-grained application level, and wider identification and presentation of system components (Kim & Yun, 2006). These developments have been triggered by changes in service types and business requirements such as agility and rapid adaptation to customer needs, and the need for integration of information systems in competitive environments. Service-oriented architecture (SOA) has emerged from such background.

The main constituent element of service-oriented architecture is the service. Basically, service is a unit of work that can be interpreted and implemented differently depending on the stakeholder’s view point. From a customer’s point of view, it can be a service provided at business level, system designer may view it as a part of the logic of business process, and a programmer may see it as an operation that needs to be performed by a software component (Knipple, 2005). The most important features of service in SOA are autonomy, loose coupling, statelessness, composability, discoverability, reusability, and formal contract in interfaces, which are known as SOA principles (Kim & Yun, 2006).

Legacy systems are those systems that are very difficult to maintain but still retain some value. Maintenance, modification and reuse of the existing legacy systems depend on the extent of success to redefine and remodel them in line with user requirements.

There are many definitions and description for legacy system. Legacy systems are software applications that people do not know how to handle, but still remain vital for the organization. A legacy system can be any information system that is significantly resistant to changes and adaptation to new business requirements. In other words, legacy system is a vital software that cannot be modified effectively (Zhang, Yang, & Chu, 2006). Many of the commercial systems support the core business functions with absolute necessity for the continued functionality of the organization. Thus, mapping of the existing legacy systems to service-oriented architecture has turned into an organizational goal worth pursuing. Legacy systems cannot be simply discarded, as this would mean the loss of time, capital, and human resources spent to design and implement them. A cost-effective mapping requires the spent capitals to be salvaged, or in other words, it requires the legacy systems to be reused in other applications. For the legacy systems to be reused, the services embedded in the legacy systems need to be identified (service candidate identification).

Manual identification of services in a legacy system is a time-consuming effort and requires specialized labor. Hence, an automatic or semi-automatic tool for identification of services in the legacy code could be very convenient. Many researchers have attempted to develop such automatic or semi-automatic tool and there has been some successes in this regard. But there remain some gaps that need to be addressed. The present study aims to overtake this challenge and provide a suitable solution for this problem. The rest of this paper is organized as follows. In the second section, the related work is reviewed; in the third section, the methods of solving the service identification problem are described and the results are presented; and the last section presents the conclusions and suggestions for future work.

Complete Article List

Search this Journal:
Volume 19: 4 Issues (2022): 1 Released, 3 Forthcoming
Volume 18: 4 Issues (2021)
Volume 17: 4 Issues (2020)
Volume 16: 4 Issues (2019)
Volume 15: 4 Issues (2018)
Volume 14: 4 Issues (2017)
Volume 13: 4 Issues (2016)
Volume 12: 4 Issues (2015)
Volume 11: 4 Issues (2014)
Volume 10: 4 Issues (2013)
Volume 9: 4 Issues (2012)
Volume 8: 4 Issues (2011)
Volume 7: 4 Issues (2010)
Volume 6: 4 Issues (2009)
Volume 5: 4 Issues (2008)
Volume 4: 4 Issues (2007)
Volume 3: 4 Issues (2006)
Volume 2: 4 Issues (2005)
Volume 1: 4 Issues (2004)
View Complete Journal Contents Listing