Figure 2 - uploaded by Marvin Grieger
Content may be subject to copyright.
Restructuring process
Source publication
Enterprises are nowadays increasingly faced with the fact that their information systems have become legacy. A common solution to this problem is to migrate the existing application to a new environment, e.g. to a new platform. Modern platforms often employ the architectural style of service-oriented architecture (SOA), in which an application is c...
Contexts in source publication
Context 1
... initial service design can be seen in Figure 1 (I). The process related to our approach is shown in Fig- ure 2. Based on the initial service design, hierarchical and partitioning clustering are performed to improve it gradually. ...
Context 2
... clusters are then implement- ed by introducing additional composite services, as can be seen in Figure 1 (II). As illustrated in Figure 2, hierarchical clustering con- sists of three activities, which are performed repeated- ly. Each iteration starts by calculating new clusters for a hierarchy layer. ...
Similar publications
The family Thamnocephalidae, especially the genus Branchinella, has become a mélange of genera and species with unclear affinities. A genus level revision of the family, using modern taxonomic standards, is presented. Two distinct subfamilies are recognized, consisting of six genera (including one new genus): Thamnocephalus and Carinophallus gen. n...
Citations
... Several approaches were presented to identify services from legacy software. However, only five approaches [12,13,14,15,16] considered the types of services. ...
... Grieger et al. [16] presented an approach identifying three service types when analyzing legacy code. The first type refers to initial Design services that implement business values. ...
... A number of service type taxonomies exists [2,12,13,14,15,16,24,25] that consider different aspects (e.g., domain specificity, granularity, governance) to distinguish service types. We study and combine these taxonomies and limit ourselves to those services types that are distinguishable at the code level. ...
A common strategy for modernizing legacy systems is to migrate them to service-oriented architecture (SOA). A key step in the migration process is the identification of reusable functionalities in the system that qualify as candidate services in the target architecture. We propose ServiceMiner, a bottom-up service identification approach that relies on source code analysis, because other sources of information may be unavailable or out of sync with the actual code. Our bottom-up, code-based approach uses service-type specific functional-clustering criteria. We use a categorization of service types that builds on published service taxonomies and describes the code-level patterns characterizing types of services. We evaluate ServiceMiner on an open-source, enterprise-scale legacy ERP system and compare our results to those of two state-of-the-art approaches. We show that ServiceMiner automates one of the main labor-intensive steps for migrating legacy systems to SOA. It identifies architecturally-significant services with 77.9% of precision, 66.4% of recall, and 71.7% of F-measure. Also, we show that it could be used to assist practitioners in the identification of candidate services in existing systems and thus to support the migration process of legacy systems to SOA.
... Several approaches were presented to identify services from legacy software. However, only five approaches [12,13,14,15,16] considered the types of services. ...
... Grieger et al. [16] presented an approach identifying three service types when analyzing legacy code. The first type refers to initial Design services that implement business values. ...
... A number of service type taxonomies exists [2,12,13,14,15,16,24,25] that consider different aspects (e.g., domain specificity, granularity, governance) to distinguish service types. We study and combine these taxonomies and limit ourselves to those services types that are distinguishable at the code level. ...
A common strategy for modernizing legacy systems is to migrate them to service-oriented architecture (SOA). A key step in the migration process is the identification of reusable functionalities in the system that qualify as candidate services in the target architecture. We propose ServiceMiner, a bottom-up service identification approach that relies on source code analysis, because other sources of information may be unavailable or out of sync with the actual code. Our bottom-up, code-based approach uses service-type specific functional-clustering criteria. We use a categorization of service types that builds on published service taxonomies and describes the code-level patterns characterizing types of services. We evaluate ServiceMiner on an open-source, enterprise-scale legacy ERP system and compare our results to those of two state-of-the-art approaches. We show that ServiceMiner automates one of the main labor-intensive steps for migrating legacy systems to SOA. It identifies architecturally-significant services with 77.9% of precision, 66.4% of recall , and 71.7% of F-measure. Also, we show that it could be used to assist practitioners in the identification of candidate services in existing systems and thus to support the migration process of legacy systems to SOA.
... Greiger et al. [11] proposed an approach whose focus is to identify composite services which are the entry points for end users. The approach does not really identify other finer services. ...
Service-orientation views applications as orchestrations of independent software services that (1) implement functions that are reusable across many applications, (2) can be invoked remotely, and (3) are packaged to decouple potential callers from their implementation technology. As such, it enables organizations to develop quality applications faster than without services. Legacy applications are not service-oriented. Yet, they implement many reusable functions that could be exposed as \emph{services}. Organizations face three main issues when re-engineering legacy application to (re)use services: (1) to mine their existing applications for reusable functions that can become services, (2) to package those functions into services, and (3) to refactor legacy applications to invoke those services to ease future maintenance. In this paper, we explore these three issues and propose research directions to address them. We choose to focus on the service-oriented re-engineering of recent legacy object-oriented applications, and more specifically, on JEE applications, for several reasons. First, we wanted to focus on architectural challenges, and thus we choose to \textit{not} have to deal with programming language difference between source and target system. We chose JEE applications, in particular, because they embody the range of complexities that one can encounter in recent legacy applications, namely, multi-language systems, multi-tier applications, the reliance on external configuration files, and the reliance on frameworks and container services during runtime. These characteristics pose unique challenges for the three issues mentioned above.
... Greiger et al. [11] proposed an approach whose focus is to identify composite services which are the entry points for end users. The approach does not really identify other finer services. ...
Service-orientation views applications as orchestrations of independent software services that (1) implement functions that are reusable across many applications, (2) can be invoked remotely, and (3) are packaged to decouple potential callers from their implementation technology. As such, it enables organizations to develop quality applications faster than without services.
Legacy applications are not service-oriented. Yet, they implement many reusable functions that could be exposed as services. Organizations face three main issues when re-engineering legacy application to (re)use services: (1) to mine their existing applications for reusable functions that can become services, (2) to package those functions into services, and (3) to refactor legacy applications to invoke those services to ease future maintenance.
In this paper, we explore these three issues and propose research directions to address them. We choose to focus on the service-oriented re-engineering of recent legacy object-oriented applications, and more specifically, on JEE applications, for several reasons. First, we wanted to focus on architectural challenges, and thus we choose to not have to deal with programming language difference between source and target system. We chose JEE applications , in particular, because they embody the range of complexities that one can encounter in recent legacy applications, namely, multi-language systems , multi-tier applications, the reliance on external configuration files, and the reliance on frameworks and container services during runtime. These characteristics pose unique challenges for the three issues mentioned above.
... Grieger et al. [5] defined three types of services are identified, These are as follows: ...
... Application services can be of four kinds: (1) entity, (2) activity, (3) capability, and (4) process services. Infrastructure services can be of two kinds: (5) communication and (6) utility services. These services are defined as follows: ...
... This means that these services are used by other application services to perform their activities. Helper services are referred by Alahmari et al. [3], Grieger et al. [5] and Fuhr et al. [4]. For example, a helper service provides CRUD functions for another business service [3]. ...
In this paper, we answer a set of research questions that are required to develop service identification approach based on the analysis of object-oriented software. Such research questions are: (1) what is a service, (2) how are services different from software components, (3) what are types of services, (4) what are existing service identification approaches that consider service types into account, and (5) how to identify services based on the object-oriented source code with respect to their types. Our methodology is based on performing a literature review to identify the answers of these research questions. Also, we propose a taxonomy of service types.
... The constructed migration method also comprised an Architectural Restructuring. We realized an evolutionary algorithm to cluster the dialogs based on the extracted dialog flows [9]. Each cluster aggregates dialogs that are related in terms of the underlying business process. ...
Software migration methods enable to reuse legacy systems by transferring them into new environments. Thereby, the method used needs to fit to the project’s situation by considering conceptual differences between the source and target environment and automating parts of the migration whenever suitable. Using an inappropriate migration method may lead to a decreased software quality or increased effort. Various method engineering approaches have been proposed to support the development of situation-specific migration methods. However, most do not provide a sufficient degree of flexibility when developing a method or fall short in guiding the endeavor. To address this problem, we introduce a situational method engineering framework to guide the development of model-driven migration methods by assembling predefined buildings blocks. The development is centered around the identification of concepts within a legacy system and the selection of suitable migration strategies. We evaluate the framework by an industrial project in which we migrated a legacy system from the domain of real estates to a new environment.
