Article Preview
Top1. 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.