Geographically Distributed Cloud-Based Collaborative Application

The amount of multimedia content on the Internet has been growing at a remarkable rate, and users are increasingly looking to share online media with colleagues and friends on social networks. Several commercial and academic solutions have attempted to make it easier to share this large variety of online content with others, but they are generally limited to only sending Web links. At the same time, existing products have not been able to provide a scalable system that synchronizes disparate Web content sources among many users in real-time. Such a goal is especially desired in order to provide the benefits of cloud deployments to collaborative applications. Many Web-based applications cannot predict the number of connections that they may need to handle. As such, applications must either provision a higher number of servers in anticipation of more traffic, or be faced with a degradation of the user experience when a large number of clients connect to the application. Cloud-based deployments can alleviate these issues by allowing the application’s server base to auto scale based on the user demand. A cloud deployment can also employ servers in different geographic locations in order to offer better latency and response times to its clients. Moving a collaborative application from using a single server to a cloud and then to a distributed cloud is not a trivial matter, however. This chapter will show our experience with how such a transition can be performed, and will present the architectural changes that had to be implemented at the server and cloud level in order to create a distributed execution that resides in the cloud.

Migration of Data between Cloud and Non-Cloud Datastores

The on demand services and scalability features of cloud computing have attracted many customers to move their applications into the cloud. Therefore, application, data access, storage, and migration to and from cloud have garnered much recent attention, especially with well-established legacy applications. Cloud service providers are following different standards to host applications and data. In the present chapter, the authors focus on data migration from various datastores to cloud and vice versa. They have discussed various challenges associated with this reciprocal migration and proposed a simple yet powerful model whereby data can be migrated between various datastores, especially cloud datastores. The results show an efficient way to move data from conventional relational databases to Google App Engines and how data residing in the Google App Engines can be stored on relational databases and vice versa. They provide a generalized architecture to store data in any cloud datastore. The authors use RDF/RDFS as an intermediate model in the migration process.

The SOA Frontier

Service Oriented Architecture (SOA) and Web Services are the current trend to integrate large and distributed systems, which is a common situation in both the business and government worlds. However, within these worlds, systems are commonly written in COBOL because they were developed several decades ago. Therefore, migration of COBOL systems into service-oriented architectures becomes a necessity. Two main approaches are used to migrate COBOL systems to SOA systems: direct and indirect migration. Direct migration implies wrapping the current COBOL routines of a system with a software layer developed under a newer platform that can be used to offer Web Services. In contrast, indirect migration requires re-designing and re-implementing the COBOL routines’ functionality using a newer platform as well. In this chapter, the authors propose a novel migration approach, which takes the best of the two previous approaches. To assess the advantages and disadvantages of these approaches, this chapter presents a case study from a government agency COBOL system that has been migrated to a Web services-based system using the three approaches. As a result of having these migration attempts, the authors present the trade-off between direct and indirect migration, the resulting service interfaces quality, and the migration costs. These results also show that this new migration approach offers a good balance to the above trade-off, which makes the approach applicable to similar COBOL migration scenarios.

Migrating a Legacy Web-Based Document-Analysis Application to Hadoop and HBase

Migrating a legacy application to a more modern computing platform is a recurring software-development activity. This chapter describes the authors’ experience with a contemporary rendition of this activity, migrating a Web-based system to a service-oriented application on two different cloud software platforms, Hadoop and HBase. Using the case study as a running example, they review the information needed for a successful migration and examine the trade-offs between development/re-design effort and performance/scalability improvements. The two levels of re-design, towards Hadoop and HBase, require notably different levels of effort, and as the authors found through exercising the migrated applications, they achieve different benefits. The authors found that both redesigns led to substantial benefit in performance improvement, and that expending the additional effort required by the more complex migration resulted in notable improvements in the ability to leverage the benefits of the platform.

Introduction to the Migration from Legacy Applications to Service Provisioning

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.

Bridging the SOA and REST Architectural Styles

This chapter proposes a new architectural style, based on a combination of the best characteristics of SOA and REST, which the authors designate as Structural Services. Unlike REST, resources are able to offer a variable set of operations, and unlike SOA, services are allowed to have structure. This style uses structural interoperability, which includes structural compliance and conformance.

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

Service-Oriented Architecture (SOA) is a viable option for systems development, systems integration, and leverage of legacy systems. Despite its positive contributions and potential, SOA has been subjected to significant hype and inflated expectations, and past research efforts in this area have been unfocused. As a result, there is a strong need for systematic and unbiased research. Based on a synthesis of two leading efforts, this chapter presents a framework of research challenges for service orientation and focuses on the topics related to the migration and evolution of service-oriented systems. The chapter reviews current progress as well as gaps in addressing challenges that are derived from the framework.

Model-Driven Software Migration

Established software systems usually represent important assets, which are worth preserving in new software structures, to combine already proven functionality with the benefits of new technologies. The SOAMIG project is aimed at developing an adaptable migration process model with an accompanying tool support based on model-driven technologies. This process model, which combines reverse and forward engineering techniques, was applied in two different case studies on migrating a monolithic software system to service-oriented architecture and to a transformation-based language migration from COBOL to Java.

Model Driven Integration of Heterogeneous Software Artifacts in Service Oriented Computing

Systems evolutivity requires complex operations on services, including migration, duplication, updating, and a number of administration-related actions. However, current environments are heterogeneous and require integration to manage services. It is a complex problem, because it implies a transformation of life cycle related concepts. This integration does not fit very well in the service-oriented approach: indeed this approach is consumer-centered and considers that services are hosted by third parties, while administration is a provider view. Therefore, there is a gap between technologies used to compose applications and technologies that provide them. In the context of system adaptability, this gap becomes a major challenge to be solved. The authors propose an execution environment, which provides a homogeneous service representation used to integrate: their functionalities, their life-cycle and management operations, and lifecycle related concerns, like deployment. Their approach includes two integration mechanisms: the technologies integration supported by wrappers and concerns integration supported by the run-times.

Considerations of Adapting Service-Offering Components to RESTful Architectures

Over the past few years, we have witnessed a paradigm shift on the programming models and on architectural styles, which have been used to design and implement large-scale service-oriented systems. More specifically, the classic message-oriented and remote procedure call paradigm has gradually evolved to the resource-oriented architectural style, inspired by concepts pertinent to the World Wide Web. This shift has been primarily driven by multifaceted functional and non-functional requirements of Web enabled large-scale service offering systems. These requirements include enhanced interoperability, lightweight integration, scalability, enhanced performance, even looser coupling, and less dependence on shifting technology standards. As a consequence, several, and sometimes antagonistic, architectures, design patterns, and programming paradigms have emerged on a quest to overcome the constantly expanding enterprise software needs. In the context of resource-oriented architectures, the Representational State Transfer (REST) architectural style has gained considerable attention due to its simplicity, uniformity, and flexibility. More specifically, the potential for scalability and loose coupling, the uniformity of interfaces, and the efficient bridging of enterprise software systems with the Web are significant factors for software architects and engineers to consider REST when designing, implementing, composing, and deploying service-oriented systems. These issues stir discussion among academics and practitioners about how to properly apply REST constraints both with respect to the development of new enterprise systems and to the migration and adaptation of existing service-oriented systems to RESTful architectures. In this chapter, the authors discuss issues and challenges related to the adaptation of existing service-oriented systems to a RESTful architecture. First, they present the motivation behind such an adaptation need. Second, the authors discuss related adaptation theory, techniques, and challenges that have been recently presented in the research literature. Third, they identify and present several considerations and dimensions that the adaptation to REST entails, and the authors present frameworks to assess resource-oriented designs with regard to compliance to REST. Fourth, the authors introduce an adaptation framework process model in the context of enterprise computing systems and technologies, such as Model Driven Engineering and Service Component Architecture (SCA). Furthermore, they discuss open challenges and considerations on how such an adaptation process to REST can be extended, in order to yield systems that best conform to the REST architectural style and the corresponding REST constraints. Finally, the chapter is concluded with a summary and a discussion on the points raised and on some emerging trends in this area.