Mitigating Mobile Diversity with RESTful Services

Mitigating Mobile Diversity with RESTful Services

Tristan Wehrmaker, Kurt Schneider
Copyright: © 2013 |Pages: 15
DOI: 10.4018/978-1-4666-2199-2.ch005
OnDemand:
(Individual Chapters)
Available
$37.50
No Current Special Offers
TOTAL SAVINGS: $37.50

Abstract

Mobile devices create new opportunities for companies. However, innovative applications can cause challenges for software and system architecture. In this chapter, the authors describe a trap to fall into when starting a promising mobile application in a shortsighted way. When the application gets popular and successful, diversity of mobile platforms increases. Many users have an almost emotional relationship to their own smartphone or platform and may not be willing to change it. In order to make the mobile application available to more users, a company may be tempted to add a “simple” extension to accommodate other platforms. Thus, the diversity in devices leads to diversity in distributed object technologies and with it to problems in complexity and compatibility. The authors describe an approach that counters this problem with RESTful services. They use the ConTexter system for illustrating experiences with the problem and for evaluating a proposed solution. The chapter shows the key issues the authors had to solve while migrating ConTexter to a RESTful platform.
Chapter Preview
Top

1. Introduction

Many people carry smartphones, tablets or other mobile devices with them all the time. More and more companies seize the chance of mobile distributed applications to improve their access to people and the flow of information. In this chapter, we describe an unfavorable trap of shortsighted propagation. It is closely related to the Distributed Disaster anti-pattern described by Brown et al. (2000).

Risky new ideas are typically explored with a small and homogeneous user community to start with. The new application is explored using a single technological platform (e.g., hardware and operating system). Paradoxically, problems arise exactly if those attempts are successful: If the initially small user group likes the application, it is often spread to other people, without careful redesign. When the system spreads beyond its initial target group and throughout the enterprise, diversity of mobile platforms increases. This is the root of the here-described problem. The application that was previously intended as proof of concept turns into an application that is in productive use. There are too many users that have the application installed in their devices and the development team has no access to them anymore. In addition the resources are often too limited to discard the existing application and to start from the beginning. There are good reasons to fall into this trap again and again.

Many users have an almost emotional relationship to their own smartphone or platform. They are not willing to change. In order to make the mobile application available to more users, a company may add a “simple” extension to their server side system to accommodate other platforms – and opt for architectural diversity. At this point add-ons and bypasses start to mess up the initially simple architecture.

Performance and maintainability suffer due to compromised architectural clarity when smartphones, computers and other handhelds introduce diversity. Many diverse implementations of clients and servers have to be maintained, which leads to problems in complexity and compatibility.

The concepts in this chapter were developed upon our experiences with this problem and are reported using the case study of our ConTexter system as presented in Schneider et al. (2010). It is also used to evaluate a proposed solution approach. The development of ConTexter accidentally got lured into the above-mentioned trap. ConTexter is an advanced feedback system. ConTexter is considered as yet another mobile application example with all its strengths and weaknesses. A case study section below describes it in more detail. We discuss the REST architectural style and how it can help to mitigate the above-mentioned problems. We suggest using REST from the start of the development. However, we also present mitigation steps for a situation in which the development already got caught in the trap of shortsighted propagation.

The chapter is structured as follows. Section 2 describes the background of this chapter with explanations of the central terms mobile application and client-server communication in conjunction with an introduction into REST and RESTful services. Section 3 discusses the diversity in mobile applications. It highlights the trap of shortsighted propagation and shows our ConTexter system, which serves as case study and example of how to get caught in the trap. Section 4 will describe how to bypass the trap with RESTful services. This includes recommendations on how RESTful services can be implemented and how to proceed when migrating to technologies for RESTful services. Future research directions will be shown in section 5. It evaluates the proposed solution approach, discusses recommendations on when to use it and describes how it might be improved in the future. Section 6 finally gives a conclusion about this chapter.

Complete Chapter List

Search this Book:
Reset