Introduction to the Migration from Legacy Applications to Service Provisioning

1

Copyright © 2013, IGI Global. Copying or distributing in print or electronic forms without written permission of IGI Global is prohibited.

Chapter 1

DOI: 10.4018/978-1-4666-2488-7.ch001

INTRODUCTION

Nowadays, the business landscape is profoundly influenced by changing ownership paradigms. On one hand, the complexity of software appli-cations has continuously increased mainly due to incorporation of advanced technologies; this

phenomenon has critically required a “divide et impera” approach, leading to a wide distribution of resources, activities, artifacts, and projects. This distribution can be seen from several points of view:

• Technical: With the rise of the distributed processing era in 1990 (Greenfield, 2004);

Anca Daniela IonitaUniversity “Politehnica” of Bucharest, Romania

Introduction to the Migration from Legacy Applications

to Service Provisioning

ABSTRACT

Despite the clear advantages of Service Oriented Architecture (SOA) and Cloud Computing environ-ments, enterprises are strongly chained to their business tradition; they cannot easily give up to their legacy because they have made significant investments in the form of money, people, regulations, and technology. They see the advantages of migrating to a service provisioning architecture for adapting to new technology and business models, and for facing globalization challenges and change of ownership paradigms. At the same time, they realize that migration to SOA and Cloud Computing environments is a complex endeavor, requiring business reanalysis, code reengineering, automatic transformations, architectural changes, new strategies, well-defined methods, and, last but not least, assessment of eco-nomical impacts.

This chapter presents the fundamental ideas related to migrating legacy applications to service-oriented systems, and provides an overview of the available approaches that are presented in this book. The goal is to provide a “big picture” while also analyzing each chapter and indicating the way it covers several essential concerns, such as state-of-the-art, methods, standards, tools, business perspective, practical experiments, strategies, and roadmaps.

2

Introduction to the Migration from Legacy Applications to Service Provisioning

• Managerial: With the proliferation of multi-partner projects, or by outsourcing part of product development and services to third-parties;

• Geographical: Working with and for peo-ple worldwide, and relocating certain ac-tivities of business processes.

The degree of globalization continues to increase and has gone through three important stages (O’Brian, 2008):

• International: With foreign subsidiaries based on local information systems;

• Global: Including worldwide operations;• Transnational: With central information

systems supported by the Internet.

One can see that, apart from decomposing—sustained by the first part of the Latin maxim “divide”—there is an increasing need of the second part: “impera.” This is expressed as new approaches and trends for sharing resources, con-necting people, offering support for collaborative work, or managing software artifacts.

In this context, ownership is also much more distributed than before, requiring better specifica-tion of agreements between partners; interoper-ability support represents a priority for technical stakeholders. One way of dealing with these challenges is a shift towards service provisioning, based on advanced Information Technology (IT) infrastructures, platforms and software, as well as on a holistic approach that involves specialists from economy, engineering, social sciences, and arts (Donofrio, 2010). This trend is also influenced by an increase in the workforce in the service sector, which is valid for countries with various levels of development (Sporer, 2007).

However, enterprises are not in a hurry to give up to their legacy and abruptly switch to service-oriented systems. The main reason is economic because business processes cannot be suddenly modified and introduction of new technology has its costs. Therefore, it is more and more clear that

the transition towards completely new systems is rarely an option. Except for startups, it becomes vital for enterprises to reuse their legacy systems as application front-ends and back-ends. It is also important to do it in a gradual manner. Indeed, there are quick solutions for moving applications to run on Cloud infrastructures (Varia, 2010), but this is only possible under certain condi-tions: statelessness and decoupling from external agents. It is difficult to conform to the latter and, at the same time, stay aligned with current trends. Generally, the move towards service provision-ing requires supplementary work for wrapping or completely reengineering existent code; buying new services, platforms or infrastructures; reana-lyzing business requirements; and conducting a forward-engineering process with the constraint of reusing as much as possible.

This chapter introduces the background of migrating legacy applications in the larger context of software maintenance and reuse. After that, it presents an overview of approaches for migrating to Service-Oriented Architecture, Cloud Comput-ing environments, and related service-oriented approaches. Finally, it analyzes several concerns regarding migration to service provisioning and indicates the book chapters where these concerns are covered in detail.

BACKGROUND

Why Do We Need to Make Changes?

As previously stated, software has to enable busi-ness operations in an environment characterized by globalization, increased competition, and mobil-ity. This requires enterprises to rapidly adapt to changes in the business environment. However, the monolithic and highly coupled nature of many applications precludes them from responding to new functional and non-functional requirements. For attracting new customers and supporting a rapid growth, often based on mergers and acquisi-tions, the information systems used by enterprises

3


should be able to adapt to new rules, regulations and policies; changes in operating conditions; and redesign of business processes. Therefore, maintenance continues to represent an important challenge, as discussed in detail in Chapter 2.

Software dynamics are still subject to Lehman laws (Lehman, 1997), including:

• “Continuous change” of requirements, en-vironments and business rules;

• “Increasing complexity” of software systems;

• “Self regulation” determined by the domain specificity and the end-user community;

• “Organizational stability,” judged as the transparency of the global, distributed management style;

• “Conservation of familiarity” needed by traditional users;

• “Continuing growth” of the back-end sys-tem; and

• “Declining quality” in the absence of pro-active measures.

Why Do We Need to Preserve Legacy?

The development of completely new systems, adapted to the current trends, would involve complex development cycles, high costs, plus the need to maintain the old system during this endeavor. This represents an effort that cannot be supported by those who have already invested in their information systems and have trained per-sonnel to work with them.

The need to preserve legacy contains multiple aspects that are common to the advantages of reuse: taking advantage of software that has been exten-sively tested in real life, reducing risk, preserving domain knowledge, and speeding up the process for reaching current business objectives. It often represents low-scale reuse, performed for creating a new version that is ready for reusing at a larger scale. Service orientation is considered among the most important reuse techniques, along with

libraries, program generators, configuration tools, product lines, or component based development (Sommerville, 2006).

Moreover, in order to create reusable entities out of existent assets, and preserve part of the legacy, it is often necessary to restructure the system. The need for reengineering for legacy migration is outlined in Chapter 4, and the differ-ences between reengineering and migration are further analyzed in Chapter 7.

Why Do We Need to Migrate?

Software maintenance can have four possible goals:

1. Corrective,2. Adaptive,3. Preventive, and4. Perfective (Lientz, 1980).

The first one concerns typical life cycles and does not relate to our concerns. However, all the other three are valid for transforming a mono-lithic legacy system into a service-oriented one because they concern the adaptation to a new environment—new infrastructure, platforms, or business rules. It can be considered as a method for preventing maintainability problems, which often involves radical changes such as reconsider-ing the software architecture. Last but not least, even if functionality or quality improvements are not explicitly planed, this kind of maintenance has a very clear goal of modernization, and many non-functional properties are changed.

According to the staged model of software lifecycle (Bennet, 2000), after the initial develop-ment, maintenance is composed of three phases:

• Evolution: When adaptation and correc-tion are done without restructuring or sub-stantial changes;

• Servicing: When patches and wrappers are introduced with the inevitable effect of damaging the architectural integrity;

4


• Phase-out: When it is only possible to work around for preserving the application in use.

The question is what place legacy migration has in such a lifecycle. Taking into account the versioned staged model (Bennet, 2000), one can create a new version for keeping the software in the beneficial stage of evolution, which can be accomplished by migrating the application to a service-oriented system. The new architecture can be preserved for a longer time and future changes can be delegated to lately bounded services, often replaceable and supplied by third parties. This can be done by adopting a SOA framework or a Cloud Computing environment, offering software, platforms or infrastructure as a service.

MIGRATION TO SERVICE PROVISIONING

A Framework for Migrating to SOA Environments

SOA is capable of solving problems of integrating software supported by heterogeneous platforms and of using various data formats, based on loose coupling between the assembled parts. The main reason is that a client is not directly connected to a service provider, but rather discovers the services that serve its needs and can then choose among similar offers, based on functions, semantics, and other properties such as Quality of Service (QoS), monitored during the system operation. A client can connect to its provider at runtime, and can also switch to another one dynamically. Besides, these services can be composed inside an application, using one of the following approaches:

1. Orchestration, performed from a higher level of abstraction, generally by executing processes, or

2. Choreography between business processes representing different parties (Peltz, 2003).

Building a service-oriented system, and gain-ing its benefits, is not a simple task. The “Cold Turkey” strategy, based on a sudden withdrawal of the legacy application and its replacement with a new one based on service provisioning, may disrupt business processes. Migration to services responds better to iterative, incremental approaches, as the alternative called “Chicken Little,” which proposes to use gateways between the legacy parts and the new ones. These strate-gies are generic for migrating legacy information systems and were defined in the DARWIN project (Brodie, 1998).

Another important landmark for migration is the “Horseshoe Model,” introduced for integrating software architecture and reengineering (Kazman, 1998). The three sides of the horseshoe are repre-sented by the recovery of the legacy architecture, its transformation, and development based on the desired architecture. This model is described in Chapter 2, in a larger context of reengineering processes for migration to SOA environments, where various derived models are also discussed. An updated version, where the upper level is an enterprise model, was used for defining eight families of SOA migration, based on a system-atic literature review (Razavian, 2010). Winter proposes another version of the horseshoe model, based on metamodeling (Winter, 2007), which is also adopted and applied in the process model described in Chapter 7.

Generalizing these approaches, one can conclude that the reverse engineering side is concerned with legacy system analysis, followed by restructuring and separation of reusable code, and ending with creating a model of the existent system (see Figure 1). The transformations may be conducted according to diverse strategies and methods, and with various tools, for producing a model of the service-oriented system. The forward-engineering side performs identification

5


of service candidates and their specification, fol-lowed by implementation based on reusing legacy assets. Besides these reengineering concerns, one has to add elements that are specific to the SOA architecture, such as service registry and service discovery modules. If the architecture is more advanced, one can also take into account elements for service composition, run-time monitoring, security, and autonomic capabilities for service management (Papazoglou, 2007).

Figure 1 shows a mapping of the book chapters to the Horseshoe Model of migration, as follows:

• Chapter 2: Overviews these topics with a focus on identification of research areas;

• Chapter 3: Covers all these topics as well, presenting a systematic literature review on migration to SOA environments;

• Chapter 4: Covers the lower and the up-per parts of the horseshoe; the model is not explicit, but it provides many practical details about analysis, separation of reus-able code, and service identification and implementation;

• Chapter 5: Provides insight into service identification and specification, based on the SoaML standard modeling language;

• Chapter 6: Describes real life experiments of migration using three different meth-ods, covering analysis and implementation topics and assessing the transformation effects;

• Chapter 7: Has a global coverage because it proposes a comprehensive migration pro-cess based on Model-Driven Engineering.

Specifics for Migrating to Cloud Environments

There are several aspects that separate migration to Cloud environments from migration to SOA environments:

• Cloud Computing intrinsically implies specific requirements such as virtualiza-tion, elasticity, reliability (Jeffery, 2010).

• Generally, Cloud Computing applications are intended to operate on a large scale; the number of users is not possible to predict

Figure 1. Mapping of the book chapters on the horseshoe model of migration

6


and therefore there is a need for elasticity and horizontal and vertical scalability.

• End-users can belong to different third parties that should work as if the software/platform/infrastructure is their own, creat-ing the illusion of ownership for the em-ployees belonging to a given tenant. This creates the need for multitenant architec-tures (Mietzner, 2009), as explained in de-tail in Chapter 8.

• Cloud solutions are more dependent on their specific provider and inter-Cloud interoperability is not a state of practice. There is ongoing research for decoupling application development from their de-ployment and execution environments, and using services offered by external Cloud providers (Petcu, 2011).

• Specific Service Level Agreements (SLAs) are necessary due to the flexibility of the delivery model and of the inherent vari-ability in cloud; they have to be self-creat-ed and negotiated, based on a flexible pric-ing model, and the performance should be monitorable for technical adaptations and legal purposes (Chauhan, 2011).

• However, Cloud Computing does not pro-pose a particular architecture but rather a delivery mode that pushes the service pro-visioning paradigm to an extreme. One might not only give up the ownership of certain services provided by third parties, but the entire application.

Migration to Cloud Environments does not exclude the previously discussed issues related to the Horseshoe Model. The decision-making process is based on the same principle of ana-lyzing the source and the target. One still has to perform business analysis; analysis of the existent code; reengineering; and service development, deployment, and provision. Often, migration to Cloud environment does not exclude migration to SOA environments, because services are the

main composition elements that require a mature architecture for being managed so that system coupling does not get out of control.

Before starting migration, alternative solutions for selecting new Cloud platforms have to be carefully evaluated with respect to business needs. For example, as shown in Chapter 10, the Apache Hadoop Distributed File System (HDFS) is good for “write-once-read-many” workloads, while HBase—a NoSQL database based on Google’s BigTable—is better for random “read-write” op-erations. Apart from the platform, an important issue is also data migration, which generally constitutes an important legacy of the enterprise. An indirect transformation method can be applied, consisting of mapping the source database format (generally a relational one) to a standard interme-diate format, and then mapping this to the target, schema free, document-oriented database, capable of handling large amounts of unstructured data assuring elasticity. An approach based on an RDF (Resource Description Framework) intermediate data model in explained in Chapter 9.

Even if Cloud Computing does not promote a particular architecture, migration to Cloud envi-ronments may also require major changes to the system architecture in order to take full advantage of scalability, virtualization, and autonomy. For instance, given a client-server application, a solu-tion for being able to scale up and down based on demand may be to modularize the server in such a way to create a logical server as a cluster of virtualized servers. For realizing this, Chapter 11 identifies three important issues that have to be solved:

1. Defining a method for allowing servers to discover each other and communicate with each other;

2. Finding a way to replicate user information across a cluster of servers;

3. Creating a proxy for rapidly transmitting high amounts of information from one server to another.

7


Apart from that, one has to add generic com-ponents specific to Software as a Service (SaaS), dedicated for billing, monitoring, security, and, eventually, an Application Programming Interface (API) for different Cloud providers.

From Legacy to Related Service-Oriented Approaches

The world has become service-driven—service sectors are continuously growing and they need to be supported by appropriate technology, methodologies, and policies. This has created an emergence of service-specific paradigms to cover all aspects of services:

• Service Science (Spohrer, 2007): As an integration of service-related areas such as management, marketing, operations, engi-neering, computing, human resource man-agement, and economics;

• Internet of Services (Cardoso, 2009): As a business model and appropriate tech-nologies for using the Internet as a means for delivering and consuming services at a large scale, in a similar way to its current usage for the World Wide Web;

• Service-Oriented Computing (SOC) (Papazoglou, 2008): As a manner of rap-idly developing massive distributed appli-cations, by composing services available over the network.

Some parallels between SOC and Cloud Computing are presented in Chapter 14, which proposes a platform for administration of new and legacy software artifacts. This chapter does not address the complete migration of an application, but rather the migration of its parts to reusable services. Migration of the application as a whole may have no efficiency, so an intermediate situa-tion—between exposing the entire application in a service-oriented environment and rewriting it completely—would be to reuse some of its legacy

components as services, which is also considered in SMART (Service-Oriented Migration and Reuse Technique), where criteria for assessing the candidates’ reuse capabilities and a migration strategy are clearly defined (Lewis, 2008).

Another parallel can be made between the SOA and REST (Representational State Transfer) architectural styles, which are both commonly for interoperability in distributed systems. The former is oriented towards behavior, while the latter to-wards state and resources (see details in Chapter 12). The combination of them can be beneficial for dealing with Cloud Computing challenges. This opens a new migration trend—the adaptation of existing services to RESTful ones. An adaptation framework based on Model-Driven Engineering (MDE) for reengineering and horizontal trans-formations, followed by Service Component Architecture (SCA) for forward engineering, is presented in Chapter 13.

Migration Concerns

Migration complexity leads to a need to analyze it theoretically, to perform research experiments, and to learn lessons from the best practices. Therefore, it has to be treated from multiple points of view to be able to capture the entire picture. Seven main concerns were identified within this book: the knowledge of the existing state-of-the art, the importance of choosing an optimal strategy, following a well-defined migration method, the availability of tools to support the entire migra-tion life cycle, conformance to standards, lessons learned from practice, and pre- and post-migration business analysis.

State-of-the-Art

Migration to SOA environments is currently marked by well-defined methods, strategies and standards, plus a clearly drawn research roadmap; tools are generally borrowed from reengineering and model transformations. Migration to Cloud

8


environments has inherited part of the knowl-edge gained from the experience of migration to SOA environments, but it clearly needs specific methods and tools for introducing architectural modules that enable virtualization and elasticity to leverage the application performance.

Strategy

The strategies intend to guide decisions that are made during the entire migration life cycle, start-ing with the analysis of motivation and potential benefits, and ending with the direct or gradual replacement of the legacy system. They may integrate points of view of the multiple stake-holders involved, including economists, project managers, software engineers, and experts in the application domain.

Methods

Migration methods are based on raising the level of abstraction, adapting conceptual aspects for supporting service orientation, then developing the new application based on the co-existence of services originated from the legacy code and new services, developed in-house or delivered by third parties.

Tools

Migration can be a very laborious task, which has triggered the development of tools that auto-mate, or at least assist, certain steps of migration methods. Because service provision includes aspects of engineering and management, the land-scape includes code reengineering tools, model

Table 1. Mapping of book chapters to migration concerns

Chapter No. Chapter Title

State-of-the-

art

Strategy Methods Tools Standards Practice Business

1 Introduction to the Migration from Legacy Applications to Service Provisioning Y Y Y

2 Research Challenges in the Maintenance and Evolution of Service-Oriented Systems Y Y

3 Legacy to SOA Evolution: A Systematic Literature Review Y Y

4Reengineering and Wrapping Legacy Modules for Reuse as Web Services (Motivation, Method, Tools, and Case Studies)

Y Y Y Y Y

5 Service Identification and Specification with SoaML Y Y Y

6 The SOA Frontier: Experiences with 3 Migration Ap-proaches Y Y Y Y Y

7 Model-Driven Software-Migration: Process Model, Tool Support, and Application Y Y Y Y Y

8 Moving to SaaS: Building a Migration Strategy from Concept to Deployment Y Y Y Y

9 Migration of Data between Cloud and Non-Cloud Datastore Y Y

10 Migrating a Legacy Web-Based Document-Analysis Ap-plication to Hadoop and HBase: An Experience Report Y Y Y Y Y

11 Geographically Distributed Cloud Based Collaborative Application Y Y Y

12 Bridging the SOA and REST Architectural Styles Y Y

13 Considerations of Adapting Service-Offering Compo-nents to RESTful Architectures Y Y Y Y Y

14 Model Driven Integration of Non-Homogeneous Soft-ware Artifacts in Service Oriented Computing Y Y Y

9


transformers, modeling editors, code generators, configuration systems, and decision support environments.

Standards

Interoperability of SOA solutions has been a dis-tinct focus of research and industrial communities. Many standards have been defined for service modeling, description, discovery, and orchestra-tion. Important organizations that support some of these standards include the Object Manage-ment Group (OMG) and Organization for the Advancement of Structured Information Standards (OASIS). Cloud environments are currently more focused on individual producers, but migration can still take advantage of existing standards related to services. Interoperability between Clouds, even if far from reaching its maturity, has attracted ac-tivities of multiple organizations, like Distributed Management Task Force (DMTF), Open Cloud Consortium (OCC), The Open Group, etc.

Practice

There are two types of practical experiments, (1) academic case studies for assessing new methods and tools, and for creating a comparison framework; and (2) real-life projects that have to deal with their limited time and cost resources and outline new challenges for researchers. This book presents experiments from both categories for migration to SOA and Cloud environments.

Business

Business is the main driver for all migration ef-forts; it imposes non-functional requirements for software development and constraints for project management. A realistic estimation of the Return Of Investment (ROI) to create a well-founded business case are essential for choosing the right strategies, methods and tools. Alignment between business and IT concerns represents one of the current challenges.

Table 1 shows which of these migration con-cerns are addressed in each of the book chapters for benefit of the readers.

CONCLUSION

Migration of legacy applications to service provisioning environments relies on mature software engineering disciplines in areas such as maintenance, reengineering, and reuse to take advantage of their methods and tools. However, specific challenges remain, some of them related to the service foundation and others specific to the approach (SOA or Cloud Computing). Even if traditional models prove to be useful, this research and practice area has to define its own strategies, methods, tools, for supporting the entire life cycle, and for keeping a constant alignment with business needs.

REFERENCES

Bennett, K. H., & Rajlich, V. T. (2000). Software maintenance and evolution: A roadmap. In A. Finkelstein (Ed.), Proceedings of the Conference on the Future of Software Engineering, (pp. 3-22). ACM Press.

Brodie, M. L., & Stonebraker, M. (1998). Mi-grating legacy systems: Gateways, interfaces & the incremental approach. San Francisco, CA: Morgan Kaufmann Publishers Inc.

Cardoso, J., Voigt, K., & Winkler, M. (2009). Service engineering for the internet of services. Lecture Notes in Business Information Processing, 19, 15–27. doi:10.1007/978-3-642-00670-8_2

Cervantes, H., & Hall, R. (2004). Autonomous adaptation to dynamic availability using a service-oriented component model. In Proceedings of the 26th International Conference on Software Engineering, (pp. 614-623). Washington, DC: IEEE Computer Society Press.

10


Chauhan, T., Chaudhary, S., Kumar, V., & Bhise, M. (2011). Service level agreement parameter matching in cloud computing. In Proceedings of the World Congress on Information and Com-munication Technologies (WICT), (pp. 564-570). WICT.

Donofrio, N., Sanchez, C., & Spohrer, J. (2010). Collaborative innovation and service systems: Implications for institutions and disciplines. In Grasso, D., & Burkins, M. (Eds.), Holistic Engi-neering Education. Berlin, Germany: Springer.

Fielding, R. T. (2000). Architectural styles and the design of network-based software architectures. (Ph.D. Dissertation). University of California. Irvine, CA.

Greenfield, J., & Short, K. (2004). Software factories: Assembling applications with pattern, models, frameworks, and tools. New York, NY: Wiley Publishing.

Jeffery, K., & Neidecker-Lutz, B. (2010). The future of cloud computing: Opportunities for European cloud computing beyond 2010. Geneva, Switzerland: European Commission, Information Society and Media.

Kazman, R., Woods, S., & Carrière, J. (1998). Requirements for integrating software architec-ture and reengineering models: CORUM II. In Proceedings of the Firth Working Conference on Reverse En-gineering (WCRE), (pp. 154-163). Washington, DC: IEEE Computer Society Press.

Lehman, M. M. (1996). Laws of software evolution revisited. In C. Montangero (Ed.), Proceedings of the 5th European Workshop on Software Pro-cess Technology (EWSPT 1996), (pp. 108-124). London, UK: Springer-Verlag.

Lewis, G., Morris, E., Simanta, S., & Smith, D. (2008). SMART: Analyzing the reuse potential of legacy components in a service-oriented archi-tecture environment. Technical Note CMU/SEI-2008-TN-008. Retrieved from http://www.sei.cmu.edu/library/abstracts/reports/08tn008.cfm

Lientz, B. P., & Swanson, E. B. (1980). Software maintenance management: A study of the main-tenance of computer application software in 487 data processing organizations. Reading, MA: Addison-Wesley.

Mietzner, R., Metzger, A., Leymann, F., & Pohl, K. (2009). Variability modeling to support cus-tomization and deployment of multi-tenant-aware software as a service applications. In Proceedings of the ICSE Workshop on Principles of Engineering Service Oriented Systems (PESOS), (pp. 18-25). Washington, DC: IEEE Computer Society Press.

O’Brian, J. A., & Marakas, G. M. (2008). Man-agement information systems. Columbus, OH: McGraw-Hill.

Papazoglou, M. P., Traverso, P., Dustdar, S., & Leymann, F. (2007). Service-oriented comput-ing: State of the art and research challenges. IEEE Computer, 40(11), 38–45. doi:10.1109/MC.2007.400

Papazoglou, M. P., Traverso, P., Dustdar, S., & Leymann, F. (2008). Service-oriented computing: A research roadmap. International Journal of Cooperative Information Systems, 17(2), 223–255. doi:10.1142/S0218843008001816

Peltz, C. (2003). Web services orchestration: A review of emerging technologies, tools, and standards. Hewlett Packard, Co. Retrieved March 23, 2012, from http://itee.uq.edu.au/~infs3204/interesting_websites/WSOrchestration.pdf

Petcu, D., Craciun, C., Neagul, M., Rak, M., & Lazcanotegui Larrarte, I. (2011). Building an Interoperability API for sky computing. In Pro-ceedings of the International Conference on High Performance Computing and Simulation (HPCS), (pp. 405-411). HPCS.

Razavian, M., & Lago, P. (2010). A frame of refer-ence for SOA migration. Lecture Notes in Com-puter Science, 6481, 150–162. doi:10.1007/978-3-642-17694-4_13

11


Sommerville, J. (2006). Software engineering (8th ed.). Reading, MA: Addison-Wesley.

Spohrer, J., Maglio, P. P., Bailey, J., & Gruhl, D. (2007). Steps toward a science of service systems. IEEE Computer, 40(1), 71–77. doi:10.1109/MC.2007.33

Varia, J. (2010). Amazon web services - Migrat-ing your existing applications to the AWS cloud. Retrieved March 23, 2012, from http://media.ama-zonwebservices.com/CloudMigration-main.pdf

Winter, A., & Ziemann, J. (2007). Model-based migration to service-oriented architectures: A project outline. In H. M. Sneed (Ed.), CSMR 2007 Workshop on a “Research Agenda for Service-Oriented Architecture Maintenance”, (pp. 107–110). Amsterdam, The Netherlands: Vrije Universiteit Amsterdam.

KEY TERMS AND DEFINITIONS

Cloud Computing: It characterizes infrastruc-tures, platforms and software based on a delivery paradigm that distinguish them from the classical ownership, and assumes that any of them can be considered to be a service offered on demand.

Legacy Application: It defines a software system that has been traditionally used within an enterprise and represents one of its important assets, with a strong influence on its business processes, human resources, and clients.

Service: In the context of this book, a service is considered to be an autonomous piece of software designed for being reused and delivered remotely,

based on loose coupling between its provider and its consumer.

Service-Oriented Architecture: It defines an architectural style formed of three basic elements: a service provider that hosts, publishes, and delivers services; a service registry that contains standard descriptions of the published services; a client that is able to discover services from the registry for the need of its application, and to communicate with their providers for consuming them.

Software Maintenance: The life cycle for ap-plication development does not end with delivery of a product to customers. In order to keep the product on the market for a long time, a producer has to perform appropriate changes, which can range from bug corrections to improvements and adaptations.

Software Migration: Unlike “big-bang” modernization, software migration is based on reusing existing legacy assets and on a gradual, incremental path from the old information systems and working styles to the new ones that require adapting to modern technologies and business environments.

Software Reengineering: It represents the modification of existing code for creating a new application with different functional or non-functional requirements.

Software Reuse: Despite continuous changes in the environment, there are elements that are im-mutable or valid for a long time because one has made a huge investment in their implementation. It is critical to preserve these elements and reduce the time and cost of future development, even if it concerns maintaining an existing application or creating a new one.

Documents

Introduction to the Migration from Legacy Applications to Service Provisioning