Application-agnostic resource-centric service handling support for

Technische Universitaumlt DresdenFakultaumlt Informatik

Master Thesis

Application-agnostic resource-centric service handlingsupport for imperfect networking conditions

Author Anna UtlikMatrikel-Nr 3634515

Institute of Systems ArchitectureChair of Computer Networks

Professor Prof Dr rer nat habil Dr h c Alexander SchillSupervisors Dr-Ing Josef Spillner Dr-Ing Thomas SpringerSubmission date February 28 2013

Service Handling in Imperfect Networking

AufgabenstellungDiese Seite muss vor dem Binden der gedruckten Fassung der Arbeit durch die von HerrnMeiszligner und dem Studenten eigenhaumlndig unterschriebene originale Aufgabenstellung er-setzt werden Das zweite abzugebende gebundene Exemplar soll stattdessen eine Kopiedieser originalen Aufgabenstellung enthalten

Declaration of AuthorshipIn the following I Anna Utlik want to state that this master thesis titled

Application-agnostic resource-centric service handling support for imperfectnetworking conditions

and the content presented in it are results of my own work All published works of thosewhich were utilized in this thesis are referenced and can be found in the BibliographyAll direct or indirect information taken from external resources is acknowledged and ref-erenced in the Bibliography

Dresden February 28 2013

Service Handling in Imperfect Networking Contents

Contents

1 Introduction 111 Motivation 112 Adressed usage scenarios 213 Research goals and questions 414 Structure 4

2 Background 521 Services in Internet 5

211 General definition of Service 5212 Services in Web 6213 RESTful services 6

22 Service Tooling Support 7221 Service description language WSDL 20 with HTTP binding exten-

sions 7222 Web Application Description Language (WADL) 8223 Swagger 9224 RIDDL 10225 WRML - Web Resource Modeling Language 10

23 Disconnected operation techniques 1124 Summary 12

3 State of the Art 1331 RESTful API analysis 13

311 Design Rules 14312 Criteria of evaluation 15313 Result of evaluation 18314 Conclusion 22

32 Existing Client side solutions 23321 Mobile devices peculiarities 23322 Failure model of RESTful service based mobile application 23323 Client SDKs and API-wrappers 24324 Conclusion 26

33 Related scientific work 27331 Mobile user recovery 27332 FTWeb and Fault Tolerant Web Service Framework 27333 DR-OSGI 28334 FT-REST 28335 Conclusion 28

34 Summary 29

Contents

4 Description of the Concept 3141 Requirement analysis 31

411 Discussion 3242 Logical architecture 3243 Structural architecture 3344 Process architecture 3745 Summary 41

5 Implementation 4351 Development platforms 4352 Overview of the structure 4453 API mapping tool implementation 4454 Client-side library implementation 48

541 Basic components 50542 Extension points 53543 Application specific components 55544 Instantiation variations and configuration 57545 Two-leveled response processing 59546 Integration with legacy code 59

55 Summary 60

6 Evaluation 6161 Test environment 6162 Objective testing 62

621 Test preconditions 62622 Results discussion 64

63 Application creation scenario 69631 Description 69632 Results discussion 69

64 Relation to scientific works 7365 Summary 73

7 Epilogue 7571 Conclusion 7572 Addressed research questions 7673 Future research work 77

A Result of RESTful API analysis 79

B Successful responses distribution 85

C Error and lost responses distribution 87

D WADL description of Couchfunk API 89

Bibiliography 91

Service Handling in Imperfect Networking List of Figures

List of Figures

11 Scenario 1 212 Scenario 2 313 Scenario 3 314 Scenario 4 3

21 Swagger complient RESTful API 922 Swagger complient RESTful API mdash sandbox 9

31 Growth of the APIs during the last years 1332 API protocols share 14

41 Logical architecture 3342 Structural architecture 3443 Request Execution Manager 3544 Request workflow 3745 Execution of request 3846 Interaction with Requests Queue 3947 Process of response handling 40

51 Package diagram of the ReSup 4452 Layered structure of the API mapping plug-in 4553 Data types in ReSup API Mapper 4654 Data structure of the API Mapper 4755 Class diagram of the handler 4756 Class diagram of network awareness components 5257 Output from DemoReSup mdash data from AdministrationConsole 5358 Class diagram of Cache storage 5459 Class diagram of ReSupRequstrsquos family 56510 Instantiation variants of IReSupExecutionManager 58

61 Testing environment 6262 Distribution of successful responses based on network parameters 6563 Distribution of error and lost responses based on network parameters 6664 Cache-hit rate 6865 Average time of test execution 6866 Example Android application 7067 Choice of project source folder and package for future request class 7068 Selecting service description file 7169 Specifying request parameters 71

Service Handling in Imperfect Networking List of Tables

List of Tables

31 Adaptation concepts 1732 Result of API analysis (part 1) 1933 Result of API analysis (part 2) 2034 Result of client libraries evaluation 26

41 Requirements matching 32

61 Requestrsquos set characteristic 6362 Service endpoints with error injection 6363 Service resources with theoretical caching ability 6764 Comparison of characteristics FT-REST vs ReSup 74

A1 Adaptation concepts 79A2 Result of API analysis (part 1) 80A3 Result of API analysis (part 2) 81A4 Result of API analysis (part 3) 82A5 Result of API analysis (part 4) 83

1 IntroductionAs the World Wide Web becomes more enriched with different kinds of informationInternet companies find new ways to expose their internal data and resources Fromuserrsquos point of view interaction with web is not restricted anymore to read-only access toinformation but also includes utilization and modification of data resources for creatingcomplex applications and systems RESTful web services are attracting attention ofbusiness companies as an easy and scalable way to provide interface to the end userBased on the plain HTTP protocol for resource invocation RESTful approach avoids

overhead with auxiliary data used for encapsulating messages in envelopes [AP12] Com-pared with SOAP-based services [MG09] RESTful services are easier to develop and useand additionally due to absence of the auxiliary data they show better performanceThe latter property allows given services to be consumed on the devices with limited

computational power as mobile phones and tablets Thus with simultaneous increasing ofwireless network covered areas it gives people a possibility to access valuable informationin any place any time and from most comfortable terminalIn the following a motivation for the research field is provided Furthermore addressed

problem areas are presented and research questions are discussed At the end an overviewof the following chapters is given

11 MotivationIn the recent years in the Internet business environment RESTful services have appearedas an easy scalable self-descriptive and light-weight alternative to WDSLSOAP servicesStatelessness and utilizing of HTTP as an invocation protocol has become a reason of fastadoption by companies and it has resulted in an enormous growth of RESTful servicesduring last yearsAs a drawback it has led to the lack of standardization and formalized service descrip-

tion Although Roy T Fielding has introduced basic principles of REST [Fie00] and a lotof work has been done in the following works [Api12] [Mas11] [Til08] to determine onegood way of designing RESTful services many proposed implementations bypass someor even all those rules Thus developers are unable to reuse software components re-sponsible for the interaction between the application and the service A in the service BcontextDespite implementation differences services have one major commonality mdash a high

dependency on guaranteed network connection The addressed statelessness preventsservices from keeping any information about client on the service side thus making theclient responsible for maintaining the session integrity and handling its interruption dueto network volatility Mitigating this issue implies writing a fault-handling code that isindividual to every serviceAdditionally a high dependency on external services makes mobile applications unus-

able during a network downtime as no data necessary for applications can be received

1 Introduction

In fact this is up to developer if caching of data and its further reuse from a cache stor-age should be implemented in the application or not However the RESTful paradigmencourages caching and provides sufficient means to benefit from this techniqueThe research field into which this work is embedded covers a provision of service

handling support on the client side in context of unreliable network conditionsThereby the motivation of this work is to solve problems described above efficiently

This implies developing of a client-side library which should be able to serve as a mid-dle layer between the application logic and the RESTful web service interface providingtransparent handling of the networking problem for the end client The final client appli-cation using this library should achieve an asynchrony and sufficient resilience in networkcommunication with the service

12 Adressed usage scenariosIn the following three usage scenarios are introduced showing the application of theintended solution

1 Due to increased computational power of mobile devices a scope of tasks whichcan be accomplished using the latter is also growing People want to be able touse all the familiar services such as social networks on-line storages collaborativedocuments editing etc not only from stationary PC but from their mobile devicesas well as shown in the Figure 11 because most of the time it remains in thearea of an easy access Respectively services are providing convenient APIs Butthey are designed in such way that handling all of services and network faults is adeveloperrsquos concern

Mobile application

System

Service

laquousesraquo

Figure 11 Scenario 1

2 Next scenario depicted in the Figure 12 represents a composite application whichcan integrate a functionality of several servicesAs a popular example a combination of social services (such as Twitter FacebookInstagram etc) in one application can be introduced In this scenario a program-ming code responsible for dealing with the failure behaviors grows proportionallyto the amount of used services

3 Wireless networks due to their inhomogeneous nature are less reliable then wirednetworks Thus mobile devices that depend on such type of connection can faceshort periods of network outage and service downtime If the network connection

Service Handling in Imperfect Networking 12 Adressed usage scenarios

Mobile application

System

Service 2laquousesraquo

laquousesraquoService 1

often disappears and reappears again a user can be confused with what is happeningin the application and can not be sure if all of his actions have been completedsuccessfully or just ignored due to the connection absence The Figure 13 visualizesthe given scenario

wait for network connection

Mobile application Servicelaquousesraquo

System

4 For applications based exclusively on the remote data a presence of the networkconnection is vital Such applications become totally unusable in case of connectionlosses for more then several seconds This scenario can be seen in the Figure 14

Mobile application

Service

laquousesraquoLocal cached data

Use online dataonly if connectionis available

If data is in cache

Service datalaquoextendsraquo

laquousesraquo

System

1 Introduction

13 Research goals and questionsThis work focuses on the mitigating of the possible failures between a mobile client andRESTful web service Within this thesis the following research questions should be an-swered in order to design implement and evaluate the client-based framework for handlingimperfect network conditions in the scenarios given above

bull Which means can be used to achieve a sufficient resilience and reliability of mobileapplication in the heterogeneous network environment

bull How to achieve a non-blocking interaction with the application during the unstablenetwork behavior

bull How to make a fault-tolerant application layer independent from the accessed REST-ful API with the lack of a formalized service description

14 StructureThis master thesis has the following structureChapter 2 at the beginning gives an introduction to the scope of terms used in the

work The notion of the service is explained in general and in details In the Section 22an overview of existing service description methodologies and tools is made The chapterfinishes with an overview of disconnected operations techniques which are used for solvingsimilar problems in Section 23In the Chapter 3 state of the art is presented The chosen research field is dealing

with client problems while accessing resource-oriented services therefore in the Section 31the investigation and comparison of existing production services are presented In theSection 32 the client-service middleware that can possibly mitigate the described faultsis examined An overview of the scientific works on the related topic is given at the endof the chapter in the Section 33Chapter 4 provides conceptual decisions to the research question Logical structural

and process architectures are presented and discussed Decisions which are taken duringthe architectures design are justifiedChapter 5 describes the implementation of the designed solution named in scope of

this work as ReSup It consists of two parts mdash the client-side library and Eclipse plug-infor the service-specific code generation The package structure is presented and explainedfor both parts of the framework Important classes and interfaces are described in detailsChapter 6 introduces the evaluation of the accomplished work Two test cases are

proposed described and performed in order to cover the fulfillment of the defined require-ments by the developed solution Afterwards the results of the evaluation are discussed

2 Background

Given chapter starts with an overview of notions of service web service and RESTfulservice which are fundamental for understanding of the given workComprehensible and detailed service descriptions is a first entry point for developers

who starts to work with web service Well or poorly described service measures the amountof efforts made by developers Therefore an overview of the existing known techniquesand tools for service description is presented Afterwards some of well-known techniquesaimed to cope with connection lost between client and server are described

21 Services in Internet

With the development of informational technologies more and more aspects of human lifeis shifted to the Web As Web became more than just a set of interconnected hypertextdocuments now it integrates resources and functionality as well This allows fast andeasy sharing of information among users extends significantly the amount of availabledata in common and provides new possibilities of building informational systems

211 General definition of Service

In a modern society the notion of service plays significant role Every day people use andhear this word in a different contexts from economical services to technical and internetservices In any case service means the way of how the final product is delivered fromproducer to consumerGenerally every service can be described as an abstract resource with a set of particular

functionality that is provided to end user This functionality is meant to be reusedfor different purposes by different entities Appropriate description of a service is animportant component of service discovery and utilizationNowadays the Internet with its intense expansion also absorbed additional function-

ality which allows it to become tightly integrated into the business sector Real worldservices used to provide goods andor information to people found their incarnation inmodern web technologiesFuture foresees the development of so called Internet of Services (IoS) where organiza-

tions and individuals can find different services on the Internet combine them and easilyadapt them to their specific context [BO12] Although research and development in thisarea is mostly concentrated on technical and IT-oriented services scientific society movestowards unified description [SKS12] for both mdash IT and non-technical real world serviceswith their specific domain semanticsmdash in order to encourage wide web service adoptionand further IoS evolution

2 Background

212 Services in WebReal world services penetration into Web opens new possibilities for service provider com-panies as well as for their customers Business companies strive to reveal open informationabout their products and services via Internet as a way of easy and efficient communica-tion with customers and idea of web services provide all means to do this in an efficientway Exposing a real service as a web service enriches enterprise infrastructure attractsclients ensures integration into business processes within and across enterprisesIn technical terms web service is an abstract description of a software system designed

for interoperable machine-to-machine interaction over a network and as concrete approachfor implementation of this software system Web service exposes standardized interfacesometimes described in machine readable format and makes itself available for interactionwith other parties using collection of open protocols and standards such as TCPIP XMLHTTPOn the conceptual level all services are simply a software component provided through

a network accessible endpoint Difference appears on a technical level as explainedhere [Sne08] From the implementation point of view two distinct service types existmdash resource-oriented and activity-oriented The latter type is usually referred as Bigweb services and they are focused on the actions that a user can perform rather thenon a resource or an object upon which the action is taken The simplest example canbe some banking service with set of transfer withdraw and payment operations In thisexample client doesnrsquot refer to money as an object but to operation he can perform withmoney as an actionThe second type are resource-oriented services which are mentioned in the literature

as RESTful services They focus on distinct data objects (resources) and provide limitedset of operations that can be performed Lately the concept of RESTful services hasattracted a lot of developerrsquos attention what became a central point of interest in givenresearch work

213 RESTful servicesREST is an architectural approach for software systems such as web services which caninteract over network Introduced in the dissertation of Roy T Fielding [Fie00] after sometime it became wide popular and beloved by many developers mostly for itrsquos simplicityMain constraints which were brought up by this architectural style were separation ofclient-server concerns statelessness uniform interface and caching All of this can beachieved with the usage of plain HTTP 11 protocol therefore mostly used in real-worldRESTful services implementationsAs it was mentioned before RESTful services are resource centric every resource has

its unique resource identifier (URI) acts as a service endpoint and could be manipulatedby clients Resource representation is a specific state of an actual resource data and itcan be described within a single request message (eg using query parameters) By thisstatelessness is achieved meaning that the server doesnrsquot keep client state and systembecomes more scalableREST architecture makes extensive use of HTTP 11 features request methods mes-

sage headers and response codes Standard set of HTTP methods so called HTTP verbscorrespond to so named CRUD operations ndash create read update and delete This set is

Service Handling in Imperfect Networking 22 Service Tooling Support

sufficient for resource manipulation and with the usage of HTTP 11 as a base protocolRESTful services expose a uniform interface to a clientIn addition semantics of HTTP verbs supports reliability and performance of service

GET method is considered safe what means that resource will remain unchanged oversome time This ability allows to cache it on a client or server-side Methods PUT andDELETE are considered idempotent In other words applying these methods more thenone time will cause the same effect as if it was invoked once This property allows a saferesending of requests in the situation when imperfect network conditions became a reasonfor a response lost due to a timeout

22 Service Tooling SupportFrom the viewpoint of a client programmer development of the mobile application forRESTful web service is not a trivial task REST had appeared as an architectural stylea set of constraints but not as a specific technology or a set of rules Therefore in everyweb service implementation this recommendations are applied from subjective point ofview As a result there is no standard way of how to create an API as well as no widelyaccepted specification to describe a serviceLack of standardization has led to a large amount of diverse implementations of REST-

ful services which sometimes even violate some of the REST requirements BasicallyREST restricts the interaction interface to 4 main HTTP methods brought by HTTP 11specification and set of standard headers This approach appears under the name underthe name High-REST At the same time service developers are free to implement cus-tom methods and headers in order to describe a data domain in a best way The otherexample is so called Low-REST where only two methods (GET and POST) are used toperform all actions which is known as a tunneling Lack of unified API descriptions es-pecially in machine-readable format has made machine-to-machine interactions and codegenerations very complicated or even impossible Plain-text description which is usuallyprovided is intended only for human understanding thus prohibiting an automated orsimplified development of the client applicationsAs WSDL has proved its usability with SOAP-based services the first attempt was

made in WSDL v20 to adopt this standard for RESTful services as well Such solutionwas not very efficient therefore has not found much appreciation from the developersAs an alternative WADL wad developed Before W3C made a decision about standard-ization of this format even more alternatives has appeared Among the most known areSwagger and RIDDL At the same time other developers claim that RESTful service doesnot require any description language because it suppose to be self-descriptive throughresources representations Development of WRML framework is currently moving in thisdirection

221 Service description language WSDL 20 with HTTP bindingextensions

WSDL is an XML based language for description of web servicesIt describes a service as a collection of network endpoints or ports together with ab-

stract definitions of message port types and operations independently from concrete

2 Background

implementation of data bindings format WSDL 20 [Chi+07] has emerged as an evolu-tion of WSDL 11 and supposed to solve interoperability issues across different serviceimplementationsOne of the most noticeable changes is ltinterfacegt element instead of ltportTypegt

which provides more intuitive description of service interface together with logical group-ing of ltoperationsgt and ltmessagegt elements Along with extended SOAP binding theHTTP binding features were added This binding specification provides a full integrationwith REST as HTTP is the most used protocol in RESTful applicationsNew version of WSDL also added richer possibilities to describe a service interface such

as interface inheritance larger set of Message Exchange Patterns (MEP)1 etcREST is resource oriented while Big web services are service oriented WSDL 20

provides a possibility to describe both SOAP and REST-based implementations of aservice but still it stays way more interface-centric when REST is resource-centricSuch enhanced functionality of WSDL 20 extends the scope of its use increases clarity

and structure in service description at the same time exposing more complexity Despitethe W3C recommendation to use the new WSDL 20 version most of the current systemsand client frameworks support WSDL 11 Adoption of this description language toRESTful services has not become successful as developers try to keep the implementationof service as simple according to the architectural concept announced by REST

222 Web Application Description Language (WADL)WADL specification has been submitted to W3C Consortium by Marc Hadley [Had09](Sun Microsystems Inc2) in 2009 but until now it is not standardizedIt had emerged as an alternative to WSDL 20 with more narrow specification for

describing of RESTful services [Tak+08]WADL is a resource-centric description language that corresponds to resource-oriented

type of services WADL document defines set of resources methods that can be appliedto each of them representation formats and relationship between resources This aspectscan sufficiently describe RESTful service in machine processable formatWhile WSDL 20 is independent from transport protocol WADL can only be used for

applications that rely on HTTP protocol This limitation makes WADL much simplerAs WSDL 20 introduced the extended set of all possible MEP WADL is limited to thosewhich are supported by HTTP although it does not even define them explicitly HTTPprotocol is meant to be stateless except one feature that can violate REST constraint ofstatelessness - HTTP cookies This aspect is supported by WSDL 20 HTTP bindingsby explicit specification of HTTP cookies in contradistinction to WADL which does notsupport any stateful features of HTTPOne of the first who supported WADL was GlassFish3 community Jersey framework for

building RESTful web services with automatic generation of WADL documentation andwadl2java tool for automatic client code generation Restlet4 framework has extensionsfor WADL support

1There are two major message exchange patterns mdash a request-response and a one-way pattern SOAPprotocol defines larger set of patterns In-Only Robust In-Only In-Out In Optional-Out Out-OnlyRobust Out-Only Out-In Out-Optional mdash httpenwikipediaorgwikiMessaging_ pattern

2httpwwworaclecomussunindexhtm3httpglassfishjavanet4httpwwwrestletorg

Although usage of WADL service description should simplify development of clientapplications and generic client-based frameworks as well as automated generation andsimplified maintenance of web service documentation it has not become widely adoptedby production services This leaves a question about standardization of RESTful webservices open

223 Swagger

Swagger is a framework created by Wordnik project5 for their own purposes The mainaim of this framework is to provide tools for developers that help to generate docu-mentation for RESTful API keep it up-to-date when service changes and provide easyuser interface to visualize web service API Swagger does not claim to become a de-factostandard of API descriptions and it does not influence the API style At the same timeSwagger defines itself as an improvement on existing specification as they in distinctionto Swagger do not support legacy systemsSwagger framework is tightly integrated into the serverrsquos code and at the moment there

exist implementations in HTML5 Scala and Java Client libraries for automatic codegeneration from resource declaration document are available for Scala Java JavascriptRuby PHP and Actionscript3 Example of RESTful API user interface generated byframework is depicted on Figure 21

Figure 21 Swagger complient RESTful API

Figure 22 shows a sandbox UI for possible interaction with service API Raw specifi-cation document generated by Swagger framework is provided in Json format

Figure 22 Swagger complient RESTful API mdash sandbox

5httpwwwwordnikcom

2 Background

224 RIDDLRESTful Interface Description and Declaration Language (RIDDL) was proposed in theresearch work [MSW09] as an improvement for existing WSDL 20 and WADL solutionswith the aim to eliminate following drawbacks

bull Service endpoint should not be the part of description as a description should bereusable

bull Transparent modification of existing service and adding the new functionality with-out breaking existing clients

Authors offer simple way to describe tree structure of resources in a way of XML sub-tags [MBS10] In contrast to WADL it is also possible to express reoccurring structureof parameters (with options zeroOrMore onreOreMore optional choice group) RIDDLclaims to be a declaration that supports service composition and evolution in the followingways

Composition Descriptions automatically are mashed together to form a new descriptionwith the elimination of the overlapping trees of resources

Evolution Preserve backward compatibility when the service and its interface changesAs service evolution could be represented by the chain of services each with itrsquos owndescription RIDDL proposal is to mash these description together and form a newdescription representing current version of service

225 WRML - Web Resource Modeling LanguageWRML open source project6 started in July 2011 by Mark Messe In general it is acollection of ideas and solutions related to RESTful web services implementation Itoriginated as resource model diagramming technique to represent resources in a structuredand uniform way As the resource is a main concept of REST architecture uniformity oftheir representations is a vital property for RESTful web services standardizationResource modeling is the first step for building RESTful API of any web service In

order to make structures and behaviors of resources consistent the following resourcearchetypes were proposed and described in following work [Mas11]

Collection is a server-managed directory of resources New resources can be added orexisting resources can be deleted from it In this resource archetype server managesthe id assigning of the newly created resource URI can be look like this

httpapisoccerrestapiorgleagues

Store is a client-managed resource repository Client decides which resource to put andordelete from the store The example URI for this archetype when user wants to createresource named kitty in his store favorites is

PUT users1234favoriteskitty

6httpwwwwrmlorg

Service Handling in Imperfect Networking 23 Disconnected operation techniques

Controller resource models a procedural concept It looks like executable function andusually appears in the URI as a last segment without child resources For examplePOST alerts245743resend

Document is a general concept representing object or database record This resourcearchetype depending on conditions can act as any of aforementioned archetypes

For keeping a clear and clean resource model developers of the API should avoid creatinghybrid types of resourcesIn HTTP the Content-Type header specifies the form of the data in message via

media-type Some of media types are registered by Internet Assigned Numbers Authority(IANA) some of them are vendor specific and WRML proposes a self descriptive media-type applicationwrml The idea is that client developers should rely on self-descriptivefeatures of REST and depend on API specific details as less as possible For exampleMIME type applicationjson declares that message has JSON format but does not spec-ify anything about semantics of the message To solve this problem WRML frameworkuses self-descriptive media type applicationwrml which has two more parameters

format identifies document resource which describes format of message (XML JSON)

schema identifies document resource that describes object details and is independentfrom format parameters value

The example on the Listing 21 below shows WRMLrsquos media type used to describe aPlayer form that is formatted using JSON

Listing 21 Content-type header proposed by WRMLapplicationwrmlschema=httpapischemaswrmlorgsoccerPlayerformat=httpapiformatswrmlorgapplicationjson

23 Disconnected operation techniquesCommon distributed and mobile systems depend heavily on the underlying network con-nection and the common scenario is to report to end user about the network failures whenthey occur so he can proceed with reconnection attempts or restarting the operation Butat the same time it is possible to make the underlying system apply some techniques toincrease the possibility of successful outcome of network operation before reporting thefinal state to the user Such techniques were represented and classified by Mikic-Rakic andMedvidovic in their work [MM06] Roughly they can be grouped as making remote dataavailable locally rerouting requests to similar available nodes and delaying the requestsuntil connection reappears First group contains following methods

Caching mdash storing the data which was accessed already locally

Hoarding mdash pre-fetching the data that might be needed

Replication mdash local copy of remote component and synchronizing changes with it

2 Background

In scope of researched area hoarding and replication are not very efficient Hoardingcauses unnecessary network usage (as result also battery consumption) when pre-fetcheddata is not used afterwards And it can not be used when fetched resources need to be up-to-date as most of resources provided by RESTful services In addition to the same datafreshness restriction replication requires local storage for data which makes it inefficientfor mobile devices Caching instead can be applied especially if application on mobiledevice during its life-cycle is aimed to request the same resource quite oftenSecond group implies redirecting the requests to other similar service endpoints (equiv-

alent service endpoints) if they exist when requested one is unavailable Unlike WSDL-SOAP services RESTful services do not provide endpoint replication which makes thistechnique uselessThird group is represented first of all by the queuing strategy when requests are stored

before invoking and in case of network disconnection invocation can be delayed Al-though this method can be used only when result is not immediately needed systemscan benefit from it if it experiences many short-time network unavailability periods Sim-ilar behavior can help when mobile device has network connection but service itself isnot responding Request can be delayed and repeated after some back-off time which isknown as retry technique

24 SummaryThis chapter gives an overview of a service in todayrsquos world from two main points ofview mdash real-world service and informational service Two implementation concepts of aservice are available nowadays in production mdash SOAP-based and REST architecture Anoverview of them was made in Section 21Later on in Section 22 the most popular and promising among available description

tools and languages for RESTful service were presented These tools do not show thewide adoption by currently functioning services which makes it impossible at the givenmoment to rely on these tools for building generic software solutionsAt the end of the chapter in Section 23 disconnected operations techniques were dis-

cussed Several of them that can improve the overall system reliability in imperfectnetwork conditions were established

3 State of the ArtThe following chapter provides a state of the art overview Research consists of threemain directions mdash RESTful services available in production client-side solutions andscientific works in a problem areaProblem of heterogeneity of existing RESTful APIs was raised in previous chapter

In order to develop one general solution for different services a commonalities in APIimplementations should be revealed Therefore the chapter starts with the analysis ofRESTful APIsSet of reviewed services provides client SDKs for more efficient application development

At the next step such available solutions were analyzed in order to define how do theyactually help programmers and how do they deal with possible network and service errorsFinally analysis of related scientific works concludes the chapter Research in the

next areas was taken into consideration mobile device communication with web basedresource fault tolerance in distributed systems

31 RESTful API analysisNowadays tendency bring the web APIs to the same position as web sites which havebeen growing enormously when the Web era had started[Net12] Starting from few webAPIs in the beginning of 2000th this amount is increasing up to today As reported byweb resource ProgrammableWeb 1 its existence had began with only 32 APIs in summerof 2005 and reached limit of 1000 existing APIs in 3 years Speed of APIs appearancenever slow down and more than 7000 of new APIs were added to this collection in last 7years as can be seen in Figure 312

Figure 31 Growth of the APIs during the last years

1httpwwwprogrammablewebcom

3 State of the Art

What is noticeable last thousand has been added withing only three month Thistendency is caused by the wide adoption of REST paradigm For example statistics ofAPI protocols that are used by governmental APIs is shown in the Figure 323 It provesthat share of almost 70 belongs to RESTful APIs

Figure 32 API protocols share

An exponential growth of web APIs without any standards is resulting in technolog-ical implementation chaos Without provided SDKs client has to construct raw HTTPrequests to access resources and deal with each response individually based on humanreadable documentation which means no effective reuse of client codeAs Steven Willmott has mentioned in his talk Reaching a Million APIs and What to

do When We Get There [Wil12]

For current REST APIs semantics are based to some extent HTTP RESTprinciples and Data type descriptions (which all provide a baseline) but pri-marily on a very large amount of developer interpretation The operationalsemantics of the interactions are effectively hard coded into client side softwaremdash making applications brittle and APIs difficult to re-use in any automatedway Arguably this is a little like writing a new browser for every web site mdasha fun exercise for some but unsustainable at scale

Concerning the current situation with API variety there are some examples of APIcomparison reports like in Adam Parrish article Social network APIs A revised lexicalanalysis [Par10] and in recommendation paper [Api12] from Apigee But none of themprovide full and detailed analysis

311 Design RulesIn this section a set of rules about API design is aggregated from several sources RESTAPI Design Rulebook by Mark Messe [Mas11] Web API Design Crafting Interfaces

2ProgrammableWeb 8000 APIs httpblogprogrammablewebcom201211268000-apis-rise-of-the-enterprise

3ProgrammableWeb 316 Government APIs httpblogprogrammablewebcom20120925316-government-apis-sunlight-labs-congress-noaa-national-weather-service-and-us-postal-service

Service Handling in Imperfect Networking 31 RESTful API analysis

that Developers Love recommendation paper from Apigee [Api12] web-blogs etc Theserules are considered as a good practice by web community and recommended to use inRESTful API development

1 Well designed URIs This implies correct usage of special characters4 avoidingcapital letters appropriate using of nouns and verbs5 using of query component forfiltering and partial responses

2 Request methods should correspond to HTTP method semanticsbull GET must be used to retrieve (read) representation of resourcebull PUT must be used to insert and update resource in the client defined collection

of resourcesbull DELETE must be used to delete resourcebull POST must be used for both ndash creating resource in collection invoking end-

points representing an action

3 Appropriate usage of response status codes eg 2xx success codes should not beused in case of error response

4 Usage of HTTP headers for better specification of resource metadata

5 Correspondence between Content-Type and message Well-formedness of messages

312 Criteria of evaluationSet of APIs chosen for comparison in this chapter contains 12 elements Decision onthe choice of each of them was made based on target area of corresponding web servicesSuch approach allows to embrace different types of data data structures resource typesrequirements Distribution over a target area made it possible to investigate web servicesof different maturity levels find examples of both good and bad practicesFor evaluating of existing API several criteria were chosen which are relevant for client

developers

Data model

Data archetypes mentioned in Section 225 can be used for resource model designAlthough it is not a standard these recommendations help to keep data hierarchicallystructured With such hierarchical model it is easier to create meaningful URI pathswhich are clear and intuitive for developers eg groupsfirst-groupmembersfirst-membername Using verbs in resource naming (eg getFirstMemberName)is a replication of SOAP web service endpoints which are action-oriented In scope ofRESTful concept it may result in large amount of unstructured resources and createdifficulties for developer to understand the API

4To use - instead of _ for hierarchical representation of the structure etc5Nouns are used for resources plural forms mdash for collections of resources Verbs are reserved forcontrollers (actions) and names of CRUD functions should be avoided

3 State of the Art

MIME types of resources

Depending on service nature resources that it provides can be of different types - imagesplain text formatted messages streams video etc MIME types specified by Content-Type header are a metadata for client which gives the possibility to choose appropriatetools to handle this resource

Set of CRUD operations proposed by API with its correspondence to HTTPmethods

According to semantic of HTTP methods GET corresponds to read operation PUT toinsert and update DELETE to delete and POST to create a resource In some APIsHTTP methods are misused as eg using GET for deleting a resource Although some-times it happens due to infrastructural issues (web frameworks supports HTTP 10) inmost cases it might be confusing to the client especially in case of data prefetching orcaching

Message body formats

XML remains one of the most popular format in web JSON appeared as an alternativeto XML It is more lightweight and has a simpler structure Developer will benefit froma possibility to choose between several formats of data representation because it givesmore freedom in client code implementation Although XML and JSON are the mostpopular formats in REST-compliant services other formats also exist eg XHTMLAtom GData PHP arrays etc

Support of HTTP headers

HTTP headers can provide additional metainformation which can be useful for clientsCaching data adaptation performance optimization mdash all these advantages become evenmore important in context of mobile devices and unstable network conditions Althoughusage of some custom headers may be sometimes confusing for clients in specific datadomains they can be used to improve reliability error recovery etc

HTTP response codes

Misuse of response codes may cause problems on client side with the correct understandingof responses For example using HTTP 200 OK status code in response where resourcewas not found with providing human readable message in the body Such implementationbinds client tightly to format and semantic of the message and makes it sensitive forchanges in message structure

Language documentation and tools

Most of RESTful services nowadays provide human-readable documentation overviewGetting started guide list of API methods examples discussion blogs reference mate-rial etc This documentation can be very detailed good structured or can be insufficientfor clear understanding There are some tools like Apiary [Ltd12] and Swagger [TM12]which help to create structured RESTful API documentation As overwhelming majority

of RESTful web services provide only plain-text description the structure content of thisdocumentation examples sandboxes and other developer tools will be taken into account

Formal documentation

As was mentioned in Section 22 formal documentation could be written using WSDL20 WADL or any of existing alternatives But none of them became a de-facto standardfor now although there are WADL support in web frameworks (Jersey Restlet etc)Searching for an appropriate way to describe RESTful services is still in progress

Provided security means

Widely accepted standards of data encryption used with HTTP remain optional in webservice implementation Depending on the type of service it can have sensitive or insen-sitive data can have a possibility of recognizing the user sessions or be totally statelessDifferent standards are used for identifying a user mdash OAuth OpenID HTTP Basic Au-thentication custom authentication schemes etc

Data adaptation

Ability to adapt data to the context of client application makes the web service adaptiveIt means that it can provide different content transformation techniques to adapt it in abest way to a device capabilities Taking into account power issues network cost issuessize issues of mobile devices adaption of received data especially multimedia content arevery importantContent adaptation for mobile devices as classified in the dissertation [Spr04] can be

realized through following concepts as it is shown in Table 31

Table 31 Adaptation concepts

1 Data transformation

a different format of raw data

b composition or decomposition of data

c compression

2 Data replacementa several options possible

b replacement of a resource with description text

3 Data reduction

a providing possibilities to filter selected data

b lossy conversion

c pagination

Provided SDKs

Some of RESTful services provide client SDKs API wrappers or different developer tools(playgrounds sandboxes) It is resource consuming to provide support tools for a variety

3 State of the Art

of programming languages and platforms so usually they are limited to the set of mostpopular Python JavaScript PHP Ruby Java In some cases mobile platforms Androidand iOS are targeted as well Availability of SDKs encourages and accelerate developmentof clients Nevertheless these tools remain specific for web service they represent andcannot be reused in a generic way

313 Result of evaluationFollowing section provides an analysis of RESTful APIs from the viewpoint of mobileclient APIs which were chosen cover next areas social (Facebook Shufflerfm) datastorage (Dropbox Amazon S3) images (Flickr Daisy) audio (SoundCloud) and video(Vimeo) security and management of resources (CloudPassage and Sun Cloud API) opendata (Open 311)Full comparison summary can be found in the Appendix A Following tables 32 and 33

contain an excerpt from analyzed results with five service APIs which will be investigatedmore deeply in the next section

Data Model Most of the chosen APIs have a well-structured resource model whichcorrespond to resource archetypes approach proposed in WRML framework and describedin Section 225 Eight from twelve used APIs have hierarchical resource model whatallows to provide URI of following pattern [resource]id[subresource]

bull Shufflerfm mdash tracksidstream

bull CloudPassage mdash groupsgroupidserversserveridissues

bull Open 311 mdash facilitiesfacilityid

Several APIs do not have a hierarchical resource model Instead resource can be accessedvia query parameter with the method name

bull Flickr mdash apiflickrcommethod=flickrfavoritesremove

bull Vimeo Advanced mdash apirestv2method=vimeogroupsremoveVideo

This approach looks like adaptation of SOAP services to RESTful paradigm Daisy APIhas only one entry point As resources in this service are represented by only one imageand image properties are sent via query parameters such URI structure makes senseExcept of method=singleimage parameter which is obligatory on every request

Message body formats MIME types and format of the responserequest body aretightly connected Based on MIME type a client can correctly interpret the body contentas it is successfully done now in all browsers Inconsistency between MIME types andformat may be considered as a malware and rejected by server or misused by clientsMost of the examined web services use JSON or XML or provide choice among both asresponse body format According to IANA registered and recommended to use MIMEtypes for these formats are applicationjson and applicationxml In the set of comparedAPIs such MIME types were also used

bull textjavascript textplain with JSON message body in service APIs of Flickr Face-book Amazon S3

Table 32 Result of API analysis (part 1)API Facebook Amazon S3 FlickrDescription Social networking ser-

viceStorage service with asimple web interface tostore objects using theAmazon on-line stor-age infrastructure

Online photo manage-ment and sharing ser-vice

Data model Graph Hierarchical structure Methods orientedMIME textjavascript

charset=UTF-8 forJSON responses

imagejpg textplainapplicationxmlbinaryoctel-stream

textxml text-javascript

Format JSON XML (was noticedJSON in one response)

JSON JSONP XMLPHP Serial

CRUD POST is used for bothcreate and updatePUT is not used

All+HEAD GET or POST seman-tic of request is rep-resented via methodquery parameter

Headers E-TagPragmaContent-Length Cache-Control

Request mdash RangeIf-Modified-Since If-Unmodified-Since If-Match If-None-MatchExpect response mdashETag x-amz-datex-amz-security-tokenx-amz-mfa x-amz-delete-marker x-amz-id-2

Response codes Standard customcodes spesified andused by SDKs

Error description inXML

Response XML docu-ment of two types indi-cation error of success

Formal documenta-tion

mdash mdash mdash

Language Docu-mentation

Structured GraphAPI Explorer

Structured description Unstructured API ex-plorer

Security SSL OAuth 20 Custom HTTP schema OAuth 10Data adaptation(Table 31)

1b 1c 2a 3a 3c 1b 1c 3c URL shortening 1c1b 2a 3c

SDKs iOS AndroidJavaScript PHP

SDK for Java NetPHP Ruby AWSToolkit Mobile SDK(Android iOS)

third party API-Kits

bull textxml for XML (Flickr)

bull applicationvndcomsuncloudXxxxxxxx+json for JSON formatted responses in SunCloud API

In addition applicationrss+xml was used for RSS feeds (Open 311) applicationphp forPHP array (Vimeo Data API) and other custom media types

CRUD operations Resource manipulation is made through four main functions CRUDcreate read update delete Normally they correspond unambiguously to HTTPmethods

3 State of the Art

Table 33 Result of API analysis (part 2)API Dropbox SoundcloudDescription File storage and sharing service Sound sharing service with social

featuresData model Mixed hierarchy Hierarchical structureMIME applicationjson applicationjson applica-

tionxml charset=utf-8 au-diompeg

Format JSON XML JSONCRUD GET PUT POST AllHeaders x-dropbox-metadata with con-

tent metadataAccept applicationjsonAccess-Control-Allow-MethodsETag Last-modified

Response codes Standard HTTP error code syn-tax additional info in the bodysome custom errors

HTTP Status Codes

mdash mdash

Structured description examples Structured description APIConsole

Security SSL only OAuth 10 Plain HTTP for public data andclient id SSL OAuth 20

Data adaptation(Table 31)

UTF-8 encoding localization1b 3c

1b 3a 3c

SDKs iOS Android Python RubyJava OSx

Python Ruby PHP Java iOSJavaScript Sound Sharing kitsAPI Console

but sometimes web applications implement action with semantic which do not correspondto method they used for performing this action For example

bull Vimeo Advanced API GET apiv2method=vimeogroupsremoveVideo

bull Dropbox POST fileopsdelete

bull Flickr POST servicesrestmethod=flickrfavoritesremove

First it violates the interface proposed by REST conception second - it may confusedevelopers with indirect functionality and at last it make impossible for clients to retryrequests if needed Using GET method to delete resource is a critical mistake because itconflicts with notion that GET method is safe and resource is read-only so result couldbe safely cached Sometimes systems do data prefetching for faster access of resourcesafterwards In this case resource may never actually be requested by client explicitly butwill be deleted by automatic prefetching requestDaisy Vimeo Data API and Open 311 use just GET request because they provide

read-only resources but sometimes GET request acts as a tunnel for DELETE and PUTrequests when web framework does not support these HTTP methods Taking into ac-count data structures of Flickr and Vimeo Advanced API it is possible to assume thatmisuse of methods is caused by building them on top of existing SOAP web serviceIn the above described situation tunneling for DELETE method should be done via

HTTP POST method which explicitly states its non-repeatable nature

HTTP headers Important HTTP headers which encourage caching are Cache-controlPragma ETag Last-Modified If-Unmodified-Since If-Match Amazon S3 have a big setof custom headers which help in problems troubleshooting via requests tracking DropboxAPI specifies a custom header which provides content metadata Sun Cloud API has anon-obligatory header for specification of the API version that this client was programmedagainst

HTTP response codes In most of examined APIs HTTP response codes correlate withactual state of response so they can be used on client side to identify success of requestwithout reading full response Additionally APIs provide response body with humanreadable description of the error and specific error codes which additionally may be usedby client if API documentation contains their description (eg Amazon S3) FlickrDaisy and Vimeo Advanced APIs do not implement standard HTTP response codes ina proper way In Flickr API success of request can be determined from success tag inXML response document as can be seen from Listing31

Listing 31 Flickr responseHTTP 11 200 OKltrsp stat=failgt

lterr code=1 msg=Collection not foundgtltrspgt

The same situation (Listing 32) is in Vimeo Advanced API

Listing 32 Vimeo Advansed API responseHTTP11 200 OKgenerated_in 00176stat failerrcode 401expl The oauth_token passed was either not valid or has expiredmsg Permission Denied

Daisy API does not handle badly formed requests and in case of any returns only humanreadable description of the error in HTML document

Security Read-only services (as Vimeo Data API Open 311 SoundCloud public data)do not implement any security mechanisms and all requests are done via unsecuredHTTP Daisy and Shufflerfm require application key obtained during the registrationto be included as one of query parameters In CloudPassage application key should beprovided in special request header Vimeo Advanced API Dropbox Flickr require OAuth10 Facebook - OAuth 20 and use secure HTTP Amazon S3 API uses custom HTTPauthentication schema as well as security headers

3 State of the Art

Language documentation All of represented APIs have human-readable documenta-tion more or less structured and detailed Very useful for developers are so named APIplaygrounds where it is possible to try API calls in action In many cases such toolsare much more effective than just explanation From the set of aforementioned APIs thisfunctionality is provided by Facebook (Graph Explorer) Sun Cloud Vimeo AdvancedSoundCloud Flickr

Formal documentation The formal machine-readable documentation written onWADLor WSDL 20 was not presented by any of API documentation

Data adaptation With reference to Table 31 adaptation 1a is provided by Open 311both Vimeo APIs and SoundCloud Composition or decomposition of data (1b) is pos-sible in Facebook (batch requests mdash several API requests in one HTTP call field expan-sion mdash joining several requests in one nesting) Amazon S3 (upload data in parts batchdelete) Dropbox (chunked upload for large files partial retrieval) Also services like Shuf-flerfm SoundCloud Vimeo Dropbox Amazon S3 Flickr and Facebook use paginationfor responses which returns large lists of data Gzip compression (1c) is used by major-ity of compared APIs Several variants of multimedia data (2a) is proposed by VimeoAPI (user pictures of different resolution) Dropbox provides different size of thumbnailsof files to represent them to client api-contentdropboxcom1thumbnailsltrootgtltpathgt Facebook and Flickr also provide variety of picture sizes Possibility to filterdata (3a) with query parameters are present in SoundCloud Facebook Vimeo AdvancedShufflerfm

Provided SDKs Almost every API has SDK for clients API wrappers libraries officialor provided by third party Exceptions are Daisy and CloudPassage Facebook DropboxSoundCloud and Amazon S3 provide SDKs for mobile clients as well (iOS Android)

314 Conclusion

The homogeneity of service APIs is of greatest interest for creating the reusable fault-tolerant software First of all difference is expressed in URI path structure responsecodes uniformity of CRUD operations As it was shown in the previous section RESTfulservices are significantly different from the standard implementation of interface As aresult there are better and worse designed APIs but it is complicated to adjust them allunder one patternAnother result of the investigation is that API developers mostly neglect the caching

headers making it impossible to benefit from HTTP cache on the client side In additionnone of the researched RESTful services provided machine-readable description of theinterfaceDescribed inconveniences complicate the task to create reusable fault-tolerant software

solution applicable to existing production RESTful services

Service Handling in Imperfect Networking 32 Existing Client side solutions

32 Existing Client side solutionsSome of the service APIs described in Section 31 provide client SDK which will beinvestigated and compared Existing features of bad network connection handling andcaching will be investigated

321 Mobile devices peculiaritiesDue to their mobility sizes and multi-functionality the portable devices have peculiaritieswhich influence the development of the applications Some of them are

Power Network interfaces and screen consume most of the battery capacity

Costs Depending on the data plan network connection cost can vary Bigger amount oftransferred data may result in larger monetary costs

Security Devices can be connected to different gateways and hotspots and may have nofirewalls between them and the target resource Usage of wireless connection makesdevices vulnerable to Man-in-the-Middle (MITM) attack

Connection Areas with poor network coverage may cause weak signal or its periodicalabsence which results in continuous searching for the network and reconnecting

Bandwidth Low bandwidth of mobile Internet (GPRS) may cause long delays timeoutsand termination of connection as a result

Abovementioned characteristics should be considered while developing a client applica-tion

322 Failure model of RESTful service based mobile applicationMobile devices are vulnerable to all conditions of the surrounding network environmentand any deviation from normal state can cause a problem Considering basic architecturedevice - network - service following points of possible failure could be determined

1 Devicemdash disconnection from network It may happen due to device settings (whengoing to sleep) lack of signal strength reconnecting to the network with VPNauthorization sudden shutdown

2 Network mdash on the way from client to RESTful service endpoint many differentnetwork nodes may be involved in message transportation Two options should beconsidered

bull Slow connection Due to physical devices network nodes settings architectureand load network may reveal low bandwidth delays and packet loss In thiscase the client will wait for request to complete until some timeout is reached

bull Failure of network node If for some reason connection was interrupted on oneof the network nodes client will receive an HTTP error response

3 RESTful service Failure can occur due to general service unavailability in re-sponse to an incorrectly constructed request or insufficient permissions or internalservice error during dynamic resource generation

3 State of the Art

It is assumed that the service is functioning properly and do not reveal unpredicted be-havior ie resources always correspond to what was requested In this case errors whichcan appear from the service side are predicted and described in service documentationwhat makes it possible for the client to handle them correctly Provided client SDK andAPI wrappers must at least act as a layer of handling and generalizing this kind of failureswrap service errors and represent them in a well-documented form to the client developerFailures connected with network can be partly handled in network libraries (timeout

estimation request retry requestresponse caching etc)In case of device disconnected from network locally cached data may be used to not

interrupt the user interaction with an application until connection is reestablished Alsologging of network operations can be used to recover client after reconnectionAs separation of concerns is a good practice in software engineering mitigating of

failures should be separated from the application logic It could be handled in followinglayers layer of HTTP operations (eg HTTP library) or client side framework (eg APIwrapper)

323 Client SDKs and API-wrappersClient SDK and API wrappers should comprise service semantics simplify access of net-work endpoints (carry a burden of constructing HTTP requests and parsing responses)add fault tolerance to an application It is up to framework designer to decide if just basicfeatures of HTTP connection are needed for the desired functionality or extended features(caching cookies) will also be used The following list contains requirements which cantheoretically be provided by client side frameworks that would be acknowledged by theclient developer

1 Semantic mapping to RESTful service resource model

2 Wrapping general exceptions into more specific exception types

3 General request-retry technique

4 Consideration and utilization of HTTP methods idempotent features

5 Handling of network timeouts

6 Verification of message body integrity

7 Caching of responses

Facebook Facebook client SDK is build upon standard Java HttpUrlConnection Cacheis implemented for responses session parameters and media data (pictures) Before mak-ing a new request an attempt to retrieve cached response is madeFacebook Android SDK provides 3 strategies of executing API requests in UI thread

as asynchronous task and with provided callback interface Timeout parameters couldbe specified only for Batch requests implementation and retry requests technique is notused Implementing a retry strategy is left for a client considerationDue to huge variety of possible responses from the same service endpoint SDK provides

a general interface GraphObject and several derived classes representing objects from a

response These classes can either implement GraphObject interface or be parametrizedby classes implementing this interfaceAll errors are encapsulated in 4 specific exception classes authorization graph object

operation cancel and service error exceptions Any of these exception contains a detailedmessage describing the errorAlthough integrity of received data is not checked by SDK it has additional specific

Android features

bull Standard building blocks of Android application FacebookActivity LoginActiv-ityLoginButton LoginFragment PlacePickerFragment ProfilePictureView

bull LoggingBehaviors Specifies different categories of logging messages that can begenerated

Dropbox Dropbox Android client library is build on top of Apache HttpClient Strategyof request-retry is not implemented either This option is left to developer althoughDropbox service API strictly follows idempotent behavior of requests avoiding misuseSeven subclasses of DropboxException class cover all possible errors from service withcorrespondent explanation for developer as well as IO exception related to network issuesIntegrity of data is not considered by service and library does not provide a possibilityto cache responsesUnderlying HttpClient used for API calls can be customized with socket and connec-

tion timeout values which is 30 sec by default

Amazon S3 Amazon SDK is implemented on top of Apache HttpClient and providestwo possibilities to use S3 API mdash high and low-level High-level approach has easierinterface for developer handles retries of request (up to 3 times by default) makes thedecision of how to upload file mdash using simple or multipart upload Low-level approachgives more control over the uploading process In any case maximum number of retriessocket and connection timeout values size of connection pool can be defined by the clientAmazon SDK provides two main classes for handling all types of errors AmazonClien-

tException and AmazonServiceException The latter one covers all possible errors fromservice side and delivers human readable explanation to developer If request methodis idempotent and error does not depend on client (service unavailable service internalerror) immediate request retry is performed AmazonClientException covers errors onthe client side which service is unaware of like absence of network connection In thiscase responsibility to handle these errors remains on client developerEvery kind of response document is handled by library internally Response metadata

is cached for diagnostic purposes Content-length header is required by Amazon and incase of discrepancy between this value and actual size of content service it will return anerror

Flickr Flickr API wrapper6 is not an official library from service provider but a thirdparty library Due to the specific data model of the service which reflects SOAP-basedservice model the given API wrapper includes a vast amount of data object classeseach of which represent a particular API endpoint response Library uses using Java

6httpcodegooglecompflickrj-android

3 State of the Art

HttpUrlConnection as transport layer and do not implement any special features ascaching or request retry All possible errors are represented by FlickrException classencapsulating error code and text message In general API wrapper does not provideany customization of connection parameters and does not make an access to the servicemore reliable

SoundCloud SoundClound API wrapper does not differ from Flickr in amount of faulttolerance functionality It provides basic wrapping of HTTP requests with the use ofApache HttpClient automatic adding of all necessary headers and receiving the corre-spondent response Unlike aforementioned Flickr API wrapper SoundCloud identifies 3types of exceptions

bull BrokenHttpClientException covers bugs in underlying HTTPClient

bull InvalidTokenException covers networkservice problems

bull ResolverException covers errors with resolving responses

Additionally API provides enclosing service endpoints and also request parameters forresources (users tracks comments) But serialization of response message to data ob-jects is left to client because library provides serialization of responses only to String orJSONObjectAs a summary to all reviewed client libraries provided by services it can be emphasized

that they do not use all possible features of possible errors mitigation on HTTP levelBasic simplification targeted by these libraries is that the client developer receives morecomprehensive API to the service does not deal with construction of raw requests andparsing of raw responses

Table 34 Result of client libraries evaluationmdash Facebook Dropbox Amazon S3 Flickr SoundCloudMapping toresource datamodel

+ + + + ndash

Exception wrap-ping

+ + + ndash +

Request retrytechnique

ndash ndash + ndash ndash

Timeouts ndash + + - ndashData integrity ndash ndash + ndash ndashResponsecaching

+ + ndash ndash ndash

324 ConclusionAnalysis made in the previous section shows that chosen existing client-side solutionsdo not provide proper fault tolerance for the final software product In most cases givenclient libraries act as an API wrapper and overtake responsibility from client developerto produce the specific code for API semantics Only few solutions additionally providesome level of fault tolerance as repetition of unsuccessful requests Nevertheless those

Service Handling in Imperfect Networking 33 Related scientific work

solutions remain tightly bound to RESTful service APIs to which they belong and areunsuitable for reuse with other services Further existence of such client-side solutioncan burden developer even more because in addition to service interface it adds one morelayer of the information to be learned by developer mdash the interface of library itself

33 Related scientific workThe issue of maintaining a stable Internet connection in wireless networks is a well knownproblem of mobile devices Modern distributed applications typically developed on webservices often rely on mobile components which heavily depend on different types ofwireless connection (WIFI GPRS UMTS Wi-Max etc) Apart from instability of ap-plications for mobile devices individually such network problems can cause performanceand monetary costs Many research work has been done in this area in order to achieveresiliency of such application against network volatility

331 Mobile user recoveryIn the following work [Van+03] authors describe the problem of mobile client state recov-ery after the network disconnection and reconnection The goal of this work is to reducecosts of recovery if user was involved into a long Internet transaction which was inter-rupted Notion of Internet transaction (iTX) used in this work is taken from familiarconcept of database transactions and describes the user interaction with one or morenetwork resources with achieving of one or more objectives Proposed solution involveslogging of user state for each step of iTX As initial steps in transaction can branch intoseveral parallel and independent subtransactions it is necessary to track in which sub-transaction user is now and evaluate which actions should and can be recovered By thisproposed solution allows to reuse the current state from the log and do not repeat thesteps of transaction again thus saving the network trafficAlgorithm of the given solution requires continuous computation and updating of an

action graph as well as persistent storage for user states That is why mobile device dueto limited battery memory and processing power is a bad choice for placement of thissolution

332 FTWeb and Fault Tolerant Web Service FrameworkAuthors of FTWeb project [SLM05] and Fault Tolerant Web Service Framework [SF07]both provide a fault tolerant layer for unreliable web servicesThe model proposed in FT-Web provides a software layer that acts as proxy between

client requests and service responses This proxy ensures transparent fault handling forclient by usage of active replication Given approach addresses requirements of highservice availability and reliability for distributed systemsFault Tolerant Web Service Framework project proposes customizable fault-tolerance

connectors between client and service Connector is a software component which cap-tures web service interactions and partially performs built-in fault tolerance actions Itencapsulates pre-processing post-processing of requests and recovery actions that couldbe parameterized by user Connectors reside on a third party infrastructure betweenservice providers and consumers The second notion on which given approach relies is

3 State of the Art

redundant services This is used by recovery strategies which implement passive andactive replication of request between equivalent servicesBoth of these approaches are targeted at SOAP web services and involve third party

component between client and service

333 DR-OSGISolution DR-OSGi described in the paper [KTA09] proposes a systematical handling ofnetwork outages in distributed system in a consistent and reusable way by implement-ing fault tolerant strategies as reusable components Given solution is targeting serviceoriented applications implemented on top of OSGi platform Hardening strategies fornetwork volatility resiliency as caching hoarding replication etc are provided as OSGibundles and could be added to existing applications transparently Although presentedbenchmarks are showing improved results with DR-OSGi when network becomes unavail-able in exchange to small performance overhead solution has a limitation of needlesssystem resources consumption This circumstance prevents it from being widely usedon mobile devices Also underlying OSGi framework restricts the usage of DR-OSGi onplatforms where OSGi is not supported or must be pre-installed manually (Android)

334 FT-RESTThe work in FT-REST [ET12] presents an approach to fault handling in client RESTfulapplications Proposed solution consists of domain-specific Fault Tolerance DescriptionLanguage (FTDL) and client-side library FTDL is used to specify fault tolerance poli-cies for RESTful application which are compiled afterwards by FT-REST framework intoplatform specific code This code module can be added to business logic of applicationand act as a fault tolerant layer between application and RESTful service Authors claimthat this solution brings benefits in programmability mdash by separating the fault toleranceconcern from underlying logic programmer can fully focus on implementing the core ofapplication reusability mdash by reusing XML-based FTDL specification of service betweendifferent applications and across platforms and extensibility mdash by robust extension ofFTDL fault-tolerant strategies instead of writing fault tolerant code FT-REST encapsu-late following fault tolerance strategies retry (reattempting servicersquos endpoint) sequen-tial (iteration through the set of equivalent endpoints) parallel (simultaneous invocationof equivalent endpoints) and composite mdash combinations of aforementioned Howeverclient-side caching and other disconnected operations techniques are not considered inthis work

335 ConclusionMany scientific works are focused on adding the resiliency to a distributed network appli-cations but not much of them consider the client as a point of network and service faulthandling Among the introduced works FT-REST can be considered as highly relatedas it provides fault handling support for the client and is aimed at RESTful systemsHowever there is no works have been found which could provide developers with an out-of-the-box solution that helps to implement RESTful mobile application with necessaryfault tolerance

Service Handling in Imperfect Networking 34 Summary

34 SummaryIn this chapter different RESTful APIs were analyzed Although increasing amount ofthem tries to follow the best practices of REST paradigm obsolete APIs still exist Incase a service provider supplies the developer with client SDK it is strongly recommendedby providers to use it Thus in the Section 32 five of client SDKs were analyzed anddescribed Using them in development brings up the following problems

bull additional level of information to learn

bull additional dependencies to the project

bull diverse application logic for different services

bull impossibility to reuse the code

The chapter concludes by the summary of reviewed research works in Section 33The next chapter introduces the concept of application-agnostic software solution

aimed to deal with the problems related to the given research area

4 Description of the ConceptThe motivation related notions and state of the art were described in the previous chap-ters In this chapter the concept of proposed solution will be presented In the Section 41both functional and non-functional requirements will be discussed Afterwards the struc-ture of the solution will be represented on the conceptual level then discussed in moredetails and concluded with description of the components interaction

41 Requirement analysisBased on the results gained from previous chapter and fault tolerant techniques de-scribed in Section 23 requirements for the intended solution are established in the follow-ing section To summarize all above mentioned and in consideration with given researcharea (mobile nature of client and specifics of RESTful services) next measures can beapplied to improve the overall system reliability caching queuing and asynchronous re-quest invocation request retry Proposed solution should correspond to set of functionaland non-functional requirements Functional requirements specify what system shoulddo and non-functional requirements specify how the system should behave Based onpresented using scenarios following functional requirements are established

Functional requirements

FR1 API mapping tools Framework should provide tools for easy mapping of API end-points to inner system request types

FR2 Service aggregation According to usage scenario 2 possibility to use given frame-work with several different RESTful API should be considered

FR3 Asynchrony Framework should provide asynchrony in accessing server resourcesBy asynchronous request execution it should mitigate errors caused by short-timeconnection losses and quality reduction

FR4 Client-side caching To achieve faster access to resources client-caching techniquesshould be present Additionally cache might be persisted between application ses-sions

FR5 Network awareness Network connectivity should be considered as an applicationfailure factor and be mitigated by framework

FR6 Configurability Framework should be optionally configurable with set of predefinedparameters First of all caching and fault tolerant strategies should be adjustable

4 Description of the Concept

Non-functional requirements

NFR1 Independence Solution should provide generic way to handle different RESTfulAPIs It should not rely on the rules of some specific service API This requirementis one of the most important as it assures reuse of the given solution

NFR2 Lightweight Framework is intended to be used for mobile devices in consequenceto this it should be lightweight Amount of external libraryrsquos dependencies shouldbe minimized and source code should be concise

NFR3 Saving of bandwidth Minimizing of network traffic used to transfer resources fromserver As consumption of resources through network is more expensive comparingto consumption of data from local disk it should save battery power processingpower in some cases also monetary costs

NFR4 ExtensibilityPlatform dependent tools to monitor network connectivity shouldbe easily added Due to several possible solutions to work with RESTful APIsframework should be extensible with plug-ins responsible for conversion of APIdescriptions of different formats to canonical requests

411 DiscussionBased on results from comparison of existing means for work with RESTful web servicesthe following requirements summary can be presented Table 41 shows which from theestablished requirements are satisfied by existing tools As it can easily be seen inde-pendence from data domain can only be satisfied be FT-REST solution Here should bementioned that FT-REST research work do not provide a source code in a free accessthereby it was not possible to test it practically

Table 41 Requirements matchingmdash Facebook

AndroidSDK

Dropbox An-droid SDK

AmazonS3 AndroidSDK

Flickr(flickrj-android)

SoundCloudJava APIWrapper

FT-REST

FR1 3 3 3 3 3 3FR2 5 5 5 5 5 3FR3 5 3 3 5 5 3FR4 3 5 3 5 5 5FR5 5 5 5 5 5 5FR6 3 3 3 5 5 3NFR1 5 5 5 5 5 3NFR2 3 3 3 3 3 3NFR3 3 3 3 5 5 no infoNFR4 5 5 5 5 5 no info

42 Logical architectureLogical architecture depicted in figure 41 is concentrated on satisfying of functionalrequirements Platform dependency or implementation details are not considered on thisstage Architecture comprises five main components

Service Handling in Imperfect Networking 43 Structural architecture

Requests Executor

Cache Request Queue Network Manager

API mapping component

Service

Figure 41 Logical architecture

1 Network Manager

2 Requests Executor

3 Requests Queue

4 Cache

5 API mapping component

API mapping component does transformation of given service description informationto canonical service description which is used in system Service description can beprovided in several forms mdash plain text WSDL WADL Swagger formats etc Givencomponent plays a role of abstracting a specific service description from system so everyservice after mapping is handled in the same way In such way system can aggregate andoperate several servicesCache component is responsible for keeping requested resources in memory andor in

persistent storage Retrieving resources from local cache is much faster than from networksource Additionally it saves bandwidth and battery life on mobile devicesRequests queue component fulfills requirement of asynchrony by putting all outgoing

requests into queue and letting Requests Executor component to execute them whennetwork conditions are favorableNetwork manager is the source of connectivity information for the systemLogical architecture is followed by structural architecture that shows the structure of

the proposed solution in a more detailed way

43 Structural architectureIn the following figure 42 system is depicted from the viewpoint of developer

intraquo

laquotr

nraquo

laquocu

nraquo

Figure 42 Structural architecture

This section provides detailed component analysis and substantiate their functions inaccordance with the requirements In combination both logical and structural architec-tures cover all set of functional and non functional requirements discussed in Section 41

Client and Service Service component in the given figure represents RESTful servicewhich provides API By client in given context the application business logic is meantThis application logic utilizes service API in order to create functionality of application

Request Execution Manager Given component is responsible for requestresponseworkflow It provides interface to the client via which client passes requests and re-ceives responses During the instantiation client can configure some of the network andperformance related parameters

Requests Execution Manager

Fault-tollerant Execution

Controller

Execution Controller

Adaptive Execution

Controller

External service context

Network Errors

Service Errors

Service API

Figure 43 Request Execution Manager

Request Execution Manager is a composite component (Figure 43) that consists ofthe following components

bull Execution controller

bull Fault tolerant execution controller

bull Adaptive execution controller

Execution controller leads the workflow of execution in general It works as a mediatorbetween the other parts of the system Fault tolerant execution controller provides re-sponse error checking makes decision if error can be mitigated by the framework andapplies fault handling techniques As described in Section 322 and shown in the Fig-ure 43 two sources of errors are considered service errors and network errors Adaptiveexecution controller is an optional component which relies on semantics of the serviceand can be configured by client Itrsquos function is to provide automatic adaptation of re-sources retrieved from remote service to the device context As an example differentpictures resolutions and quality can be mentioned or various message formats Such typeof functionality is tightly bounded to the possibilities provided by service thereby thiscomponent is not included in the core structure

Requests Queue Given component maintains the queue of outgoing requests If requestcannot be executed immediately due to network conditions it remains in the queue for agiven time

Network Manager This component is aware of network conditions and supply thisinformation to other components which rely on it (Requests queue and Execution Con-troller)As it is possible to have more than one type of network connection on mobile device

and retrieving information about connection state is associated with inquires to hardwareNetwork Manager must rely on Network Monitoring components which are platformspecific Thus framework can be extended with custom Network Monitoring at thispointGiven component is necessary for saving device power as before making HTTP request

client can decide if it physically possible

Network Monitoring Component As was mentioned before implementation of thiscomponent depends on the underlying platform therefore on the architecture diagram inFigure 42 this component is depicted out of the Core structure scope It provides one ofextension points of proposed framework

Cache Caching component is responsible of maintaining requestresponse cache on mo-bile device Caching strategy is compliant to HTTP 11 protocol specification additionallycan be configured to force or ignore some of constraints in case if it is possible due to thenature of requestCaching component should be responsible for asynchronous cache validation which

should not interfere with main application functionality It plays an important role insaving of network traffic and respectively device power by giving a possibility to avoidround-trip calls to service if resource data is accessed several times during the short period

Canonicalization Component As it was mentioned in previous chapters world ofRESTful services suffers from absence of unified service description format TherebyCanonicalization component is present in the architecture to supply framework withcanonical entities of the requests and responses The most widespread service descriptionsnow exist as plain text which can be understood by human In such situation REST-ful service endpoints corresponding HTTP methods and responses should be transformedmanually by developer If service contains description in one of emerging and gaining pop-ularity formats (eg WADL Swagger) pluggable components can be added to achieveautomatic transformation Thereby proposed framework provides one more extensionpoint Possible set of optional plug-ins is depicted as API Mapping plug-in which is alsonot included into core architecture

Administrative Component Administrative component should collect statistics andmanages the level of information that is printed into log messages

Service Handling in Imperfect Networking 44 Process architecture

44 Process architectureIn the given section the proposed solution is discussed from the behavioral point of viewProcess architecture aims to describe processes which takes place in the system In theFigure 44 sequence of actions is depicted which is applied to client request during itslife-cycle

Creation of canonical request

Check of cache

Scheduling request in queue

Check presense of network connection

Requesting the resource

Handling the response

time signal

Mitigating connection absence

Mitigating service errors

Stage 1

Stage 2

Stage 3

Client initiatesinteraction

Client receivesresponse

Cache hit

Figure 44 Request workflow

Elements with dashed boundaries represent optional actions which are invoked for errorhandling and may not occur under normal working conditionsComplete life-cycle can be divided into three parts

bull Stage 1 Client has an intent to get some resource from server For this purposeneeded information is retrieved from service description and appropriate requestis constructed After this local cache is checked and request life-cycle can becompleted on this stage if corresponding response is found locally Response isconstructed from storage and returned to the client

bull Stage 2 Within this stage request is added to the local queue of requests thatis maintained by framework Until system receives notification about the Internetconnection presence requests remain in the queue There might be a possibility tostore this sequence when application is suspended before all requests has left thequeue and restore the queue after it was resumed

bull Stage 3 Request is going to be sent to target server and eventually error responsecould be received At this stage framework takes the responsibility of evaluationof the error nature and making a decision about possible retry of given requestParameters such as amount of repetitions and back off time between retries are setby default if not provided by client

Further in this chapter these three stages of requestresponse lifecycle are describedand interaction between components is shown on corresponding sequential diagrams

Stage 1 First process which corresponds to stage 1 in Figure 44 is depicted in Fig-ure 45 It gives a detailed overview on the interaction between components from themoment the client invokes the original request up to placing it in the Request QueueTwo main points of this process are constructing of canonical request and check of thecache

Client CanonicalisationComponent

API mappingplugin

Request Execmanager

getCanonicalRequest() getRequest()

APIspecificRequestcanonicalRequest

executeCanonicalRequest()

Cachemanager

configuration

getCachedResponse()

a l tcachedResponse

getResponseTo(request)

responseIsCached = true

responseIsCached = false

generatedResponse

generateResponse()

getResponseFromServer()

responseFromServer

handleResponse()

storeResponse()optional[isCacheable]

responseFromServer

Server

Queue requestfor execution

Figure 45 Execution of request

Preparing the request To prepare the request for execution client must create canonicalrequest from the given service interface description There are several ways of howthis description can be provided The most common option is a plain-text human-readable description in which case client would need to make mapping manuallyusing provided tools Also different API mapping plug-ins can be used to extenda system with additional means to process machine-readable descriptions if any is

provided by the service After a canonical request is created it will be passed toRequest Execution manager for further processing

Check cache If the nature of request allows in the next step Execution Manager checksif the response to this particular request has been received and stored locally Incache hit situation the validity of response is verified Time during which responseis considered as valid can be either specified by service and provided via responseheaders or set by the framework if none is provided In case the response is validthe canonical response object is constructed and returned to client Otherwise cacheshould be updated with newer state of data from the remote server

Stage 2 After the request is placed in the queue the second stage begins Queue ofoutgoing requests and Network Manager are main components at this step Queue is notkeeping requests when it is not necessary therefore in optimal networking conditions assoon as a request enters the queue it is retrieved and forwarded for further processingRequest queue does not decide when to execute request it passes request to ExecutionManagerAs it can be seen from Figure 46 process starts from adding request to the queue

after what immediate check of the network connection occurs For this Network Manageraccesses platform specific Network Monitoring component and if connection is currentlyabsent the system will wait When connection reappears Network Manager notifies theExecution Manager and triggers the execution of the next request from the queue

Request Execmanager

RequestQueue

NetworkManager

Platform Specificnetwork monitoring

addRequest() checkConnection()

canonicalRequest

Service

request

getRequest()

[network connected]

triggerExecution()

wait()

responseFromServer

isConnected()

[network disconnected]

executeRequest()

Figure 46 Interaction with Requests Queue

Stage 3 Third part of the overall process shown in the Figure 47 focuses on responsehandling and repeating of a failed request

Service Request Execmanager

FaultTollerantExecution Manager

sendResponse()

retry()

sendRequest()

Client

checkResponse()

onResponseReceived()

backOffEstimation()

t imeout()

canRetry()

retry()canRetry()

constructErrorResponse()

Request can be repeated

Request is notrepeatable

Response is unsuccessful a l t

Response is successful

constructResponse()

Figure 47 Process of response handling

Received responses are handled by framework on two levels standard HTTP responseswith commonly accepted error codes and canonicalized service responses successful offaulty nature of which might be not obvious If one of the checks returns a confirmationof response error Fault-tolerant Execution component is taking measures to mitigate thiserror At this step next criteria must be considered

bull Retry count have not reached maximum value

bull Request is idempotent and can be retried

When framework receives a negative answer to one of this criteria an error response isconstructed and returned to the client If both returned positive answer two next stepsare taken before Fault-tolerant execution component will retry the request

bull Calculate back off time to not overload the server

bull Wait for given time

When the request outcome is successful and correct response reaches the system it canoptionally be cached on the device and afterwards passed to a client

45 SummaryIn the Section 41 a set of functional and non functional requirements was established anddiscussedThe Section 42 presents a logical architecture which describes the solution on the

conceptual levelIn the Section 43 the analysis proceeds with more detailed architecture involving some

of the implementation detailsThe way of how the components of the proposed solution interact is described in details

in the Section 44

5 ImplementationAfter the concept described in the previous chapter in the following chapter details of theimplementation are explained First the selected technologies are presented Afterwardsarchitectural aspects of the system are introduced They are followed by the implemen-tation details of each component of the proposed solution Finally summary closes thechapter

51 Development platformsAs a base language for implementation Java was chosen There are several reasons behindthis decisionFirst of all Java is platform independent that allows to reuse once designed and written

software Second large amount of third-party libraries is available that cover differentaspects of development It helps to save development time and choose the most suit-able among available tools based on project needs instead of adjusting requirements toavailable tools In the implementation of the described concept following libraries wereusedApache HttpClient

is a library that provides support for the base HTTP protocol Although stan-dard javanet package contains sufficient tools for networking in Java it covers thenetworking in a very extensive way The chosen library is aimed at HTTP levelthus hiding the low-level interactions from the developer Additionally it has morecomprehensive API and is well documented

HttpClient Cacheis an extension to Apache HttpClient that provides HTTP11 compliant cachinglayer Being highly customizable it allows to adjust cache parameters according toapplication needs and device capabilities

wadl4jprovides a simple interface for a WADL service descriptions manipulation It wasdeveloped by Christian Liebing in scope of Dynvocation project 1

Third and most important in context of the given research Java language is used formobile application development Due to its popularity it was chosen by Google as a mainlanguage for third-party applications for Android mobile platform Although insteadof SunOracle Java Virtual Machine an alternative Dalvik Virtual Machine is used inAndroid environment for programmers the process of software development remains thesame mdash familiar coding in Java By this Google ensured the rapid growth of applications

1Dynvocation is a FutureSOA project developed at the Chair of Computer Net-works at the Faculty of Computer Science of the Dresden University of Technologyhttpprojectdynvocationdynvokerorgdynvoker

5 Implementation

which resulted in Androidrsquos strong position on the mobile platform market mdash accordingto the report of BusinessWire 2 from November 1 2012 in the 3rd quarter of 2012 yearmarket share of Android devices has reached 75

52 Overview of the structureThis and following sections present how the application-agnostic resource-centric fault-handling solution referenced in the future as ReSup was implementedFirst of all proposed solution consists of two parts mdash tool for request generation and

library responsible for HTTP-request invocation and mitigation of the possible networkissuesThe figure 51 represents a package structure of the produced code Detailed explana-

tion of the package structure will be presented in following subsections

apimapper

uicomponents

codegenerator

datainterfaces

handlers

datatypes

dataprocessing

orgtudresup

adaptation

entit ies

executionhandlers

network

adcomp

entit ies

pdcomp

network

Figure 51 Package diagram of the ReSup

53 API mapping tool implementationDue to possible overhead during continuous parsing of a service description file for eachintended HTTP request especially on mobile devices necessary requests should be cre-ated by developer and included into application on compilation phase To achieve thisa convenient tool was created called ReSup API Mapper It is provided as an EclipseIDE plug-in that allows programmers to access it easily during development process Itsbasic functionality is to generate request class with the set of predefined parameters

2Android Marks Fourth Anniversary since Launch with 750 Market Share in Third Quarter Accord-ing to IDC httpwwwbusinesswirecomnewshome20121101006891enAndroid-Marks-Fourth-Anniversary-Launch-750-Market

Service Handling in Imperfect Networking 53 API mapping tool implementation

ReSupAPIMapper plug-in provides extension points thus developers can add a customfunctionality for obtaining request parameters from different description filesGeneral structure of the Mapper is presented in the Figure 52 Plug-in contributes to

orgeclipseuimenus and orgeclipseuicommands extension points thus becominga part of IDE Every command which appears in menu is responsible for one strategyof how request code is generated Each command has a corresponding handler Thehandler can utilize different custom data processing components if there is a need toobtain request parameters from description files At the end all necessary informationcollected on previous stage is passed to a code generation component for class sourcecode creation As shown in the figure with a red highlighting to extend solution with one

Figure 52 Layered structure of the API mapping plug-in

more strategy for request code generation a corresponding command for the menu entryshould be added as well as the handler and custom data processing componentsIn the Figure 51 the left subpackage orgtudresupapimapper refers to plug-in im-

plementation Following description of package structure helps to understand it better

UicomponentsThis package contains UI components their models and controllers Pages aselementary UI blocks can form wizards Wizards are started by handlers andlead the developers through the process of assigning request parameters At theend wizard model return all collected data wrapped into OutputRawDataProviderinterface to the handler for further processing

CodegeneratorName of the package is self-explanatory and it contains a RequestCodeGeneratorclass Additionally the given package contains a subpackage with the interfaceOutputRawDataProvider required by the RequestCodeGenerator Aforementionedinterface should be implemented by the component which is able to provide all thenecessary request data

5 Implementation

HandlersEach command entry in ReSup menu needs a handler to start a correspondingwizard and process parameters returned from it They are contained in the givenpackage If chosen strategy implies for example parsing of source description fileresult of such processing can be obtained via IFileParser in a form of datatypesfrom orgtudresupapimapperhandlersdatatypes package

DataprocessingComponents from this package are responsible for parsing of various source dataand constructing datatypesIParcedRequest objects which are further consumedfor creating OutputRawDataProvider objects

Datatypes

During the creation of source code there are two types of data which are required byplug-in The Figure 53 visualizes the scenarios when these datatypes are used

Figure 53 Data types in ReSup API Mapper

First type that is mandatory in every run mdash request parameters collected from thewizard such as destination package destination folder class name request type etcThese data is supplied to the code generator via OutputRawDataProvider interface whichis implemented by the wizard It receives necessary parameters from models of includedpages general information about java file destination folder package subclass andHTTP request parameters The Figure 54 demonstrates the corresponding class diagram

Second type of the data might not appear during class code generation as it repre-sents outcome from a source description file if any is used Such data is provided viaIParsedRequestData interface

Handlers

Handler classes are used to execute the corresponding action represented by a commandentry in the menu The basic workflow for code generation is to start wizard receivecollected data and pass it to RequestCodeGenerator AbstractReSupHandler class en-capsulates the aforementioned workflow and provides the following hook-methods to beimplemented in the subclasses related to corresponding actions

processFile(filePathjavalangString)collectionltIParsedRequestDatagtreturns a collection of IParsedRequestData which corresponds to a list of theavailable endpoints in the service interface

Wizard

-genInfoGeneralInfoPageModel-reqInfoRequestInfoPageModel

all the methods from implemented interfaces

laquoInterfaceraquoOutputRawDataProvider

laquoInterfaceraquoRequestInfoInterface

+getServiceEndpoint()String+getHttpMethod()String+getRestRequestType()String+isCacheEnabled()boolean+getTimeToLive()int+getRequestClassName()String

laquoInterfaceraquoGeneralInfoInterface

+getSourceFolder()String+getPackageName()String+getSuperclassFullName()String+getSuperclassSimpleName()String

GeneralInfoPageModel

RequestInfoPageModel

+RequestInfoPageModel()+RequestInfoPageModel(requestInfoIParsedRequestData)

Figure 54 Data structure of the API Mapper

obtainWizard(handlerIReSupCommandsHandler)AbstractReSupWizardis used to obtain the wizard appropriate for the task this handler is doing

onWizardClosed(dataProviderOutputRawDataProvider shell Shell)voidpasses all the collected information to the code generator

A class diagram of the handler can be seen in Figure 55

RequestGenerator

+generateRestifyRequest(dataProviderOutputRawDataProvidershShell)

RequestGenerationHandler

-wizardDataOutputRawDataProvider

+processFile()+onWizardClosed()+obtainWizard()

AbstractReSupWizard

-genInfoGeneralInfoInterface-reqInfoRequestInfoInterface

methods which provide all necessary data forrequest generation

AbstractReSupHandler

+execute()+processFile()+onWizardClosed()+obtainWizard()

Figure 55 Class diagram of the handler

As the developer presses the finish button in the wizard code presented in the Listing 51is produced as an output from ReSupAPIMapper plug-in Later on in the application thisrequest class can be instantiated and passed to the client library which would proceedwith invocation of the described request

Listing 51 Example of the generated request classimport orgapachehttpHttpStatusimport orgtudresuplibbaseentitiesReSupRequest

5 Implementation

import orgtudresuplibbaseentitiesReSupResponseimport orgtudresuplibbaseentitiesVerifyResponseStatusimport orgtudresuplibbaseenumsHttpMethodimport orgtudresuplibbaseenumsRequestPriorityimport orgtudresuplibbaseenumsRestRequestType

public class SCMeRequest extends ReSupRequest private final static RequestPriority requestPriority = RequestPriorityNORMALprivate final static String serviceEndpoint = httpsapisoundcloudcommejson

private final static HttpMethod httpMethod = HttpMethodGETprivate final static RestRequestType requestType = RestRequestTypeREADprivate final static boolean cachingPrefered = true

public SCMeRequest() super(serviceEndpoint httpMethod requestType requestPriority

cachingPrefered null)

Overridepublic VerifyResponseStatus verifyResponse(ReSupResponse response)

int statusCode = responsegetHttpResponse()getStatusLine()getStatusCode()

boolean success = ((statusCode == HttpStatusSC_OK) || (statusCode== HttpStatusSC_CREATED))

boolean canRetry = thiscanRetryBasedOnMethod()return new VerifyResponseStatus(success canRetry null)

54 Client-side library implementationClient-side library provides reliability and errors mitigation for the application It rep-resents additional level of software built on top of application layer (according to OSImodel) As a base for given implementation Apache HttpClient was chosenThe client-side library fulfills the requirements established in the Section 41 by com-

bining fault handling techniques mentioned in the Section 23From the view point of components affiliation to a development environment they can

be divided into three groups

bull Core components form the basis of the library They are designed to handle allpossible requests from applications in a unified way Given basis provides a varia-tion of instantiation scenarios to a developer with different adjustment parameters(HTTP client configuration cache configuration) which were thought through inaccordance with specifics of mobile RESTful applications

bull Platform specific components represent a group of default components whichare necessary for library functioning Basic set of this components is included into

Service Handling in Imperfect Networking 54 Client-side library implementation

the library and hooks are provided to extend this set with custom components ifnecessary As an example Network Monitoring would have different implementationon Linux and Android

bull Application specific components depend on application domain For examplerequests must be created in the application for receiving data from the serviceThey encapsulate information about the service endpoints Message handlers couldbe added to receive a service data directly transformed into the application specificobjects And if the service provides possibility to adapt a resource representation toclient demands an adaptation component might be used to encapsulate a resourcechoice strategy

As can be seen in the Figure 51 ReSup library implementation consists of two mainpackages and a number of subpackages

Basepackage contains core componentsAdaptation

package provides inner functionality for adaptation of requests and interfaceIAdaptationStrategy for client defined strategies

Cacheconsists all necessary classes to instantiate caching ReSup client and optionallyprovide custom cache storage

Entitiespackage provides superclass for requests as well as response and request call-back interface for client

Enumsdefines a set of necessary constants

Executionhandlerspackage consists of factory that creates requested IReSupExecutionManagerbased on provided parameters

Networkpackage is represented by components responsible for network awareness abil-ity of the solution Interface IReSupNetworkMonitoring should be imple-mented by developer in correspondence with the platform in order to supplyan application with given functionality

Queueconsists of all the classes for queuing functionality

Implpackage contains an example set of platform and application specific componentsnecessary to demonstrate all functionality of the libraryADComp

stands for application specific components such as requests adaptation strate-gies etc

PDCompconsists of platform dependent components (caching storage and network mon-itoring implementations) used for demonstration and testing purposes

5 Implementation

541 Basic componentsThis section provides a description of ReSup basic components and interfaces which theyexpose to each other and to the client

IReSupExecutionManager

The given component delivers an interface to the client for requests invocation The li-brary contains three implementations of this interface one that does not support cachingsecond with caching based on correct cache-control instructions and the last with heuristicapproach to caching IReSupExecutionManager object can be obtained from EManagerFactoryBased on the desired configuration one of the aforementioned implementations is instan-tiatedinvoke(requestReSupRequest) ReSupResponse

provides normal blocking invocation of resource If this method is used the devel-oper himself is responsible for handling of a long execution If this method is calledin UI thread (main thread) on mobile devices and takes long time to complete itcan cause system message about non-responding application

invokeAsynchronously(request ReSupRequest callback RequestCallbackIn-terface)void

executes request in a separate thread and returns the result to a callback object

allowToProceedWithRequest(type NetworkType) voidis called by IReSupNetworkManager when a new request has been added By in-voking this method IReSupExecutionManager gets the information that device iscurrently connected to the network and can proceed with requesting the resourcefrom the service

pauseExecution()voidstops the request invocation when the device disconnected from network

shutDown() voidshuts down the instance of IReSupExecutionManager

IReSupExecutionManager encapsulates all interaction with queue and network com-ponents Responsibility of HTTP message transfer is delegated to a ReSupHttpClientinstance which was made for better separation of concerns ReSupHttpClient appliesrequest retrying strategy making decisions based on request and response parameters aswell as requests preparation (if any adaptation strategy is used) and preliminary responsehandling

BaseQueue

This component is based on javautilQueue As it is known from the official docu-mentation queue is a collection type designed to hold elements prior to its processingIn given implementation ConcurrentLinkedQueue is used as it satisfies requirements toelements order (FIFO) is thread-safe and has unbound size

BaseQueue component partly mirrors the Java Queue interface which is related toadding peeking pooling and removing elements In addition to the basic queuing func-tionality given component performs a check of the duplicated requests if any are received

addRequestToQueue(request ReSupRequest callback RequestCallbackIn-terface)boolean

adds request to the queue if it is new When the same request is detected as alreadywaiting and it is either safe or idempotent this method adds corresponding callbackobject to the collection By doing this it ensures that system do not invoke thesame request multiple times thus saving bandwidth When the result is receivedresponse is returned to all callback objects

peekRequest() ReSupRequestreturns first request from the queue without removing it from there

pollRequest() ReSupRequestreturns first request from the queue and deletes it from the queue

getCallbacks(requestReSupRequest) collectionltRequestCallbackInterfacegtreturn the collection of callbacks waiting for the response to given request Thismethod is called by IReSupExecutionManager when the result from server is re-ceived The result is passed to all awaiting entities

storeQueue() voidstores requests which remain in the queue in case application gets shut downFor using of this option a queue component should be created with appropriateIQueueStorage otherwise this method would do nothing

size() intreturns an actual size of the queue

invalidateQueue() voidremoves all requests that are currently waiting

IReSupNetworkManager

IReSupNetworkManager is responsible for providing a current state of the network con-nectivity to the system To obtain this information this component is registered as anobserver to a INetworkMonitoring component and is notified when the network statechanges From the other hand IReSupExecutionManager component is registered as anobserver to IReSupNetworkManager which can be seen in the Figure 56 In this case anobject implementing IReSupNetworkManager interface is an observable subject and canimmediately give a signal to the system to proceed with execution of the request whenthe connection appears after some downtimeThe following interface is exposed by this component

registerRequestExecutor(mngr IReSupExecutionManager) voidregisters IReSupExecutionManager as an observer If the system is instantiated asnetwork aware it is necessary to register IReSupExecutionManager for updates sothe system can resume invocation of requests from queue and retry those whichreturned recoverable exceptions

updateWithNetworkState(ntwType NetworkType isConnected boolean)void

is used to notify all registered IReSupExecutionManager objects

5 Implementation

laquoInterfaceraquoIReSupNetworkMonitoring

+registerApplicationNetworkManager(nm IReSupNetworkManager )void+notifyINetworkManagers(typeNetworkType isConnectedboolean)void+finish()void

laquoInterfaceraquoIReSupExecutionManager

+allowToProceedWithRequest(typeNetworkType) void+pauseExecution()void

laquoInterfaceraquoIReSupNetworkManager

+registerRequestExecutor( rexIReSupExecutionHandler)void+updateWithNetworkState( typeNetworkTypeisConnectedboolean)void+onRequestAdded()boolean

ReSupNetworkManager-observerscollectionltIReSupExecutionManagergtupdateWithNetworkState(type isConnected) for (IReSupExecutionManager m oservers) if (isConnected) mallowToProceedWithRequest(type) else mpauseExecution()

CustomNetworkMonitoring-observerscollectionltIReSupNetworkManagergtnotifyINetworkManagers(type isConnected) for (IReSupNetworkManager m oservers) mupdateWithNetworkState(type isConnected)

Figure 56 Class diagram of network awareness components

getNetworkType() NetworkTypereturns the current network type It is used for determining of network conditionsand possible usage of adaptation techniques based on this parameters

isConnectionPresent() booleanreturns the current state of network connection

onRequestAdded() booleanis called by IQueue when a new request has been added to a queue Task ofIReSupNetworkManager at this step is to make a decision if connection is presentmdash notify the IReSupExecutionManager and allow it to proceed otherwise waituntil the connection reappear

Administration console and logging

This part of the system is represented by two classes mdash AdministrationConsole andLOGGER LOGGER writes messages of different level to a log and outputs them to consoleby default It can be customized with the level of detalization or turned off

AdministrationConsole can be used to collect statistics for evaluation and debuggingIt provides the following interface to the client

getCacheHit()long and getCacheMiss() longshow statistics of cache performance

getNumOfNewRequestsWhenOnline() int and getNumOfNewRe-questsWhenOffline() int

give number of requests which were sent during the off-line and on-line mode Canbe compared with amounts of successful and error responses afterwards

getNumOfDuplicatedRequests() intreturns an amount of requests which were duplicated in system during the shorttime period and thus only one of them was actually issued upstream to the service

getNumOfRetriedRequests() intreturns statistics about how many times request should be repeated due to IOEx-ceptions of service unavailability

getNumOfDisconnections()int and getNumOfReconnections()intreturn information about the amount of disconnections from network

getNumOfSuccessResponses() int and getNumOfErrorResponses() intprovides number of responses which returned successfully and with errors corre-spondingly

Figure 57 shows the result of AdministrationConsole After a demo applicationDemoReSup has reached the end of execution all gathered statistics was printed out toconsole This data can be used for tracking the runtime state for debugging or testing

Figure 57 Output from DemoReSup mdash data from AdministrationConsole

542 Extension pointsIReSupNetworkMonitoring

IReSupNetworkMonitoring acts as a subject for INetworkManagerComponent The givencomponent monitors system and receives fresh information about current network connec-tivity so as it changes mdash monitoring component updates IReSupNetworkManager withnew network state

registerApplicationNetworkManager(mngr IReSupNetworkManager) voidregister IReSupNetworkManager for receiving updates on network state change

notifyINetworkManagers(ntwType NetworkType isConnected boolean)void

is used to notify all registered IReSupNetworkManager objects

5 Implementation

As cache can be very specific due to device and application requirements developer isgiven a high level of control over the cache storage This part of the library is implementedin accordance with the AbstractFactory pattern described in GoF book3Cache storage is obtained from the factory AbstractCacheStorageFactory provides

an extension point for developers who want to use custom storage types Storageimplementing IReSupCacheStorage interface can be obtained by invoking the methodcreateCacheStorage() on factory object where cacheStorage type is an integer constantspecifying which implementation of IReSupCacheStorage factory must be instantiatedIn the Figure 58 the class diagram of the AbsractCacheStorageFactory can be seen

AbstractCacheStorageFactory

createCacheStorage(cacheConfigCacheConfigcStTypeint)IReSupCacheStorage throws StorageTypeNotFound

laquoInterfaceraquoIReSupCacheStorage

laquoInterfaceraquoorgapachehttpclientcache

HttpCacheStorage

CacheStorageFactory

+IN_FILE_STORAGEint+IN_MEMORY_STORAGEint

+createStorage(IN_FILE_STORAGE)+createStorage(IN_MEMORY_STORAGE)

CustomStorageFactory

+CUSTOM_STORAGEint

+ createStorage(CUSTOM_STORAGE)

InFileStorage InMemoryStorage CustomStorage

Client

Figure 58 Class diagram of Cache storage

By CustomStorageFactory and CustomStorage any factory and storage are representedthat might be developed to cover the application needs and fit the platform requirementsCaching layer works according to RFC2616 4 recommendation based on cache control

headers provided by the server Header values (eg max-age must-revalidate) are usedto estimate if entry can be cached period of validity when it needs to be revalidated etcWith the diversity of RESTful services implementation some of them may not provideexplicit cache control headers In this situation certain entries might also be cached with

3Design Patterns Elements of Reusable Object-Oriented Software by Erich Gamma Richard HelmRalph Johnson and John Vlissides

4httpwwww3orgProtocolsrfc2616rfc2616-sec13htmlsec13

an expiration time set by default One of these two possibilities of how to use cachinglayer (in a generic or heuristic mode) can be chosen via parameter CachingStyle duringinstantiation which is explained in details in the Section544

IQueueStorage

When the application logic foresees that there might be a need to preserve uncom-pleted requests between application shutdown and restart the given component shouldbe created and passed as a parameter during the IReSupExecutionManager instantiationIQueueStorage provides standard interface to BaseQueue persisting and retrieving of arequest persisting and retrieving of a request collection removing separate entries andcleaning the storage

543 Application specific componentsReSupRequest

Request classes within proposed solution are generated via APIMapper tool described inthe Section 53 All custom request classes must extend ReSupRequest and implementabstract methodverifyResponse(response ReSupResponse) VerifyResponseStatus

where service specific logic of response evaluation should be implemented if it dif-fers from standard HTTP implementation VerifyResponseStatus object consists ofthree fields which provide an information to the library on how the response shouldbe treated They are boolean values isResponseSuccessful and canRetry along withoptional human-readable message

For better understanding an example from Flickr RESTful API (presented in Sec-tion 313) can be referenced Conventional error response from Flickr is shown in theListing 52

Listing 52 Example of Flickr responseHTTP 11 200 OKltrsp stat=failgt

This means that actual status of the response could be determined only after pars-ing the message In this case verifyResponse(ReSupResponse) method would parseXML message and based on the stat parameter value (ok or fail) create an object ofVerifyResponseStatus class with appropriate isResponseSuccessful value If any spe-cific error codes are provided in service response which can give an understanding aboutrecoverable or non-recoverable nature of the error they can be used to detect if thisrequest should be repeated by setting the canRetry parameter valueCorresponding class diagram of abstract class ReSupRequest and subclasses is shown

in the Figure 59Individual parameters of request such as serviceEndpoint requestType httpMethod and

others are static fields of the class as they belong exclusively to this particular request

5 Implementation

ReSupRequest

-serviceEnpointURI-requestTypeRestRequestType-httpMethodHttpMethod-timeToLiveint-cachingPreferedboolean-adaptationStrategyIAdaptationStrategy

+ReSupRequest(baseUriString methodHttpMethodtypeRestRequestType timeToLiveint cachingPreferedboolean)

+verifyResponse(responseReSupResponse)VerifyResponseStatus

FirstCustomRequest

+FirstCustomRequest()super(serviceEndpointhttpMethodrequestTypet imeToLivecachingPrefered) +verifyResponse (responseReSupResponse) VerifyResponseStatus custom logic

N-CustomRequest

+N-CustomRequest()super(serviceEndpointhttpMethodrequestTypet imeToLivecachingPrefered) +verifyResponse (responseReSupResponse) VerifyResponseStatus custom logic

Figure 59 Class diagram of ReSupRequstrsquos family

HTTP parameters and headers can be added or changed depending on runtime conditionsthus they should be provided via set() methods Every subclass of ReSupRequest has toimplement abstract method verifyResponse(ReSupResponse) Default class constructormust call superclass constructor with all the request parameters as arguments

Message handlers

Message handlers can be used to process a response from the service directly into anapplication specific object As every service endpoint returns its unique message handlersare correlated with requests Every custom defined handler class must implement aninterface orgapachehttpclientResponseHandler

Adaptation component

Adaptation of web resources can be done in one of two possible ways on the serverside and by the client itself The first option means that service receives data aboutthe client (mobile device PC browser type) and chooses the most convenient resourcerepresentation Such approach hasnrsquot proven itself as a convenient in the context of theRESTful services where the amount of possible clients can be significant thus the taskto provide the most compatible representation is not trivialThe second way of adaptation means that the service provides several options of the

data representation and client decides which one to select by passing correspondingparameters in a request This solution does not guarantee a 100 adjustment to clientneeds but it allows to increase this probability

Adaptation component in the proposed library can be used when the service is designedto provide the second type of adaptivity The biggest benefit with this component willbe achieved if requested resources are media files eg pictures For example FacebookRESTful API provides two ways of how picture sizes can be adapted by predefined typeparameter or by providing actual width and height of a pictureAdaptation component operates with the following parameters

NetworkTypetype of the network connection which is currently used by the device Based onthis type decision is made which one among the available resource representationoptions to choose NetworkType parameter is provided by IReSupNetworkManagerdue to the information from IReSupNetworkMonitoring component

AbstractAdaptationStrategyencapsulates the algorithm of selection of necessary parameters This algorithmmight be individual to one particular service endpoint or encompass several similarendpoints In the latter case such adaptation strategy can be reused with differentrequest objects

AbstractAdaptationStrategy class exposes two abstract methods which should beimplemented by developer into a concrete strategy

adjustParameters(NetworkType collectionltinitialParametersgt) collec-tionltnewParametersgt

changes parameters of request

adjustHeaders(NetworkType collectionltinitialHeadersgt) collec-tionltnewHeadersgt

changes request headersAnd the following method is used by IReSupExecutionManager to obtain a newadapted request

getAdjustedRequest(NetworkType ReSupRequest) ReSupRequestreturns request with set of parameters andor headers that were changed in accor-dance to a given network type

544 Instantiation variations and configurationStandard usage of the ReSup client library is simple mdash a developer needs to instantiateone of IReSupExecutionManager implementation which fits the needs of the applicationIReSupExecutionManager instance should be obtained from EManagerFactory with oneof the following methods

createExecutionManager() IReSupExecutionManagerreturns basic IReSupExecutionManager without network awareness

createNetworkAwareExecutionManager(monitoring IReSupNetworkMoni-toring) IReSupExecutionManager

returns IReSupExecutionManager with network awareness throughIReSupNetworkMonitoring component

5 Implementation

createNetworkAwareExecutionManager(queueStorage IQueueStorage mon-itoring IReSupNetworkMonitoring) IReSupExecutionManager

returns IReSupExecutionManager with network awareness throughIReSupNetworkMonitoring component and with possibility to persist uncompletedrequests for later processing

Due to the amount of features which can be present an application developer canchoose which options are necessary During the instantiation phase developer shoulddecide on two orthogonal features caching and asynchrony Such choice goes throughtwo steps factory creation and obtaining the IReSupExecutionManager instanceOn the first step the decision about caching is made and during instantiation of

IReSupExecutionManager developer can choose between supporting or not supportingof asynchrony and network awareness in the application Figure 510 visualizes how theinstantiation should be accomplished based on desired criteria

Step 1

Caching

Yes No

factory = EManagerFactory(ClientConfiguration CachingStyle AbstractCacheStorageFactory int) or factory = EManagerFactory(CachingStyle AbstractCacheStorageFactory int)

factory = EmanagerFactory() or EmanagerFactory(ClientConfiguration)

Step 2

Asynchrony

Yes No

manager = factorycreateNetworkAwareExecutionManager(IQueueStorage IreSupNetworkMonitoring)or manager = factorycreateNetworkAwareExecutionManager(IReSupNetworkMonitoring)

manager = factorycreateExecutionManager()

Figure 510 Instantiation variants of IReSupExecutionManager

During the instantiation client may provide custom defined parameters to adjust someof HTTP underlying parameters

bull socket and connection timeouts

bull size of the connection pool

bull maximum number of retries

bull if the integrity of the message will be checked

bull if the library will follow the redirects automatically

bull proxy settings if any is used host port username and password

All configuration parameters are encapsulated in ClientConfiguration class whichcan be provided as a parameter to a EManagerFactory constructor Thus the client-side library can be configured for runtime environments in a most convenient way As itcan be seen in Figure 510 there are options to create the factory without configurationparameters In this case default values will be used

545 Two-leveled response processing

In order to make the ReSup library compliant with improperly designed RESTful APIsverification of response is always made on two levels HTTP level and application levelAs described in the Section 543 if content of response does not correspond to HTTPstatus code custom logic should be applied to verify correctness of the responseThus two-steps algorithm is the following

1 Check of standard HTTP code If response code is not equal 200 standard pro-cedures are applied according to error status codes redirect retrying if error isrecoverable (eg 503 Service Unavailable) returning response to a client if error isunrecoverable (eg 403 Forbidden) Otherwise response is passed to the next levelof verification

2 Check of VerifyResponseStatus With the help of custom logic ReSup can make adecision on proceeding with request retry or returning the response to the callingentity

546 Integration with legacy code

Proposed solution is fully prepared to provide HTTP fault tolerant layer for RESTfulapplications It includes means of straightforward conversion of RESTful service endpointsand corresponding access methods to an application code as well as a level for messagetransferring and error mitigation However all features of developed framework wereintended to help in application development from scratchThis section makes an overview of possibilities of ReSup integration with legacy appli-

cations in order to increase their robustness

Proxy approach The most convenient way to add fault tolerance to application withoutmodifying its source code is to put a proxy in the middle between resource and requesterand make it responsible for mitigating all the possible errors Such approach has onedrawback mdash it does not protect client from errors which can happen between callingapplication and proxy A possible way to avoid this is to place both client applicationand fault tolerant proxy within a very short distance eg on one physical machineIn terms of mobile devices running an additional proxy would result in higher powerconsumption Moreover proxy application for Android would require root rights to accessand manipulate system settings which will limit its usage only to rooted phones

Software adapter approach Second way to improve legacy applications with fault tol-erance strategies is to change the source code These changes can be minimized bydisguising the ReSup client library as an interface of the entity which is responsiblefor HTTP message transfer in given legacy application In scope of given work anadapter is implemented that provides all the functionality of ReSup to the client viaorgapachehttpclientHttpClient interface

5 Implementation

55 SummaryIn the given chapter the overview of implementation is given In the beginning the chosenimplementation language and auxiliaries are discussed Later chapter proceeds with theoverview on the proposed solution structureThe Section 53 explains in details how the ReSup API Mapping tool was implemented

In the Section 54 the accurate description of client-side library implementation is giventhat closes with the overview of possible alternatives of ReSup integration with legacycode

6 EvaluationThis chapter provides an evaluation of fulfilled requirements along with usage scenariodiscussionAt first testing environment is explained After this objective test case is described and

results are presented Third part of the chapter provides an example of usage scenariounder which the implemented solution can be utilized

61 Test environmentEnvironment for testing was created on a laptop with the following parameters

bull OS Ubuntu 1204

bull CPU Intel Core i5 M 450 240GHz x 4

bull RAM 3072 MB DDR2 (533 MHz)

bull IDE Eclipse Indigo for Java Developers SR2 (v 372)

bull Runtime environment Java SE Runtime Environment 160_31

bull Proxy Burp Suite1 free edition v1401

bull Network utilities trickle netem

To emulate unstable network behavior following network utilities were used

bull trickle is a script which allows to shape network bandwidth2 It was used toemulate different types of networks mdash LAN WLAN different mobile networks

bull netem allows to emulate the properties of wide area networks3 Among the param-eters which could be variated (delay loss duplication and re-ordering) packet losswas chosen to emulate the behavior of mobile and WIFI networks

Burp Suite provides a set of useful tools among which there is HTTP interceptor proxyIn given testing environment it was used to intercept certain HTTP responses from serverin order to emulate recoverable service errorsDisconnection from the network was simulated programmatically to have a full control

over the amount of request which were issued in the off-line mode1httpportswiggernetburpproxyhtml2httplinuxdienetman1trickle3httpwwwlinuxfoundationorgcollaborateworkgroupsnetworkingnetem

6 Evaluation

62 Objective testingMain aim of the objective test case is to compare behavior of proposed solution withdefault alternative under the same preconditions The system used for testing is shownin Figure 61

Figure 61 Testing environment

621 Test preconditionsFor this test case a set of requests was created When choosing service endpoints whichwill participate in the test following rules were followed

bull two different services were used in order to demonstrate that efforts on integrationis equal

bull first service provides so called High-REST API that is designed according to goodRESTful API rules mentioned in Sections 22 and 311

bull second service API uses Low-REST approach

bull five service endpoints were chosen from each service

bull each set of five service endpoints contains four that correspond to the set of CRUDoperations and one additional endpoint response from which is meant to be inter-cepted and modified Thus all of HTTP methods were used to evaluate the behaviorof implementations A list of the requested endpoints is represented in Table 61

bull prepared requests formed a set in which each endpoint was invoked three times Ingeneral the size of the set was 30 requests

Service Handling in Imperfect Networking 62 Objective testing

Table 61 Requestrsquos set characteristicAPI HTTP method

operationURI Special purpose

SoundCloudBase URI

httpsapisoundcloudcom

GET read mejson error injectionGETread meplaylistsjsonPUTupdate tracks79415548jsonPOSTcreate playlistsDELETE delete playlistsidjson

Couchfunk Test APIBase URI

httptestcouchfunkdeapi

GET read commentsmyGET read getHighlightShowsGET update updateUserInfoGET create commentCreateNew error injectionGET delete deleteComment

Test environment emulated network disconnection after the first 10 requests were in-voked and reconnection after 8 more requests were submitted in the off-line mode Pre-sumably in a system without any fault tolerance strategies involved and in perfect net-work conditions these 8 request will receive Timeout waiting for connection error andno response will return to the caller Additionally responses from 2 more endpointswere artificially injected with recoverable service error instead of original data Thus inaforementioned system only 20 responses could be successful

Error injection Service unavailability is a recoverable error where client can wait forsome back-off time and retry request again In given test case this behavior was testedon two following service endpoints that can be found in Table 62 Complexity for aclient appears when the real status of response is hidden in actual response messageas RESTful API with such called Low-REST design often expose Standard behaviorof HTTP libraries is to act accordingly to HTTP response codes But in the describedsituation such library would understand a response as successful also if it is not and evenif retry technique is implemented it would not be applied

Table 62 Service endpoints with error injectionService endpoint Initial correct response Modified error responseGETapisoundcloudcommejson

HTTP11 200 OK

HTTP11 503 Service Unavailable

GET testcouchfunkdeapicommentCreateNew

HTTP11 200 OKerror-code 0

HTTP11 200 OK error-code -1

ReSup provides a possibility to apply custom error check algorithm to each requestedendpoint if it differs from conventional HTTP status code verification Thus presumablyretry strategy of ReSup would mitigate service unavailability represented by errors inTable 62

Test suite Imperfect networking conditions were modeled via change of packet loss andbandwidth parameters As was mentioned before for packet loss manipulation netem wasused and following values were varied

6 Evaluation

Packet loss 0 5 10 30 60 80

As it can be seen maximal value of packet loss used for tests was 80 Values above80 were not used as such packet loss is too high and amount of received responses isclose to zero that does not show important differences among tested implementationsBandwidth variation in testing environment represented different types of networks

For limiting bandwidth on a laptop trickle tool was used This tool limits the bandwidthof a specific application by delaying the packets on a socket and runs entirely in userspaceThis property allows to use this tool in combination with netem that use Linux kerneltool tc4 to configure Traffic Control settings As all requests before being sent to theserver were intercepted by Burp Proxy trickle tool was applied to limit the download andupload speed of Burp Suite application Following bandwidth values were used in thetest

Bandwidth 100Mbps

50Mbps

10Mbps

3 Mbps 1 Mbps 500Kbps

50Kbps

Network type Ethernet WIFI mobile(HSPAHSPDA)

mobile(3G)

mobile(EDGEEvolu-tion)

mobile(EDGE)

mobile(GPRS)

For each combination of bandwidth and packet loss parameters the testing was per-formed for two implementations with ReSup and default Apache HttpClient In generalthe test suite consisted of 84 tests Both networking parameters were checked before eachtest to prove the desired networking conditions Packet loss was determined via pingto external URL and bandwidth was checked via on-line resources speedtestnet andspeedio

622 Results discussionAs it was estimated in section 41 proposed solution should satisfy a set of certain require-ments Given objective test demonstrates how the following requirements are covered

1 Network awareness

2 Asynchrony

3 Client-side caching

4 Saving of bandwidth

Network awareness of the application is its ability to recognize if network operationsshould proceed and how or they should be postponed based on network conditions Thisrequirement is closely related with the next requirement in given research contextAsynchrony in communication with service allows to postpone HTTP requests exe-

cution based on some external conditions In scope of the given work such externalcondition is network disconnections Within the described test scenario it means thatimplementation with ReSup should allow to receive higher rate of successful responsesduring the test assuming that network was disconnected for some period of time

4httplinuxdienetman8tc

Successful responses rate

The set of figures 62 shows distribution of successful responses received from tests Eachchart corresponds to one bandwidth value thus network type A full set of charts forevery tested bandwidth can be found in the Appendix B

0 2 5 10 30 60 800

100 Mbps

Error and lost responses

Default HTTP middleware

Packet loss

0 2 5 10 30 60 800

100 Mbps

Packet loss

0 2 5 10 30 60 800

3 Mbps

Packet loss

0 2 5 10 30 60 800

10 Mbps

Packet loss

0 2 5 10 30 60 800

50 Kbps

Packet loss

Figure 62 Distribution of successful responses based on network parameters

As it can be seen from the charts with a small rate of packet loss (0-10) in implemen-tation with proposed by ReSup approach the most of the requests were successful Defaultimplementation shows in average a gap of 10 successful responses less which correspondsto what was assumed before the testWith the increasing of packet loss up to 30 the difference between two test implemen-

tations decreased to 5 responses in average Such situation has happened because of theincreased amount of lost request ie requests that did not succeed due to connection or

6 Evaluation

read timeout To summarize ReSup approach gives a benefit in all represented networktypes with small packet loss values due to asynchronous way to perform requests to aservice supported by appropriate reaction on network connectivity state

Lost and error responses rate

In the Figure 63 the distribution of error and unsuccessful responses based on test resultscan be seen The rest of the charts related to given results can be found in the Appendix C

0 2 5 10 30 60 800

2 2 2 2 2 21

0 0 0 0 0 0 0

100 Mbps

Default HTTP middleware ndash Error responses

ReSup Error responses

Default HTTP middleware - Lost responses

ReSup Lost responses

Packet loss

0 2 5 10 30 60 800

2 2 2 2 21

00 0 0 0 0 0 0

3 Mbps

Packet loss

0 2 5 10 30 60 800

2 2 2 2 10 00 0 0 0 0 0 0

50 Kbps

Packet loss

Figure 63 Distribution of error and lost responses based on network parameters

The situation with the general amount of unsuccessful responses mirrors previous resultswith successful responses Additionally the nature of received errors is represented onthe chartsAs it was stated before two recoverable service error responses were injected in the

test set This action was supposed to demonstrate the ability of the proposed solution torecognize such errors without any additional fault tolerance logic written by a programmerand successfully overcome themResults on the charts show that the default implementation of the HTTP level has

returned the injected error responses to the client directly without mitigating them unlesscorresponding requests had ended with a connection or read timeout In contrast testimplementation with ReSup successfully recovered from such errors by resending request

Cache performance

The prepared set of requests contained 4 service endpoints responses from which could betheoretically cached due to its GETread nature Only one of them provided a responsewith Cache-control header that explicitly allows caching These endpoints can be foundin the Table 63 Thus the decision of caching in such case depends on the developerIn case caching is preferable the default max-age time can be specified during whichresponse will be considered as valid

Table 63 Service resources with theoretical caching abilityService Service endpoint Cache control

SoundCloudhttpsapisoundcloudcom

mejson Cache-Control private max-age=0must-revalidate

meplaylistsjson Cache-Control private max-age=0must-revalidate

Couchfunk Test APIhttptestcouchfunkdeapi

commentsmygetHighlightShows Cache-Control max-age=300

Used ReSup configuration was created with heuristic caching approach thus allowingto cache responses with aforementioned cache-control header values when max-age valueis specified to 0 Heuristic validity period is established in 300 sec by default Thereforein the given requests set the maximum number of responses that can be returned fromcache was 8 In the next Figure 64 maximal cache hit rate of 8 is assumed to be 100and actual measurements of this parameter are depicted as a percentage of the maximumvalueBased on test results it can be stated that requirements of client-side caching and

related saving of bandwidth were covered by proposed solution

Timing

Test implementation based on ReSup might differ from default implementation in per-formance due to asynchronous behavior and network monitoring For this purpose thetime of each test run was recorded averaged and compared for both implementationsResults can be seen in the Figure 65 where the time is represented as an average valueof the tests duration while X-axis represent diagonal change of the network conditionsfrom the perfect ones with 100 Mbps and 0 packet loss rate till the worst conditionswith 50 Kbps and 80 of packet loss

6 Evaluation

0 10 20 30 40 50 60 70 80

Figure 64 Cache-hit rate

100 Mbps - 0

10 Mbps ndash 5

1 Mbps ndash 30

50 Kbps ndash 80

146 151 152

297 286

144 150 150 152 159

191267

Default Http middleware

Level of network imperfection (bandwidth - packet loss)

Figure 65 Average time of test execution

Received results have a logical explanation Client-side caching implemented in ReSuplibrary reduces amount of requests sent to upstream service thus the time betweensending a request from client and receiving a response decreases drastically It can beseen that execution time for ReSup increases significantly as packet loss rates becomeshigher than 30 In this conditions more requests has been resulted with timeouts dueto inability to establish connection or read the received response Therefore the retrytechnique of ReSup made efforts to correct such errors and more attempts to resendrequests were made It resulted in a longer time of test duration but as was shown inFigures 62 and 63 also in slightly higher amount of successful outcomes

Service Handling in Imperfect Networking 63 Application creation scenario

63 Application creation scenarioAccording to the Section 41 the following requirements should be covered in order tosimplify development process of RESTful applications using proposed solution

1 API Mapping tool

2 Service aggregation

3 Independence from service API

Additionally solution should be configurable according to application needs and be lightweightGiven test scenario provides an overview on fulfilled requirements

631 DescriptionTo demonstrate the aforementioned requirements a test application for Android has beendeveloped Steps which are not relevant to research area of given work such as develop-ment of application UI are omittedAn example Android application combines functionality from two different services mdash

Facebook and CouchfunkFacebook is a social networking service which among plenty of other functionality

provides a search of a service specific resource (person comment status etc) by akeywordCouchfunk is a TV social-media platform which exposes a private RESTful API

Among the available resources provided by this service a list of TV shows with de-scriptions and additional information can be obtainedFor the simplicity of the test example aforementioned functionality of these services

were chosen as it does not require user authentication for accessing the dataOn the first page of the application a user can see a list of shows with their short

descriptions obtained from Couchfunk as it is shown in the Figure 66a On item clickthe application proposes to search any open information in Facebook related to a title ofthe given show The user has a possibility to change a search string as it can be seen inthe Figure 66bIn the last Figure 66c the search results returned by Facebook are representedThus two different requests were created to two unrelated service endpoints One of

the chosen services provides a WADL description of an API that can be used for a codegeneration the other provides only a plain-text documentation

632 Results discussionTo create requests to the service resources the ReSup API Mapper tool was used A codegeneration process went through two or thee simple steps depending on the presence orabsence of a WADL documentation The first step for both endpoints allowed to set asource folder in a specific project where the response class should be created as well asa package A corresponding wizard page is depicted in the Figure 67The second step is only used if the service has a formal API description file (WADL

WADL etc)

6 Evaluation

(a) List of shows (b) Search query (c) Search result

Figure 66 Example Android application

Figure 67 Choice of project source folder and package for future request class

To represent this functionality an example WADL description for the Couchfunk testAPI had been prepared and generated with the help of REST Describe amp Compileapplication5 A full listing of the WADL description document can be found in theAppendix DThe Figure 68 shows that the description WADL file for Couchfunk has been selected

from a local drive and after it has been processed a developer had an option to chooseone or several service endpoints from those that were available in the description

5httptomayacderest-describelatestRestDescribehtml

Figure 68 Selecting service description file

After the selection was made developer proceeded with the adding of the particularparameters to the given request The last wizard page that handle this action for bothservice endpoints is shown in the Figure 69 When the submission of all the necessarydata was accomplished a source code for a request class was generated

Figure 69 Specifying request parameters

6 Evaluation

Thus a creation of code which is responsible for a service endpoints invocation forthe presented example application takes a little time and is independent from the serviceitselfBy default response status codes 2XX are considered as a successful outcome from a

request If a service provides the other logic a developer can override a method 61 in agenerated request source code

Listing 61 Overriden method to define the status of responseOverridepublic VerifyResponseStatus verifyResponse(ReSupResponse response)

boolean success = ((statusCode == HttpStatusSC_OK) || (statusCode ==HttpStatusSC_CREATED))

boolean canRetry = thiscanRetryBasedOnMethod()String message = try

JsonNode json = getJsonFromResponse(responsegetHttpResponse())errorcode = jsonfindValue(errorminuscode)asInt()switch (errorcode) case minus1

success = falsemessage=unknown server errorbreak

case 0message=success no error occurredbreak

case 1success = falsecanRetry = falsemessage=user login expiredbreak

default

catch (IOException e) success = falsemessage=response cannot be parsed

return new VerifyResponseStatus(successcanRetrymessage)

With this approach it becomes easy to manage a source code and keep a service specificpart in a separation from the main application logicIt can be estimated that through encapsulation of all necessary logic for a definition of

successful response into a request class the proposed solution became independent fromrules of any particular service API At the same time the ReSup API Mapper allows

Service Handling in Imperfect Networking 64 Relation to scientific works

to generate a source code which describes requests to resources in a uniform way thusgiving a possibility to integrate the functionality of several independent services into oneapplicationA listing of code which was used in the example application with the ReSup library to

instantiate and submit a request is presented in the following Listing 62

Listing 62 ReSup execution manager creation and request submissionEManagerFactory factory = new EManagerFactory(config

CachingStyleHEURISTIC_CACHING new AndroidCacheStorageFactory()AndroidCacheStorageFactoryIN_MEMORY)

manager = factorycreateNetworkAwareExecutionManager(

new AndroidNetworkMonitoring(getApplicationContext()))ShowsRequest shRequest = new ShowsRequest()managerinvokeAsynchronously(shRequest new RequestCallbackInterface())

64 Relation to scientific worksAmong the reviewed in Section 33 research works the FT-REST [ET12] framework isthe only which is highly related to the stated problem of given workAccording to the description of FT-REST framework it provides a reusable layer of

fault-tolerance Among the strategies that are used mdash retrying of request and replicatingthe request to an equivalent resources are present In distinct to it ReSup uses the retrystrategy as well and also provides an asynchrony in requests invocation which dependon network awareness of the device and client-side cachingFT-REST framework proposes to use an XML description of the fault condition (er-

ror code andor timeout) and the handling strategy (number of retries back-off intervaland type) for each service endpoint In comparison to ReSup it allows to create theseparate configuration of the faulty conditions and handling strategies to individual end-points while ReSup allows to configure the error mitigation strategy once for the wholeapplicationRegarding the fault conditions mdash FT-REST relies on HTTP error codes As it was

explained earlier in the document some of the RESTful APIs provide correct error codenot in HTTP status line but in the message Unlike the FT-REST ReSup can alsomitigate the aforementioned error conditionsIn the following Table 64 the comparison of ReSup functionality against FT-REST

framework is presentedThus after a comparison it can be stated that although FT-REST and ReSup both

provide similar functionality ReSup encapsulates more fault tolerance techniques andprovide a functionality to bind the service specific semantic to an application

65 SummaryThis chapter provides an evaluation of the developed library and the API Mapping toolTwo test cases were proposed and performed in order to prove the fulfillment of the

6 Evaluation

Table 64 Comparison of characteristics FT-REST vs ReSupCharacteristics FT-REST ReSupSeparation of concerns - separatingof fault-tolerant layer from applicationlogic

yes yes

Fault condition description for each endpoint in XMLdocument

for each endpoint (option-ally hierarchical) in gen-erated classes

Handling strategies configuration for each endpoint for all applicationTimeout handling yes yesHTTP response error codes handling yes yesMitigation of errors embedded in themessage

no yes

Service binding code no yesFault handling techniquesRetrying of request yes yesEquivalent endpoints invocation yes noCache no yesAsynchronous request invocation (dueto network conditions)

no yes

established requirementsSection 62 describes the set of tests performed on two test application implementa-

tions mdash the first is was created with the usage of default HttpClient and the secondimplemented with the ReSup library Based on the same test preconditions these testimplementations have shown different results which were described compared and dis-cussed in the end of the sectionIn the Section 63 the scenario of API Mapping tool utilization was presented An

example of simple Android application development was presented which has shown howthe developed plug-in allows to handle diversified RESTful APIs in a unified wayThis Chapter concludes with the comparison of ReSup framework to the research works

reviewed in Section 33 of the given document

7 Epilogue

71 ConclusionThe accomplished work was targeted on the improvement of the RESTful applicationsdevelopment The research was aimed from one side at the mitigating of unstable networkconditions which in most cases become a source of errors in client-server applicationsand from the other mdash at finding the generic approach to utilize different service APIs inthe development Thus two parts of the intended work were accomplished the client-sidelibrary that provides the fault-tolerant layer to the application was developed and thetool that allows to handle all the service endpoints independently and in a generic waywas created

Chapter 1provided the motivation of the research work outlined the research questions anddescribed the structure of the document

Chapter 2presented the most important background information The overview on the notionof service has been made and the difference between the existing servicersquos imple-mentations was given At the next step the existing service description formatswere discussed and it was shown that nowadays there is no standard or at least acommon approach of describing the RESTful APIs

This chapter has finished with the overview of the techniques that can be usedto increase system reliability in case of the network loss These principles namedthe disconnected operation techniques have derived from the existing distributedsystems and have proven to be quite successful in unstable network conditionsTherefore several of them were considered to be used in the solving of the givenresearch problems

Chapter 3provided the state of the art overview The research area was investigated from bothsides mdash service and client Concerning the service side a set of RESTful serviceswas analyzed and comparison results were presented In scope of the client parta number of existing client-side solutions was examined Additionally the researchworks related to the given problem area were studied

Chapter 4established the set of requirements for the proposed solution along with the discus-sion of its structure The architecture of the client-side framework that fulfills therequirements was introduced and the system workflow was presented Afterwardsthe distinct processes that occur in the proposed library were described in detailsalong with components that participate in it

7 Epilogue

Chapter 5introduced the detailed description of the developed solution named ReSup Itconsists of two parts mdash the fault-tolerant client-side library and the API Mappingtool presented in the form of Eclipse plug-in which supports the service-specificcode generation from input parameters or provided description files The packagestructure classes and interfaces were explained

Chapter 6evaluated the implemented framework for accordance with the defined requirementsin two ways mdash comparison with the default HTTP layer implementation in thepredefined conditions and the amount of efforts needed to be done by a developerwho will use the proposed solution for creation of a RESTful application Thetesting environment was described and the test suite was explained The results ofthe evaluation are presented on the comparison charts provided in the chapter andin the Appendix B and C

72 Addressed research questionsWhich means can be used to achieve sufficient resilience and reliability of mobileapplication in heterogeneous network environment

The HTTP 11 protocol specification itself and the related research works which werereviewed in scope of the given master thesis provide possible means for achieving anapplication reliability and resilience Firstly supported by the HTTP ability to cacheresources can be named which as a result became one of the milestones of the RESTfularchitecture Caching on the client side reduces amount of round-trip calls to the servicethus reducing the probability of failure Secondly the disconnected operations techniquesmentioned in Section 23 can be applied to avoid an error outcome In the accomplishedwork queuing of the requests was used to achieve asynchrony as well as retrying of therequests in case of errors The given techniques were used in combination with the deviceawareness about the networking conditions which allowed to adjust runtime parametersaccordingly

How to achieve non-blocking interaction with the application during unstablenetwork behavior

Due to the nature of RESTful services and the applications which are build on obtainedresources it is complicated to achieve a full non blocking interaction with the applicationThe reason lies behind the intent of such services and corresponding applications In mostof the cases services provide (and application consumes) a dynamic information thatchanges rapidly Thus with a high dependency on the on-line resources any applicationwill become unusable with the long connection loss In spite of this the usage of anintense client-side caching and postponing of the user interactions with a service improvethe overall user experience Therefore in the proposed solution caching parameters can beconfigured to force response caching even if for some reason a service do not encourageit explicitly Allowing the user to do some actions with the application (thus sendingrequests to a service) while delaying them internally till the connection reappears alsocreates a visibility of non-blocking interactions

Service Handling in Imperfect Networking 73 Future research work

How to make fault-tolerance application layer independent from the accessedRESTful API with the lack of formalized service description

As RESTful APIs provide a variety of different implementations and there are neitherdevelopment nor description standard the decision was made to separate a service-specificpart of application code from the other fault-tolerant code by a canonicalized interface ofrequest Thus the fault-tolerant layer depends on this interface and any of the serviceendpoints can be adjusted to implement it and expose to the fault-tolerant layer As suchinterface was defined the special API Mapping tool was created which helps to optimizethe generation of the necessary service-specific code

73 Future research workThough the developed solution covers the established requirements there exists a widerange of aspects for future investigation and improvements

Support for OAuth1 (Open Authorization)As the OAuth standard is recommended by the community of RESTful APIrsquos devel-opers to protect sensitive resources and also is currently used by many of existingRESTful services a support of the given protocol should be considered

Batch requests supportOne of the features adopted by RESTful APIrsquos is to batch several API calls togetherand invoke them in one HTTP connection to reduce the amount of latter made fromthe client An additional functionality providing this possibility can improve thedeveloped solution

Upload and download of large files in chunkesAlong with the HTTP 11 support of the chunked transfer encoding on the protocollevel some of the RESTful APIs propose an interface for upload or download oflarge resources in parts directly on the API level The given area of interest mightbe investigated and a generic solution to support chunked upload on the RESTAPI level can be proposed for future improvements

A Result of RESTful API analysis

Table A1 Adaptation concepts

c compression

3 Data reduction

b lossy conversion

c pagination

Table A2 Result of API analysis (part 1)API Shufflerfm Vimeo Data API Vimeo Advanced APIDescription Online music magazine

It allows users to searchand discover music fromblogs and music sites

Video sharing servicewith social featuresAPI gives read accessto all open data

Video sharing servicewith social featuresAPI to private dataupload videos

Data model Hierarchical structure Hierarchical structure Methods styleMIME applicationjson applicationxml appli-

cationjson applica-tionphp

applicationxml appli-cationjson applica-tionphp

Format JSON JSONP JSON JSONP PHP ar-ray XML

JSON JSONP PHP ar-ray XML

CRUD GET api provides readonly functionality

GET HEAD - only read GET represented bymethod parameters

Headers mdash Cache-Control ETag Expires Cache-ControlResponse codes Standard HTTP error

code syntaxStandard HTTP errorcode syntax

Error field in documentresponse

Formal documen-tation

mdash Structure of responseobjects

Structured description Structured descriptionexamples

Structured descriptionAPI Playground

Security Application key SSL plain HTTP SSL OAuth 10Data adaptation(Table A1)

1b 1c 3c 1b 1c 2a 3c 1b 2a 3c

SDKs Ruby API Wrapper PHP unofficialPythonRuby Wordpress CNET

PHP unofficialPythonRuby Wordpress CNET

Table A3 Result of API analysis (part 2)API Facebook Cloud Passage Amazon S3Description Social networking ser-

viceCloud server securityplatform with all thesecurity functions forservers in public and hy-brid clouds

Storage service with asimple web interface tostore objects using theAmazon online storageinfrastructure

Data model Graph Hierarchical structure Hierarchical structureMIME textjavascript

applicationjson imagejpg text-plain applicationxmlbinaryoctel-stream

Format JSON JSON XML (was noticedJSON in one response)

All 4 methods are used GET or POST se-mantic of request isrepresented via methodquery parameter

x-cpauth-access Request mdash RangeIf-Modified-SinceIf-Unmodified-Since If-Match If-None-MatchExpect response mdashETag x-amz-datex-amz-security-tokenx-amz-mfa x-amz-delete-marker x-amz-id-2

Response codes Standard custom codesspesified and used bySDKs

Set of standardcustomerror messages for 422404 500

mdash mdash mdash

Structured Graph APIExplorer

Structured description Structured description

Security SSL OAuth 20 x-cpauth-access and keyobtained through userinterface

Custom HTTP schema

Data adaptation(Table A1)

1b 1c 2a 3a 3c mdash 1b 1c 3c

mdash SDK for Java NetPHP Ruby AWSToolkit Mobile SDK(Android iOS)

Table A4 Result of API analysis (part 3)API Flickr Daisy SoundcloudDescription Online photo manage-

ment and sharing ser-vice

Suite of tools and APIsfor making imagesdynamically- straightfrom your Photoshop Rcopyfiles

Sound sharing servicewith social features

Data model Methods oriented One service entry pointMethod function as pa-rameter

Hierarchical structure

MIME textxml text-javascript

texthtml with embed-ded link to picture

applicationjsonapplicationxmlcharset=utf-8 au-diompeg

Format JSON JSONP XMLPHP Serial

HTML XML JSON

CRUD GET or POST se-mantic of request isrepresented via methodquery parameter

GET POST (browserforms)

Headers mdash standard Cache-Control private

Accept applicationj-son Access-Control-Allow-Methods ETagLast-modified

Response codes Response XML docu-ment of two types indi-cation error of success

Do not correspond toerrors

HTTP Status Codes

mdash mdash mdash

Unstructured API ex-plorer

Description with ex-amples How-to videossamples Support

Structured descriptionAPI Console

Security OAuth 10 Application id in pa-rameters to requestPlain HTTP

Plain HTTP for publicdata and client id SSLOAuth 20

URL shortening 1c 1b2a 3c

1c 1b 3a 3c

SDKs third party API-Kits mdash Python Ruby PHPJava iOS JavaScriptSound Sharing kitsAPI Console

Table A5 Result of API analysis (part 4)API Open 311 Dropbox Sun Cloud APIDescription Form of technology that

provides open channelsof communication for is-sues that concern pub-lic space and public ser-vices

File storage and sharingservice

API for creating andmanaging cloud re-sources includingcompute storage andnetworking components

Data model standard hierarchy Mixed hierarchy Standard hierarchyMIME textxml textplain

applicationrss+xmlcharset=utf-8

applicationjson applicationvndcomsuncloudXxxxxxxx+json (spe-cific media type foreach resource model)

Format XML JSON RSS JSON JSONCRUD GET POST (with GET

semantics)GET PUT POST GET POST PUT and

DELETEHeaders Standard Accept-

Ranges bytesx-dropbox-metadatawith content metadata

X-YYYYY-Client-Specification-Version(API version) Autho-rization Content-type

Response codes Standard HTTP Re-sponse codes

Standard HTTP errorcode syntax additionalinfo in the body somecustom errors

Standard HTTP re-sponse codes 4xx and5xx response messagebody containing amessages data modelcontaining zero or moremessage data modelsdescribing what wentwrong

Response field descrip-tion

mdash Media type descriptions

Structured descriptionwiki examples Re-sponse field descriptionmailing list support

Structured descriptionexamples

Command Line Client

Security None SSL only OAuth 10 SSL HTTP BasicAuthentication (RFC2617)

1c1a UTF-8 encoding local-ization1b 3c

SDKs PHP Python RubyNodejs C thirdparty software

iOS Android PythonRuby Java OSx

B Successful responses distribution

0 2 5 10 30 60 800

100 Mbps

Packet loss

0 2 5 10 30 60 800

100 Mbps

Packet loss

0 2 5 10 30 60 800

3 Mbps

Packet loss

0 2 5 10 30 60 800

50 Mbps

Packet loss

0 2 5 10 30 60 800

10 Mbps

Packet loss

0 2 5 10 30 60 800

3 Mbps

Packet loss

0 2 5 10 30 60 800

1 Mbps

Packet loss

0 2 5 10 30 60 800

10 Mbps

Packet loss

0 2 5 10 30 60 800

50 Kbps

Packet loss

0 2 5 10 30 60 800

500 Kbps

Packet loss

0 2 5 10 30 60 800

10 Mbps

Packet loss

0 2 5 10 30 60 800

50 Kbps

Packet loss

C Error and lost responses distribution

0 2 5 10 30 60 800

2 2 2 2 2 21

0 0 0 0 0 0 0

100 Mbps

Packet loss

0 2 5 10 30 60 800

2 2 2 2 2 1 10 0 0 0 0 0 0

50 Mbps

Packet loss

0 2 5 10 30 60 800

2 2 2 2 21 10 0 0 0 0 0 0

10 Mbps

Packet loss

0 2 5 10 30 60 800

2 2 2 2 21

00 0 0 0 0 0 0

3 Mbps

Packet loss

0 2 5 10 30 60 800

2 2 2 2 21

00 0 0 0 0 0 0

3 Mbps

Packet loss

0 2 5 10 30 60 800

2 2 2 21 1

00 0 0 0 0 0 0

1 Mbps

Packet loss

0 2 5 10 30 60 800

2 2 2 2 10 00 0 0 0 0 0 0

50 Kbps

Packet loss

0 2 5 10 30 60 800

2 2 2 2 2 100 0 0 0 0 0 0

500 Kbps

Packet loss

0 2 5 10 30 60 800

2 2 2 2 10 00 0 0 0 0 0 0

50 Kbps

Packet loss

D WADL description of Couchfunk APIGivenWADL description file is an example of formal documemtation that can be providedwith RESTful services With such description it becomes easier to generate source codefor client applications In given work this particular description is used as an example todemonstrate the functionality of ReSup API Mapper tool

ltxml version=10 encoding=utfminus8gtltapplication xmlnsxsi=httpwwww3org2001XMLSchemaminusinstance xmlnsxsd=httpwww

w3org2001XMLSchema xsischemaLocation=httpresearchsuncomwadl200610 wadlxsdxmlns=httpresearchsuncomwadl200610gt

ltresources base=httptestcouchfunkdeapigtltresource path=logingtltmethod name=GETgt

ltrequestgtltparam name=login type=xsdstring style=query id=loginParamgtltparam name=pass type=xsdstring style=query id=passParamgt

ltrequestgtltmethodgt

ltresourcegt

ltresource path=getHighlightShowsgtltmethod name=GETgtltmethodgt

ltresourcegtltresource path=deleteCommentgtltmethod name=GETgtltrequestgtltparam name=id type=xsdinteger style=querygtltparam name=sessionkey type=xsdstring style=querygt

ltresourcegt

ltresource path=updateUserInfogtltmethod name=GETgtltrequestgtltparam name=display_name type=xsdstring style=querygtltparam name=first_name type=xsdstring style=querygtltparam name=last_name type=xsdstring style=querygtltparam name=sessionkey type=xsdstring style=querygt

ltresourcegt

ltresource path=commentCreateNewgtltmethod name=GETgtltrequestgtltparam name=slug type=xsdstring style=query id=slugParamgtltparam name=text type=xsdstring style=query id=textParamgt

D WADL description of Couchfunk API

ltparam name=sessionkey type=xsdstring style=querygtltrequestgt

ltmethodgtltresourcegt

ltresource path=sendAvatargtltmethod name=POSTgtltrequestgtltparam name=sessionkey type=xsdstring style=querygt

ltresourcegtltresourcesgt

ltapplicationgt

Bibliography[AP12] T Aihkisalo and T Paaso ldquoLatencies of Service Invocation and Processing

of the REST and SOAP Web Service Interfacesrdquo In Services (SERVICES)2012 IEEE Eighth World Congress on June 2012 pages 100 ndash107 doi 101109SERVICES201255 (cited on page 1)

[Api12] Apigee Web API Design Crafting Interfaces that Developers Love 2012(cited on pages 1 14 15)

[BO12] Alistair Barros and Daniel Oberle editors Handbook of Service DescriptionUSDL and Its Methods 2012th edition New York London Springer Mar 312012 isbn 1461418631 url http www amazon com exec obidos redirecttag=citeulike07-20amppath=ASIN1461418631 (cited on page 5)

[Chi+07] Roberto Chinnici Jean-Jacques Moreau Arthur Ryman et al Web ServicesDescription Language (WSDL) Version 20 Part 1 Core Language 2007 urlhttpwwww3orgTRwsdl20 (cited on page 8)

[ET12] J Edstrom and E Tilevich ldquoReusable and Extensible Fault Tolerance forRESTful Applicationsrdquo In Trust Security and Privacy in Computing andCommunications (TrustCom) 2012 IEEE 11th International Conference June2012 pages 737 ndash744 doi 101109TrustCom2012244 (cited on pages 2873)

[Fie00] Roy Thomas Fielding ldquoArchitectural Styles and the Design of Network-basedSoftware Architecturesrdquo PhD thesis University of California Irvine 2000(cited on pages 1 6)

[Had09] Marc Hadley Web Application Description Language 2009 url httpwwww3orgSubmissionwadl (cited on page 8)

[KTA09] Young-Woo Kwon Eli Tilevich and Taweesup Apiwattanapong ldquoDR-OSGiHardening Distributed Components with Network Volatility Resiliencyrdquo InMiddleware 2009 Edited by Jean Bacon and Brian Cooper Volume 5896Lecture Notes in Computer Science 2009 pages 373ndash392 (cited on page 28)

[Ltd12] Apiary Ltd Apiari 2012 url httpapiaryio (cited on page 16)[Mas11] Mark Masse REST API Design Rulebook Edited by Simon St Laurent

OrsquoReilly Media Inc 2011 (cited on pages 1 10 14)[MBS10] Juergen Mangler Peter Paul Beran and Erich Schikuta ldquoOn the Origin of

Services Using RIDDL for Description Evolution and Composition of REST-ful Servicesrdquo In Cluster Cloud and Grid Computing (CCGrid) 2010 10thIEEEACM International Conference on May 2010 pages 505 ndash508 doi101109CCGRID2010126 (cited on page 10)

Bibliography

[MG09] G Mulligan and D Gracanin ldquoA comparison of SOAP and REST implemen-tations of a service based interaction independence middleware frameworkrdquoIn Simulation Conference (WSC) Proceedings of the 2009 Winter Dec 2009pages 1423 ndash1432 doi 101109WSC20095429290 (cited on page 1)

[MM06] M Mikic-Rakic and N Medvidovic ldquoA Classification of Disconnected Opera-tion Techniquesrdquo In Software Engineering and Advanced Applications 2006SEAA rsquo06 32nd EUROMICRO Conference on 29 2006-sept 1 2006 pages 144ndash151 doi 101109EUROMICRO20065 (cited on page 11)

[MSW09] J Mangler E Schikuta and C Witzany ldquoQuo vadis interface definition lan-guages Towards a interface definition language for RESTful servicesrdquo InService-Oriented Computing and Applications (SOCA) 2009 IEEE Interna-tional Conference on Jan 2009 pages 1 ndash4 doi 10 1109 SOCA 2009 5410459 (cited on page 10)

[Net12] Netcraft Web Server Survey Nov 2012 url httpnewsnetcraftcomarchives20121101november-2012-web-server-surveyhtml (citedon page 13)

[Par10] Adam Parrish Social network APIs A revised lexical analysis Apr 2010 urlhttpwwwdecontextualizecom201004social-network-apis-a-revised-lexical-analysis (cited on page 14)

[SF07] N Salatge and J-C Fabre ldquoFault Tolerance Connectors for Unreliable WebServicesrdquo In Dependable Systems and Networks 2007 DSN rsquo07 37th AnnualIEEEIFIP International Conference on June 2007 pages 51 ndash60 doi 101109DSN200748 (cited on page 27)

[SKS12] Josef Spillner Ronny Kursawe and Alexander Schill ldquoExperience Reporton Real-World Manual Service Modelling in USDLrdquo In Handbook of Ser-vice Description - USDL and its Methods Edited by Alistair Barros andDaniel Oberle Springer Berlin Heidelberg Mar 2012 pages 487ndash501 (citedon page 5)

[SLM05] GT Santos Lau Cheuk Lung and C Montez ldquoFTWeb a fault tolerantinfrastructure for Web servicesrdquo In EDOC Enterprise Computing Conference2005 Ninth IEEE International Sept 2005 pages 95 ndash105 doi 101109EDOC200515 (cited on page 27)

[Sne08] James Snell Resource-oriented vs activity-oriented Web services May 2008url httpwww-128ibmcomdeveloperworkswebserviceslibraryws-restvsoap (cited on page 6)

[Spr04] Thomas Springer ldquoEin komponentenbasiertes Meta-Modell kontextabhaumlngigerAdaptionsgraphen fuumlr mobile und ubiquitaumlre Anwendungenrdquo PhD thesis TUDresden 2004 (cited on page 17)

[Tak+08] Toshiro Takase Satoshi Makino Shinya Kawanaka et al ldquoDefinition Lan-guages for RESTful Web Services WADL vs WSDL 20rdquo In 1 1 (2008)page 1 (cited on page 8)

[Til08] Stefan Tilkov REST Anti-Patterns July 2008 url httpwwwinfoqcomarticlesrest-anti-patterns (cited on page 1)

Service Handling in Imperfect Networking Bibliography

[TM12] Tony Tam and Erin McKean Swagger 2012 url httpswaggerwordnikcom (cited on page 16)

[Van+03] Debra VanderMeer Anindya Datta Kaushik Dutta et al ldquoMobile User Re-covery in the Context of Internet Transactionsrdquo In (2003) (cited on page 27)

[Wil12] Steven Willmott Reaching a Million APIs and What to do When We GetThere 2012 url http blog programmableweb com 2012 06 05 reaching-a-million-apis-and-what-to-do-when-we-get-there (citedon page 14)

Introduction

Motivation

Adressed usage scenarios

Research goals and questions

Structure

Background

Services in Internet

General definition of Service

Services in Web

RESTful services

Service Tooling Support

Service description language WSDL 20 with HTTP binding extensions

Web Application Description Language (WADL)

Swagger

RIDDL

WRML - Web Resource Modeling Language

Disconnected operation techniques

Summary

State of the Art

RESTful API analysis

Design Rules

Criteria of evaluation

Result of evaluation

Conclusion

Existing Client side solutions

Mobile devices peculiarities

Failure model of RESTful service based mobile application

Client SDKs and API-wrappers

Conclusion

Related scientific work

Mobile user recovery

FTWeb and Fault Tolerant Web Service Framework

DR-OSGI

FT-REST

Conclusion

Summary

Description of the Concept

Requirement analysis

Discussion

Logical architecture

Structural architecture

Process architecture

Summary

Implementation

Development platforms

Overview of the structure

API mapping tool implementation

Client-side library implementation

Basic components

Extension points

Application specific components

Instantiation variations and configuration

Two-leveled response processing

Integration with legacy code

Summary

Evaluation

Test environment

Objective testing

Test preconditions

Results discussion

Application creation scenario

Description

Results discussion

Relation to scientific works

Summary

Epilogue

Conclusion

Addressed research questions

Future research work

Result of RESTful API analysis

Successful responses distribution

Error and lost responses distribution

WADL description of Couchfunk API

Bibiliography

AufgabenstellungDiese Seite muss vor dem Binden der gedruckten Fassung der Arbeit durch die von HerrnMeiszligner und dem Studenten eigenhaumlndig unterschriebene originale Aufgabenstellung er-setzt werden Das zweite abzugebende gebundene Exemplar soll stattdessen eine Kopiedieser originalen Aufgabenstellung enthalten

Contents

34 Summary 29

Contents

55 Summary 60

Bibiliography 91

List of Figures

List of Tables

1 Introduction

Mobile application

System

Service

laquousesraquo

Mobile application

System

Mobile application

Service

If data is in cache

laquousesraquo

System

1 Introduction

2 Background

223 Swagger

5httpwwwwordnikcom

2 Background

6httpwwwwrmlorg

2 Background

3 State of the Art

developers

Data model

3 State of the Art

HTTP response codes

Data adaptation

c compression

3 Data reduction

b lossy conversion

c pagination

Provided SDKs

3 State of the Art

mdash mdash mdash

3 State of the Art

HTTP Status Codes

mdash mdash

1b 3a 3c

3 State of the Art

314 Conclusion

3 State of the Art

Android features

3 State of the Art

+ + + + ndash

Exception wrap-ping

+ + + ndash +

3 State of the Art

AndroidSDK

AmazonS3 AndroidSDK

FT-REST

Requests Executor

Service

1 Network Manager

2 Requests Executor

3 Requests Queue

4 Cache

intraquo

laquotr

nraquo

laquocu

nraquo

Controller

Adaptive Execution

Controller

Network Errors

Service Errors

Service API

Check of cache

time signal

Stage 1

Stage 2

Stage 3

Cache hit

API mappingplugin

Request Execmanager

Cachemanager

configuration

getCachedResponse()

a l tcachedResponse

generatedResponse

generateResponse()

responseFromServer

handleResponse()

responseFromServer

Server

Request Execmanager

RequestQueue

NetworkManager

canonicalRequest

Service

request

getRequest()

[network connected]

triggerExecution()

wait()

responseFromServer

isConnected()

executeRequest()

sendResponse()

retry()

sendRequest()

Client

checkResponse()

backOffEstimation()

t imeout()

canRetry()

retry()canRetry()

constructResponse()

in the Section 44

5 Implementation

apimapper

uicomponents

codegenerator

datainterfaces

handlers

datatypes

dataprocessing

orgtudresup

adaptation

entit ies

executionhandlers

network

adcomp

entit ies

pdcomp

network

5 Implementation

Datatypes

Handlers

Wizard

RequestGenerator

AbstractReSupWizard

5 Implementation

BaseQueue

5 Implementation

HttpCacheStorage

CacheStorageFactory

+CUSTOM_STORAGEint

Client

IQueueStorage

5 Implementation

ReSupRequest

FirstCustomRequest

N-CustomRequest

Message handlers

5 Implementation

Step 1

Caching

Yes No

Step 2

Asynchrony

Yes No

5 Implementation

bull OS Ubuntu 1204

6 Evaluation

SoundCloudBase URI

HTTP11 200 OK

6 Evaluation

Packet loss 0 5 10 30 60 80

Bandwidth 100Mbps

50Mbps

10Mbps

50Kbps

mobile(3G)

mobile(EDGE)

mobile(GPRS)

1 Network awareness

2 Asynchrony

0 2 5 10 30 60 800

100 Mbps

Packet loss

0 2 5 10 30 60 800

100 Mbps

Packet loss

0 2 5 10 30 60 800

3 Mbps

Packet loss

0 2 5 10 30 60 800

10 Mbps

Packet loss

0 2 5 10 30 60 800

50 Kbps

Packet loss

6 Evaluation

0 2 5 10 30 60 800

2 2 2 2 2 21

0 0 0 0 0 0 0

100 Mbps

Packet loss

0 2 5 10 30 60 800

2 2 2 2 21

00 0 0 0 0 0 0

3 Mbps

Packet loss

0 2 5 10 30 60 800

2 2 2 2 10 00 0 0 0 0 0 0

50 Kbps

Packet loss

Cache performance

Timing

6 Evaluation

0 10 20 30 40 50 60 70 80

100 Mbps - 0

10 Mbps ndash 5

1 Mbps ndash 30

50 Kbps ndash 80

146 151 152

297 286

144 150 150 152 159

191267

1 API Mapping tool

WADL etc)

6 Evaluation

default

6 Evaluation

yes yes

no yes

7 Epilogue

c compression

3 Data reduction

b lossy conversion

c pagination

1b 1c 3c 1b 1c 2a 3c 1b 2a 3c

mdash mdash mdash

Custom HTTP schema

HTML XML JSON

HTTP Status Codes

mdash mdash mdash

1c 1b 3a 3c

Command Line Client

0 2 5 10 30 60 800

100 Mbps

Packet loss

0 2 5 10 30 60 800

100 Mbps

Packet loss

0 2 5 10 30 60 800

3 Mbps

Packet loss

0 2 5 10 30 60 800

50 Mbps

Packet loss

0 2 5 10 30 60 800

10 Mbps

Packet loss

0 2 5 10 30 60 800

3 Mbps

Packet loss

0 2 5 10 30 60 800

1 Mbps

Packet loss

0 2 5 10 30 60 800

10 Mbps

Packet loss

0 2 5 10 30 60 800

50 Kbps

Packet loss

0 2 5 10 30 60 800

500 Kbps

Packet loss

0 2 5 10 30 60 800

10 Mbps

Packet loss

0 2 5 10 30 60 800

50 Kbps

Packet loss

0 2 5 10 30 60 800

2 2 2 2 2 21

0 0 0 0 0 0 0

100 Mbps

Packet loss

0 2 5 10 30 60 800

2 2 2 2 2 1 10 0 0 0 0 0 0

50 Mbps

Packet loss

0 2 5 10 30 60 800

2 2 2 2 21 10 0 0 0 0 0 0

10 Mbps

Packet loss

0 2 5 10 30 60 800

2 2 2 2 21

00 0 0 0 0 0 0

3 Mbps

Packet loss

0 2 5 10 30 60 800

2 2 2 2 21

00 0 0 0 0 0 0

3 Mbps

Packet loss

0 2 5 10 30 60 800

2 2 2 21 1

00 0 0 0 0 0 0

1 Mbps

Packet loss

0 2 5 10 30 60 800

2 2 2 2 10 00 0 0 0 0 0 0

50 Kbps

Packet loss

0 2 5 10 30 60 800

2 2 2 2 2 100 0 0 0 0 0 0

500 Kbps

Packet loss

0 2 5 10 30 60 800

2 2 2 2 10 00 0 0 0 0 0 0

50 Kbps

Packet loss

ltresourcegt

ltapplicationgt

Bibliography

Introduction

Motivation



Structure

Background



Services in Web

RESTful services




Swagger

RIDDL



Summary

State of the Art


Design Rules



Conclusion





Conclusion




DR-OSGI

FT-REST

Conclusion

Summary



Discussion




Summary

Implementation





Basic components

Extension points





Summary

Evaluation

Test environment

Objective testing

Test preconditions

Results discussion


Description

Results discussion


Summary

Epilogue

Conclusion







Bibiliography

Contents

34 Summary 29

Contents

55 Summary 60

Bibiliography 91

List of Figures

List of Tables

1 Introduction

Mobile application

System

Service

laquousesraquo

Mobile application

System

Mobile application

Service

If data is in cache

laquousesraquo

System

1 Introduction

2 Background

223 Swagger

5httpwwwwordnikcom

2 Background

6httpwwwwrmlorg

2 Background

3 State of the Art

developers

Data model

3 State of the Art

HTTP response codes

Data adaptation

c compression

3 Data reduction

b lossy conversion

c pagination

Provided SDKs

3 State of the Art

mdash mdash mdash

3 State of the Art

HTTP Status Codes

mdash mdash

1b 3a 3c

3 State of the Art

314 Conclusion

3 State of the Art

Android features

3 State of the Art

+ + + + ndash

Exception wrap-ping

+ + + ndash +

3 State of the Art

AndroidSDK

AmazonS3 AndroidSDK

FT-REST

Requests Executor

Service

1 Network Manager

2 Requests Executor

3 Requests Queue

4 Cache

intraquo

laquotr

nraquo

laquocu

nraquo

Controller

Adaptive Execution

Controller

Network Errors

Service Errors

Service API

Check of cache

time signal

Stage 1

Stage 2

Stage 3

Cache hit

API mappingplugin

Request Execmanager

Cachemanager

configuration

getCachedResponse()

a l tcachedResponse

generatedResponse

generateResponse()

responseFromServer

handleResponse()

responseFromServer

Server

Request Execmanager

RequestQueue

NetworkManager

canonicalRequest

Service

request

getRequest()

[network connected]

triggerExecution()

wait()

responseFromServer

isConnected()

executeRequest()

sendResponse()

retry()

sendRequest()

Client

checkResponse()

backOffEstimation()

t imeout()

canRetry()

retry()canRetry()

constructResponse()

in the Section 44

5 Implementation

apimapper

uicomponents

codegenerator

datainterfaces

handlers

datatypes

dataprocessing

orgtudresup

adaptation

entit ies

executionhandlers

network

adcomp

entit ies

pdcomp

network

5 Implementation

Datatypes

Handlers

Wizard

RequestGenerator

AbstractReSupWizard

5 Implementation

BaseQueue

5 Implementation

HttpCacheStorage

CacheStorageFactory

+CUSTOM_STORAGEint

Client

IQueueStorage

5 Implementation

ReSupRequest

FirstCustomRequest

N-CustomRequest

Message handlers

5 Implementation

Step 1

Caching

Yes No

Step 2

Asynchrony

Yes No

5 Implementation

bull OS Ubuntu 1204

6 Evaluation

SoundCloudBase URI

HTTP11 200 OK

6 Evaluation

Packet loss 0 5 10 30 60 80

Bandwidth 100Mbps

50Mbps

10Mbps

50Kbps

mobile(3G)

mobile(EDGE)

mobile(GPRS)

1 Network awareness

2 Asynchrony

0 2 5 10 30 60 800

100 Mbps

Packet loss

0 2 5 10 30 60 800

100 Mbps

Packet loss

0 2 5 10 30 60 800

3 Mbps

Packet loss

0 2 5 10 30 60 800

10 Mbps

Packet loss

0 2 5 10 30 60 800

50 Kbps

Packet loss

6 Evaluation

0 2 5 10 30 60 800

2 2 2 2 2 21

0 0 0 0 0 0 0

100 Mbps

Packet loss

0 2 5 10 30 60 800

2 2 2 2 21

00 0 0 0 0 0 0

3 Mbps

Packet loss

0 2 5 10 30 60 800

2 2 2 2 10 00 0 0 0 0 0 0

50 Kbps

Packet loss

Cache performance

Timing

6 Evaluation

0 10 20 30 40 50 60 70 80

100 Mbps - 0

10 Mbps ndash 5

1 Mbps ndash 30

50 Kbps ndash 80

146 151 152

297 286

144 150 150 152 159

191267

1 API Mapping tool

WADL etc)

6 Evaluation

default

6 Evaluation

yes yes

no yes

7 Epilogue

c compression

3 Data reduction

b lossy conversion

c pagination

1b 1c 3c 1b 1c 2a 3c 1b 2a 3c

mdash mdash mdash

Custom HTTP schema

HTML XML JSON

HTTP Status Codes

mdash mdash mdash

1c 1b 3a 3c

Command Line Client

0 2 5 10 30 60 800

100 Mbps

Packet loss

0 2 5 10 30 60 800

100 Mbps

Packet loss

0 2 5 10 30 60 800

3 Mbps

Packet loss

0 2 5 10 30 60 800

50 Mbps

Packet loss

0 2 5 10 30 60 800

10 Mbps

Packet loss

0 2 5 10 30 60 800

3 Mbps

Packet loss

0 2 5 10 30 60 800

1 Mbps

Packet loss

0 2 5 10 30 60 800

10 Mbps

Packet loss

0 2 5 10 30 60 800

50 Kbps

Packet loss

0 2 5 10 30 60 800

500 Kbps

Packet loss

0 2 5 10 30 60 800

10 Mbps

Packet loss

0 2 5 10 30 60 800

50 Kbps

Packet loss

0 2 5 10 30 60 800

2 2 2 2 2 21

0 0 0 0 0 0 0

100 Mbps

Packet loss

0 2 5 10 30 60 800

2 2 2 2 2 1 10 0 0 0 0 0 0

50 Mbps

Packet loss

0 2 5 10 30 60 800

2 2 2 2 21 10 0 0 0 0 0 0

10 Mbps

Packet loss

0 2 5 10 30 60 800

2 2 2 2 21

00 0 0 0 0 0 0

3 Mbps

Packet loss

0 2 5 10 30 60 800

2 2 2 2 21

00 0 0 0 0 0 0

3 Mbps

Packet loss

0 2 5 10 30 60 800

2 2 2 21 1

00 0 0 0 0 0 0

1 Mbps

Packet loss

0 2 5 10 30 60 800

2 2 2 2 10 00 0 0 0 0 0 0

50 Kbps

Packet loss

0 2 5 10 30 60 800

2 2 2 2 2 100 0 0 0 0 0 0

500 Kbps

Packet loss

0 2 5 10 30 60 800

2 2 2 2 10 00 0 0 0 0 0 0

50 Kbps

Packet loss

ltresourcegt

ltapplicationgt

Bibliography

Introduction

Motivation



Structure

Background



Services in Web

RESTful services




Swagger

RIDDL



Summary

State of the Art


Design Rules



Conclusion





Conclusion




DR-OSGI

FT-REST

Conclusion

Summary



Discussion




Summary

Implementation





Basic components

Extension points





Summary

Evaluation

Test environment

Objective testing

Test preconditions

Results discussion


Description

Results discussion


Summary

Epilogue

Conclusion







Bibiliography

Contents

34 Summary 29

Contents

55 Summary 60

Bibiliography 91

List of Figures

List of Tables

1 Introduction

Mobile application

System

Service

laquousesraquo

Mobile application

System

Mobile application

Service

If data is in cache

laquousesraquo

System

1 Introduction

2 Background

223 Swagger

5httpwwwwordnikcom

2 Background

6httpwwwwrmlorg

2 Background

3 State of the Art

developers

Data model

3 State of the Art

HTTP response codes

Data adaptation

c compression

3 Data reduction

b lossy conversion

c pagination

Provided SDKs

3 State of the Art

mdash mdash mdash

3 State of the Art

HTTP Status Codes

mdash mdash

1b 3a 3c

3 State of the Art

314 Conclusion

3 State of the Art

Android features

3 State of the Art

+ + + + ndash

Exception wrap-ping

+ + + ndash +

3 State of the Art

AndroidSDK

AmazonS3 AndroidSDK

FT-REST

Requests Executor

Service

1 Network Manager

2 Requests Executor

3 Requests Queue

4 Cache

intraquo

laquotr

nraquo

laquocu

nraquo

Controller

Adaptive Execution

Controller

Network Errors

Service Errors

Service API

Check of cache

time signal

Stage 1

Stage 2

Stage 3

Cache hit

API mappingplugin

Request Execmanager

Cachemanager

configuration

getCachedResponse()

a l tcachedResponse

generatedResponse

generateResponse()

responseFromServer

handleResponse()

responseFromServer

Server

Request Execmanager

RequestQueue

NetworkManager

canonicalRequest

Service

request

getRequest()

[network connected]

triggerExecution()

wait()

responseFromServer

isConnected()

executeRequest()

sendResponse()

retry()

sendRequest()

Client

checkResponse()

backOffEstimation()

t imeout()

canRetry()

retry()canRetry()

constructResponse()

in the Section 44

5 Implementation

apimapper

uicomponents

codegenerator

datainterfaces

handlers

datatypes

dataprocessing

orgtudresup

adaptation

entit ies

executionhandlers

network

adcomp

entit ies

pdcomp

network

5 Implementation

Datatypes

Handlers

Wizard

RequestGenerator

AbstractReSupWizard

5 Implementation

BaseQueue

5 Implementation

HttpCacheStorage

CacheStorageFactory

+CUSTOM_STORAGEint

Client

IQueueStorage

5 Implementation

ReSupRequest

FirstCustomRequest

N-CustomRequest

Message handlers

5 Implementation

Step 1

Caching

Yes No

Step 2

Asynchrony

Yes No

5 Implementation

bull OS Ubuntu 1204

6 Evaluation

SoundCloudBase URI

HTTP11 200 OK

6 Evaluation

Packet loss 0 5 10 30 60 80

Bandwidth 100Mbps

50Mbps

10Mbps

50Kbps

mobile(3G)

mobile(EDGE)

mobile(GPRS)

1 Network awareness

2 Asynchrony

0 2 5 10 30 60 800

100 Mbps

Packet loss

0 2 5 10 30 60 800

100 Mbps

Packet loss

0 2 5 10 30 60 800

3 Mbps

Packet loss

0 2 5 10 30 60 800

10 Mbps

Packet loss

0 2 5 10 30 60 800

50 Kbps

Packet loss

6 Evaluation

0 2 5 10 30 60 800

2 2 2 2 2 21

0 0 0 0 0 0 0

100 Mbps

Packet loss

0 2 5 10 30 60 800

2 2 2 2 21

00 0 0 0 0 0 0

3 Mbps

Packet loss

0 2 5 10 30 60 800

2 2 2 2 10 00 0 0 0 0 0 0

50 Kbps

Packet loss

Cache performance

Timing

6 Evaluation

0 10 20 30 40 50 60 70 80

100 Mbps - 0

10 Mbps ndash 5

1 Mbps ndash 30

50 Kbps ndash 80

146 151 152

297 286

144 150 150 152 159

191267

1 API Mapping tool

WADL etc)

6 Evaluation

default

6 Evaluation

yes yes

no yes

7 Epilogue

c compression

3 Data reduction

b lossy conversion

c pagination

1b 1c 3c 1b 1c 2a 3c 1b 2a 3c

mdash mdash mdash

Custom HTTP schema

HTML XML JSON

HTTP Status Codes

mdash mdash mdash

1c 1b 3a 3c

Command Line Client

0 2 5 10 30 60 800

100 Mbps

Packet loss

0 2 5 10 30 60 800

100 Mbps

Packet loss

0 2 5 10 30 60 800

3 Mbps

Packet loss

0 2 5 10 30 60 800

50 Mbps

Packet loss

0 2 5 10 30 60 800

10 Mbps

Packet loss

0 2 5 10 30 60 800

3 Mbps

Packet loss

0 2 5 10 30 60 800

1 Mbps

Packet loss

0 2 5 10 30 60 800

10 Mbps

Packet loss

0 2 5 10 30 60 800

50 Kbps

Packet loss

0 2 5 10 30 60 800

500 Kbps

Packet loss

0 2 5 10 30 60 800

10 Mbps

Packet loss

0 2 5 10 30 60 800

50 Kbps

Packet loss

0 2 5 10 30 60 800

2 2 2 2 2 21

0 0 0 0 0 0 0

100 Mbps

Packet loss

0 2 5 10 30 60 800

2 2 2 2 2 1 10 0 0 0 0 0 0

50 Mbps

Packet loss

0 2 5 10 30 60 800

2 2 2 2 21 10 0 0 0 0 0 0

10 Mbps

Packet loss

0 2 5 10 30 60 800

2 2 2 2 21

00 0 0 0 0 0 0

3 Mbps

Packet loss

0 2 5 10 30 60 800

2 2 2 2 21

00 0 0 0 0 0 0

3 Mbps

Packet loss

0 2 5 10 30 60 800

2 2 2 21 1

00 0 0 0 0 0 0

1 Mbps

Packet loss

0 2 5 10 30 60 800

2 2 2 2 10 00 0 0 0 0 0 0

50 Kbps

Packet loss

0 2 5 10 30 60 800

2 2 2 2 2 100 0 0 0 0 0 0

500 Kbps

Packet loss

0 2 5 10 30 60 800

2 2 2 2 10 00 0 0 0 0 0 0

50 Kbps

Packet loss

ltresourcegt

ltapplicationgt

Bibliography

Introduction

Motivation



Structure

Background



Services in Web

RESTful services




Swagger

RIDDL



Summary

State of the Art


Design Rules



Conclusion





Conclusion




DR-OSGI

FT-REST

Conclusion

Summary



Discussion




Summary

Implementation





Basic components

Extension points





Summary

Evaluation

Test environment

Objective testing

Test preconditions

Results discussion


Description

Results discussion


Summary

Epilogue

Conclusion







Bibiliography

Contents

55 Summary 60

Bibiliography 91

List of Figures

List of Tables

1 Introduction

Mobile application

System

Service

laquousesraquo

Mobile application

System

Mobile application

Service

If data is in cache

laquousesraquo

System

1 Introduction

2 Background

223 Swagger

5httpwwwwordnikcom

2 Background

6httpwwwwrmlorg

2 Background

3 State of the Art

developers

Data model

3 State of the Art

HTTP response codes

Data adaptation

c compression

3 Data reduction

b lossy conversion

c pagination

Provided SDKs

3 State of the Art

mdash mdash mdash

3 State of the Art

HTTP Status Codes

mdash mdash

1b 3a 3c

3 State of the Art

314 Conclusion

3 State of the Art

Android features

3 State of the Art

+ + + + ndash

Exception wrap-ping

+ + + ndash +

3 State of the Art

AndroidSDK

AmazonS3 AndroidSDK

FT-REST

Requests Executor

Service

1 Network Manager

2 Requests Executor

3 Requests Queue

4 Cache

intraquo

laquotr

nraquo

laquocu

nraquo

Controller

Adaptive Execution

Controller

Network Errors

Service Errors

Service API

Check of cache

time signal

Stage 1

Stage 2

Stage 3

Cache hit

API mappingplugin

Request Execmanager

Cachemanager

configuration

getCachedResponse()

a l tcachedResponse

generatedResponse

generateResponse()

responseFromServer

handleResponse()

responseFromServer

Server

Request Execmanager

RequestQueue

NetworkManager

canonicalRequest

Service

request

getRequest()

[network connected]

triggerExecution()

wait()

responseFromServer

isConnected()

executeRequest()

sendResponse()

retry()

sendRequest()

Client

checkResponse()

backOffEstimation()

t imeout()

canRetry()

retry()canRetry()

constructResponse()

in the Section 44

5 Implementation

apimapper

uicomponents

codegenerator

datainterfaces

handlers

datatypes

dataprocessing

orgtudresup

adaptation

entit ies

executionhandlers

network

adcomp

entit ies

pdcomp

network

5 Implementation

Datatypes

Handlers

Wizard

RequestGenerator

AbstractReSupWizard

5 Implementation

BaseQueue

5 Implementation

HttpCacheStorage

CacheStorageFactory

+CUSTOM_STORAGEint

Client

IQueueStorage

5 Implementation

ReSupRequest

FirstCustomRequest

N-CustomRequest

Message handlers

5 Implementation

Step 1

Caching

Yes No

Step 2

Asynchrony

Yes No

5 Implementation

bull OS Ubuntu 1204

6 Evaluation

SoundCloudBase URI

HTTP11 200 OK

6 Evaluation

Packet loss 0 5 10 30 60 80

Bandwidth 100Mbps

50Mbps

10Mbps

50Kbps

mobile(3G)

mobile(EDGE)

mobile(GPRS)

1 Network awareness

2 Asynchrony

0 2 5 10 30 60 800

100 Mbps

Packet loss

0 2 5 10 30 60 800

100 Mbps

Packet loss

0 2 5 10 30 60 800

3 Mbps

Packet loss

0 2 5 10 30 60 800

10 Mbps

Packet loss

0 2 5 10 30 60 800

50 Kbps

Packet loss

6 Evaluation

0 2 5 10 30 60 800

2 2 2 2 2 21

0 0 0 0 0 0 0

100 Mbps

Packet loss

0 2 5 10 30 60 800

2 2 2 2 21

00 0 0 0 0 0 0

3 Mbps

Packet loss

0 2 5 10 30 60 800

2 2 2 2 10 00 0 0 0 0 0 0

50 Kbps

Packet loss

Cache performance

Timing

6 Evaluation

0 10 20 30 40 50 60 70 80

100 Mbps - 0

10 Mbps ndash 5

1 Mbps ndash 30

50 Kbps ndash 80

146 151 152

297 286

144 150 150 152 159

191267

1 API Mapping tool

WADL etc)

6 Evaluation

default

6 Evaluation

yes yes

no yes

7 Epilogue

c compression

3 Data reduction

b lossy conversion

c pagination

1b 1c 3c 1b 1c 2a 3c 1b 2a 3c

mdash mdash mdash

Custom HTTP schema

HTML XML JSON

HTTP Status Codes

mdash mdash mdash

1c 1b 3a 3c

Command Line Client

0 2 5 10 30 60 800

100 Mbps

Packet loss

0 2 5 10 30 60 800

100 Mbps

Packet loss

0 2 5 10 30 60 800

3 Mbps

Packet loss

0 2 5 10 30 60 800

50 Mbps

Packet loss

0 2 5 10 30 60 800

10 Mbps

Packet loss

0 2 5 10 30 60 800

3 Mbps

Packet loss

0 2 5 10 30 60 800

1 Mbps

Packet loss

0 2 5 10 30 60 800

10 Mbps

Packet loss

0 2 5 10 30 60 800

50 Kbps

Packet loss

0 2 5 10 30 60 800

500 Kbps

Packet loss

0 2 5 10 30 60 800

10 Mbps

Packet loss

0 2 5 10 30 60 800

50 Kbps

Packet loss

0 2 5 10 30 60 800

2 2 2 2 2 21

0 0 0 0 0 0 0

100 Mbps

Packet loss

0 2 5 10 30 60 800

2 2 2 2 2 1 10 0 0 0 0 0 0

50 Mbps

Packet loss

0 2 5 10 30 60 800

2 2 2 2 21 10 0 0 0 0 0 0

10 Mbps

Packet loss

0 2 5 10 30 60 800

2 2 2 2 21

00 0 0 0 0 0 0

3 Mbps

Packet loss

0 2 5 10 30 60 800

2 2 2 2 21

00 0 0 0 0 0 0

3 Mbps

Packet loss

0 2 5 10 30 60 800

2 2 2 21 1

00 0 0 0 0 0 0

1 Mbps

Packet loss

0 2 5 10 30 60 800

2 2 2 2 10 00 0 0 0 0 0 0

50 Kbps

Packet loss

0 2 5 10 30 60 800

2 2 2 2 2 100 0 0 0 0 0 0

500 Kbps

Packet loss

0 2 5 10 30 60 800

2 2 2 2 10 00 0 0 0 0 0 0

50 Kbps

Packet loss

ltresourcegt

ltapplicationgt

Bibliography

Introduction

Motivation



Structure

Background



Services in Web

RESTful services




Swagger

RIDDL



Summary

State of the Art


Design Rules



Conclusion





Conclusion




DR-OSGI

FT-REST

Conclusion

Summary



Discussion




Summary

Implementation





Basic components

Extension points





Summary

Evaluation

Test environment

Objective testing

Test preconditions

Results discussion


Description

Results discussion


Summary

Epilogue

Conclusion







Bibiliography

List of Figures

List of Tables

1 Introduction

Mobile application

System

Service

laquousesraquo

Mobile application

System

Mobile application

Service

If data is in cache

laquousesraquo

System

1 Introduction

2 Background

223 Swagger

5httpwwwwordnikcom

2 Background

6httpwwwwrmlorg

2 Background

3 State of the Art

developers

Data model

3 State of the Art

HTTP response codes

Data adaptation

c compression

3 Data reduction

b lossy conversion

c pagination

Provided SDKs

3 State of the Art

mdash mdash mdash

3 State of the Art

HTTP Status Codes

mdash mdash

1b 3a 3c

3 State of the Art

314 Conclusion

3 State of the Art

Android features

3 State of the Art

+ + + + ndash

Exception wrap-ping

+ + + ndash +

3 State of the Art

AndroidSDK

AmazonS3 AndroidSDK

FT-REST

Requests Executor

Service

1 Network Manager

2 Requests Executor

3 Requests Queue

4 Cache

intraquo

laquotr

nraquo

laquocu

nraquo

Controller

Adaptive Execution

Controller

Network Errors

Service Errors

Service API

Check of cache

time signal

Stage 1

Stage 2

Stage 3

Cache hit

API mappingplugin

Request Execmanager

Cachemanager

configuration

getCachedResponse()

a l tcachedResponse

generatedResponse

generateResponse()

responseFromServer

handleResponse()

responseFromServer

Server

Request Execmanager

RequestQueue

NetworkManager

canonicalRequest

Service

request

getRequest()

[network connected]

triggerExecution()

wait()

responseFromServer

isConnected()

executeRequest()

sendResponse()

retry()

sendRequest()

Client

checkResponse()

backOffEstimation()

t imeout()

canRetry()

retry()canRetry()

constructResponse()

in the Section 44

5 Implementation

apimapper

uicomponents

codegenerator

datainterfaces

handlers

datatypes

dataprocessing

orgtudresup

adaptation

entit ies

executionhandlers

network

adcomp

entit ies

pdcomp

network

5 Implementation

Datatypes

Handlers

Wizard

RequestGenerator

AbstractReSupWizard

5 Implementation

BaseQueue

5 Implementation

HttpCacheStorage

CacheStorageFactory

+CUSTOM_STORAGEint

Client

IQueueStorage

5 Implementation

ReSupRequest

FirstCustomRequest

N-CustomRequest

Message handlers

5 Implementation

Step 1

Caching

Yes No

Step 2

Asynchrony

Yes No

5 Implementation

bull OS Ubuntu 1204

6 Evaluation

SoundCloudBase URI

HTTP11 200 OK

6 Evaluation

Packet loss 0 5 10 30 60 80

Bandwidth 100Mbps

50Mbps

10Mbps

50Kbps

mobile(3G)

mobile(EDGE)

mobile(GPRS)

1 Network awareness

2 Asynchrony

0 2 5 10 30 60 800

100 Mbps

Packet loss

0 2 5 10 30 60 800

100 Mbps

Packet loss

0 2 5 10 30 60 800

3 Mbps

Packet loss

0 2 5 10 30 60 800

10 Mbps

Packet loss

0 2 5 10 30 60 800

50 Kbps

Packet loss

6 Evaluation

0 2 5 10 30 60 800

2 2 2 2 2 21

0 0 0 0 0 0 0

100 Mbps

Packet loss

0 2 5 10 30 60 800

2 2 2 2 21

00 0 0 0 0 0 0

3 Mbps

Packet loss

0 2 5 10 30 60 800

2 2 2 2 10 00 0 0 0 0 0 0

50 Kbps

Packet loss

Cache performance

Timing

6 Evaluation

0 10 20 30 40 50 60 70 80

100 Mbps - 0

10 Mbps ndash 5

1 Mbps ndash 30

50 Kbps ndash 80

146 151 152

297 286

144 150 150 152 159

191267

1 API Mapping tool

WADL etc)

6 Evaluation

default

6 Evaluation

yes yes

no yes

7 Epilogue

c compression

3 Data reduction

b lossy conversion

c pagination

1b 1c 3c 1b 1c 2a 3c 1b 2a 3c

mdash mdash mdash

Custom HTTP schema

HTML XML JSON

HTTP Status Codes

mdash mdash mdash

1c 1b 3a 3c

Command Line Client

0 2 5 10 30 60 800

100 Mbps

Packet loss

0 2 5 10 30 60 800

100 Mbps

Packet loss

0 2 5 10 30 60 800

3 Mbps

Packet loss

0 2 5 10 30 60 800

50 Mbps

Packet loss

0 2 5 10 30 60 800

10 Mbps

Packet loss

0 2 5 10 30 60 800

3 Mbps

Packet loss

0 2 5 10 30 60 800

1 Mbps

Packet loss

0 2 5 10 30 60 800

10 Mbps

Packet loss

0 2 5 10 30 60 800

50 Kbps

Packet loss

0 2 5 10 30 60 800

500 Kbps

Packet loss

0 2 5 10 30 60 800

10 Mbps

Packet loss

0 2 5 10 30 60 800

50 Kbps

Packet loss

0 2 5 10 30 60 800

2 2 2 2 2 21

0 0 0 0 0 0 0

100 Mbps

Packet loss

0 2 5 10 30 60 800

2 2 2 2 2 1 10 0 0 0 0 0 0

50 Mbps

Packet loss

0 2 5 10 30 60 800

2 2 2 2 21 10 0 0 0 0 0 0

10 Mbps

Packet loss

0 2 5 10 30 60 800

2 2 2 2 21

00 0 0 0 0 0 0

3 Mbps

Packet loss

0 2 5 10 30 60 800

2 2 2 2 21

00 0 0 0 0 0 0

3 Mbps

Packet loss

0 2 5 10 30 60 800

2 2 2 21 1

00 0 0 0 0 0 0

1 Mbps

Packet loss

0 2 5 10 30 60 800

2 2 2 2 10 00 0 0 0 0 0 0

50 Kbps

Packet loss

0 2 5 10 30 60 800

2 2 2 2 2 100 0 0 0 0 0 0

500 Kbps

Packet loss

0 2 5 10 30 60 800

2 2 2 2 10 00 0 0 0 0 0 0

50 Kbps

Packet loss

ltresourcegt

ltapplicationgt

Bibliography

Introduction

Motivation



Structure

Background



Services in Web

RESTful services




Swagger

RIDDL



Summary

State of the Art


Design Rules



Conclusion





Conclusion




DR-OSGI

FT-REST

Conclusion

Summary



Discussion




Summary

Implementation





Basic components

Extension points





Summary

Evaluation

Test environment

Objective testing

Test preconditions

Results discussion


Description

Results discussion


Summary

Epilogue

Conclusion







Bibiliography

List of Tables

1 Introduction

Mobile application

System

Service

laquousesraquo

Mobile application

System

Mobile application

Service

If data is in cache

laquousesraquo

System

1 Introduction

2 Background

223 Swagger

5httpwwwwordnikcom

2 Background

6httpwwwwrmlorg

2 Background

3 State of the Art

developers

Data model

3 State of the Art

HTTP response codes

Data adaptation

c compression

3 Data reduction

b lossy conversion

c pagination

Provided SDKs

3 State of the Art

mdash mdash mdash

3 State of the Art

HTTP Status Codes

mdash mdash

1b 3a 3c

3 State of the Art

314 Conclusion

3 State of the Art

Android features

3 State of the Art

+ + + + ndash

Exception wrap-ping

+ + + ndash +

3 State of the Art

AndroidSDK

AmazonS3 AndroidSDK

FT-REST

Requests Executor

Service

1 Network Manager

2 Requests Executor

3 Requests Queue

4 Cache

intraquo

laquotr

nraquo

laquocu

nraquo

Controller

Adaptive Execution

Controller

Network Errors

Service Errors

Service API

Check of cache

time signal

Stage 1

Stage 2

Stage 3

Cache hit

API mappingplugin

Request Execmanager

Cachemanager

configuration

getCachedResponse()

a l tcachedResponse

generatedResponse

generateResponse()

responseFromServer

handleResponse()

responseFromServer

Server

Request Execmanager

RequestQueue

NetworkManager

canonicalRequest

Service

request

getRequest()

[network connected]

triggerExecution()

wait()

responseFromServer

isConnected()

executeRequest()

sendResponse()

retry()

sendRequest()

Client

checkResponse()

backOffEstimation()

t imeout()

canRetry()

retry()canRetry()

constructResponse()

in the Section 44

5 Implementation

apimapper

uicomponents

codegenerator

datainterfaces

handlers

datatypes

dataprocessing

orgtudresup

adaptation

entit ies

executionhandlers

network

adcomp

entit ies

pdcomp

network

5 Implementation

Datatypes

Handlers

Wizard

RequestGenerator

AbstractReSupWizard

5 Implementation

BaseQueue

5 Implementation

HttpCacheStorage

CacheStorageFactory

+CUSTOM_STORAGEint

Client

IQueueStorage

5 Implementation

ReSupRequest

FirstCustomRequest

N-CustomRequest

Message handlers

5 Implementation

Step 1

Caching

Yes No

Step 2

Asynchrony

Yes No

5 Implementation

bull OS Ubuntu 1204

6 Evaluation

SoundCloudBase URI

HTTP11 200 OK

6 Evaluation

Packet loss 0 5 10 30 60 80

Bandwidth 100Mbps

50Mbps

10Mbps

50Kbps

mobile(3G)

mobile(EDGE)

mobile(GPRS)

1 Network awareness

2 Asynchrony

0 2 5 10 30 60 800

100 Mbps

Packet loss

0 2 5 10 30 60 800

100 Mbps

Packet loss

0 2 5 10 30 60 800

3 Mbps

Packet loss

0 2 5 10 30 60 800

10 Mbps

Packet loss

0 2 5 10 30 60 800

50 Kbps

Packet loss

6 Evaluation

0 2 5 10 30 60 800

2 2 2 2 2 21

0 0 0 0 0 0 0

100 Mbps

Packet loss

0 2 5 10 30 60 800

2 2 2 2 21

00 0 0 0 0 0 0

3 Mbps

Packet loss

0 2 5 10 30 60 800

2 2 2 2 10 00 0 0 0 0 0 0

50 Kbps

Packet loss

Cache performance

Timing

6 Evaluation

0 10 20 30 40 50 60 70 80

100 Mbps - 0

10 Mbps ndash 5

1 Mbps ndash 30

50 Kbps ndash 80

146 151 152

297 286

144 150 150 152 159

191267

1 API Mapping tool

WADL etc)

6 Evaluation

default

6 Evaluation

yes yes

no yes

7 Epilogue

c compression

3 Data reduction

b lossy conversion

c pagination

1b 1c 3c 1b 1c 2a 3c 1b 2a 3c

mdash mdash mdash

Custom HTTP schema

HTML XML JSON

HTTP Status Codes

mdash mdash mdash

1c 1b 3a 3c

Command Line Client

0 2 5 10 30 60 800

100 Mbps

Packet loss

0 2 5 10 30 60 800

100 Mbps

Packet loss

0 2 5 10 30 60 800

3 Mbps

Packet loss

0 2 5 10 30 60 800

50 Mbps

Packet loss

0 2 5 10 30 60 800

10 Mbps

Packet loss

0 2 5 10 30 60 800

3 Mbps

Packet loss

0 2 5 10 30 60 800

1 Mbps

Packet loss

0 2 5 10 30 60 800

10 Mbps

Packet loss

0 2 5 10 30 60 800

50 Kbps

Packet loss

0 2 5 10 30 60 800

500 Kbps

Packet loss

0 2 5 10 30 60 800

10 Mbps

Packet loss

0 2 5 10 30 60 800

50 Kbps

Packet loss

0 2 5 10 30 60 800

2 2 2 2 2 21

0 0 0 0 0 0 0

100 Mbps

Packet loss

0 2 5 10 30 60 800

2 2 2 2 2 1 10 0 0 0 0 0 0

50 Mbps

Packet loss

0 2 5 10 30 60 800

2 2 2 2 21 10 0 0 0 0 0 0

10 Mbps

Packet loss

0 2 5 10 30 60 800

2 2 2 2 21

00 0 0 0 0 0 0

3 Mbps

Packet loss

0 2 5 10 30 60 800

2 2 2 2 21

00 0 0 0 0 0 0

3 Mbps

Packet loss

0 2 5 10 30 60 800

2 2 2 21 1

00 0 0 0 0 0 0

1 Mbps

Packet loss

0 2 5 10 30 60 800

2 2 2 2 10 00 0 0 0 0 0 0

50 Kbps

Packet loss

0 2 5 10 30 60 800

2 2 2 2 2 100 0 0 0 0 0 0

500 Kbps

Packet loss

0 2 5 10 30 60 800

2 2 2 2 10 00 0 0 0 0 0 0

50 Kbps

Packet loss

ltresourcegt

ltapplicationgt

Bibliography

Introduction

Motivation



Structure

Background



Services in Web

RESTful services




Swagger

RIDDL



Summary

State of the Art


Design Rules



Conclusion





Conclusion




DR-OSGI

FT-REST

Conclusion

Summary



Discussion




Summary

Implementation





Basic components

Extension points





Summary

Evaluation

Test environment

Objective testing

Test preconditions

Results discussion


Description

Results discussion


Summary

Epilogue

Conclusion







Bibiliography

1 Introduction

Mobile application

System

Service

laquousesraquo

Mobile application

System

Mobile application

Service

If data is in cache

laquousesraquo

System

1 Introduction

2 Background

223 Swagger

5httpwwwwordnikcom

2 Background

6httpwwwwrmlorg

2 Background

3 State of the Art

developers

Data model

3 State of the Art

HTTP response codes

Data adaptation

c compression

3 Data reduction

b lossy conversion

c pagination

Provided SDKs

3 State of the Art

mdash mdash mdash

3 State of the Art

HTTP Status Codes

mdash mdash

1b 3a 3c

3 State of the Art

314 Conclusion

3 State of the Art

Android features

3 State of the Art

+ + + + ndash

Exception wrap-ping

+ + + ndash +

3 State of the Art

AndroidSDK

AmazonS3 AndroidSDK

FT-REST

Requests Executor

Service

1 Network Manager

2 Requests Executor

3 Requests Queue

4 Cache

intraquo

laquotr

nraquo

laquocu

nraquo

Controller

Adaptive Execution

Controller

Network Errors

Service Errors

Service API

Check of cache

time signal

Stage 1

Stage 2

Stage 3

Cache hit

API mappingplugin

Request Execmanager

Cachemanager

configuration

getCachedResponse()

a l tcachedResponse

generatedResponse

generateResponse()

responseFromServer

handleResponse()

responseFromServer

Server

Request Execmanager

RequestQueue

NetworkManager

canonicalRequest

Service

request

getRequest()

[network connected]

triggerExecution()

wait()

responseFromServer

isConnected()

executeRequest()

sendResponse()

retry()

sendRequest()

Client

checkResponse()

backOffEstimation()

t imeout()

canRetry()

retry()canRetry()

constructResponse()

in the Section 44

5 Implementation

apimapper

uicomponents

codegenerator

datainterfaces

handlers

datatypes

dataprocessing

orgtudresup

adaptation

entit ies

executionhandlers

network

adcomp

entit ies

pdcomp

network

5 Implementation

Datatypes

Handlers

Wizard

RequestGenerator

AbstractReSupWizard

5 Implementation

BaseQueue

5 Implementation

HttpCacheStorage

CacheStorageFactory

+CUSTOM_STORAGEint

Client

IQueueStorage

5 Implementation

ReSupRequest

FirstCustomRequest

N-CustomRequest

Message handlers

5 Implementation

Step 1

Caching

Yes No

Step 2

Asynchrony

Yes No

5 Implementation

bull OS Ubuntu 1204

6 Evaluation

SoundCloudBase URI

HTTP11 200 OK

6 Evaluation

Packet loss 0 5 10 30 60 80

Bandwidth 100Mbps

50Mbps

10Mbps

50Kbps

mobile(3G)

mobile(EDGE)

mobile(GPRS)

1 Network awareness

2 Asynchrony

0 2 5 10 30 60 800

100 Mbps

Packet loss

0 2 5 10 30 60 800

100 Mbps

Packet loss

0 2 5 10 30 60 800

3 Mbps

Packet loss

0 2 5 10 30 60 800

10 Mbps

Packet loss

0 2 5 10 30 60 800

50 Kbps

Packet loss

6 Evaluation

0 2 5 10 30 60 800

2 2 2 2 2 21

0 0 0 0 0 0 0

100 Mbps

Packet loss

0 2 5 10 30 60 800

2 2 2 2 21

00 0 0 0 0 0 0

3 Mbps

Packet loss

0 2 5 10 30 60 800

2 2 2 2 10 00 0 0 0 0 0 0

50 Kbps

Packet loss

Cache performance

Timing

6 Evaluation

0 10 20 30 40 50 60 70 80

100 Mbps - 0

10 Mbps ndash 5

1 Mbps ndash 30

50 Kbps ndash 80

146 151 152

297 286

144 150 150 152 159

191267

1 API Mapping tool

WADL etc)

6 Evaluation

default

6 Evaluation

yes yes

no yes

7 Epilogue

c compression

3 Data reduction

b lossy conversion

c pagination

1b 1c 3c 1b 1c 2a 3c 1b 2a 3c

mdash mdash mdash

Custom HTTP schema

HTML XML JSON

HTTP Status Codes

mdash mdash mdash

1c 1b 3a 3c

Command Line Client

0 2 5 10 30 60 800

100 Mbps

Packet loss

0 2 5 10 30 60 800

100 Mbps

Packet loss

0 2 5 10 30 60 800

3 Mbps

Packet loss

0 2 5 10 30 60 800

50 Mbps

Packet loss

0 2 5 10 30 60 800

10 Mbps

Packet loss

0 2 5 10 30 60 800

3 Mbps

Packet loss

0 2 5 10 30 60 800

1 Mbps

Packet loss

0 2 5 10 30 60 800

10 Mbps

Packet loss

0 2 5 10 30 60 800

50 Kbps

Packet loss

0 2 5 10 30 60 800

500 Kbps

Packet loss

0 2 5 10 30 60 800

10 Mbps

Packet loss

0 2 5 10 30 60 800

50 Kbps

Packet loss

0 2 5 10 30 60 800

2 2 2 2 2 21

0 0 0 0 0 0 0

100 Mbps

Packet loss

0 2 5 10 30 60 800

2 2 2 2 2 1 10 0 0 0 0 0 0

50 Mbps

Packet loss

0 2 5 10 30 60 800

2 2 2 2 21 10 0 0 0 0 0 0

10 Mbps

Packet loss

0 2 5 10 30 60 800

2 2 2 2 21

00 0 0 0 0 0 0

3 Mbps

Packet loss

0 2 5 10 30 60 800

2 2 2 2 21

00 0 0 0 0 0 0

3 Mbps

Packet loss

0 2 5 10 30 60 800

2 2 2 21 1

00 0 0 0 0 0 0

1 Mbps

Packet loss

0 2 5 10 30 60 800

2 2 2 2 10 00 0 0 0 0 0 0

50 Kbps

Packet loss

0 2 5 10 30 60 800

2 2 2 2 2 100 0 0 0 0 0 0

500 Kbps

Packet loss

0 2 5 10 30 60 800

2 2 2 2 10 00 0 0 0 0 0 0

50 Kbps

Packet loss

ltresourcegt

ltapplicationgt

Bibliography

Introduction

Motivation



Structure

Background



Services in Web

RESTful services




Swagger

RIDDL



Summary

State of the Art


Design Rules



Conclusion





Conclusion




DR-OSGI

FT-REST

Conclusion

Summary



Discussion




Summary

Implementation





Basic components

Extension points





Summary

Evaluation

Test environment

Objective testing

Test preconditions

Results discussion


Description

Results discussion


Summary

Epilogue

Conclusion







Bibiliography

1 Introduction

Mobile application

System

Service

laquousesraquo

Mobile application

System

Mobile application

Service

If data is in cache

laquousesraquo

System

1 Introduction

2 Background

223 Swagger

5httpwwwwordnikcom

2 Background

6httpwwwwrmlorg

2 Background

3 State of the Art

developers

Data model

3 State of the Art

HTTP response codes

Data adaptation

c compression

3 Data reduction

b lossy conversion

c pagination

Provided SDKs

3 State of the Art

mdash mdash mdash

3 State of the Art

HTTP Status Codes

mdash mdash

1b 3a 3c

3 State of the Art

314 Conclusion

3 State of the Art

Android features

3 State of the Art

+ + + + ndash

Exception wrap-ping

+ + + ndash +

3 State of the Art

AndroidSDK

AmazonS3 AndroidSDK

FT-REST

Requests Executor

Service

1 Network Manager

2 Requests Executor

3 Requests Queue

4 Cache

intraquo

laquotr

nraquo

laquocu

nraquo

Controller

Adaptive Execution

Controller

Network Errors

Service Errors

Service API

Check of cache

time signal

Stage 1

Stage 2

Stage 3

Cache hit

API mappingplugin

Request Execmanager

Cachemanager

configuration

getCachedResponse()

a l tcachedResponse

generatedResponse

generateResponse()

responseFromServer

handleResponse()

responseFromServer

Server

Request Execmanager

RequestQueue

NetworkManager

canonicalRequest

Service

request

getRequest()

[network connected]

triggerExecution()

wait()

responseFromServer

isConnected()

executeRequest()

sendResponse()

retry()

sendRequest()

Client

checkResponse()

backOffEstimation()

t imeout()

canRetry()

retry()canRetry()

constructResponse()

in the Section 44

5 Implementation

apimapper

uicomponents

codegenerator

datainterfaces

handlers

datatypes

dataprocessing

orgtudresup

adaptation

entit ies

executionhandlers

network

adcomp

entit ies

pdcomp

network

5 Implementation

Datatypes

Handlers

Wizard

RequestGenerator

AbstractReSupWizard

5 Implementation

BaseQueue

5 Implementation

HttpCacheStorage

CacheStorageFactory

+CUSTOM_STORAGEint

Client

IQueueStorage

5 Implementation

ReSupRequest

FirstCustomRequest

N-CustomRequest

Message handlers

5 Implementation

Step 1

Caching

Yes No

Step 2

Asynchrony

Yes No

5 Implementation

bull OS Ubuntu 1204

6 Evaluation

SoundCloudBase URI

HTTP11 200 OK

6 Evaluation

Packet loss 0 5 10 30 60 80

Bandwidth 100Mbps

50Mbps

10Mbps

50Kbps

mobile(3G)

mobile(EDGE)

mobile(GPRS)

1 Network awareness

2 Asynchrony

0 2 5 10 30 60 800

100 Mbps

Packet loss

0 2 5 10 30 60 800

100 Mbps

Packet loss

0 2 5 10 30 60 800

3 Mbps

Packet loss

0 2 5 10 30 60 800

10 Mbps

Packet loss

0 2 5 10 30 60 800

50 Kbps

Packet loss

6 Evaluation

0 2 5 10 30 60 800

2 2 2 2 2 21

0 0 0 0 0 0 0

100 Mbps

Packet loss

0 2 5 10 30 60 800

2 2 2 2 21

00 0 0 0 0 0 0

3 Mbps

Packet loss

0 2 5 10 30 60 800

2 2 2 2 10 00 0 0 0 0 0 0

50 Kbps

Packet loss

Cache performance

Timing

6 Evaluation

0 10 20 30 40 50 60 70 80

100 Mbps - 0

10 Mbps ndash 5

1 Mbps ndash 30

50 Kbps ndash 80

146 151 152

297 286

144 150 150 152 159

191267

1 API Mapping tool

WADL etc)

6 Evaluation

default

6 Evaluation

yes yes

no yes

7 Epilogue

c compression

3 Data reduction

b lossy conversion

c pagination

1b 1c 3c 1b 1c 2a 3c 1b 2a 3c

mdash mdash mdash

Custom HTTP schema

HTML XML JSON

HTTP Status Codes

mdash mdash mdash

1c 1b 3a 3c

Command Line Client

0 2 5 10 30 60 800

100 Mbps

Packet loss

0 2 5 10 30 60 800

100 Mbps

Packet loss

0 2 5 10 30 60 800

3 Mbps

Packet loss

0 2 5 10 30 60 800

50 Mbps

Packet loss

0 2 5 10 30 60 800

10 Mbps

Packet loss

0 2 5 10 30 60 800

3 Mbps

Packet loss

0 2 5 10 30 60 800

1 Mbps

Packet loss

0 2 5 10 30 60 800

10 Mbps

Packet loss

0 2 5 10 30 60 800

50 Kbps

Packet loss

0 2 5 10 30 60 800

500 Kbps

Packet loss

0 2 5 10 30 60 800

10 Mbps

Packet loss

0 2 5 10 30 60 800

50 Kbps

Packet loss

0 2 5 10 30 60 800

2 2 2 2 2 21

0 0 0 0 0 0 0

100 Mbps

Packet loss

0 2 5 10 30 60 800

2 2 2 2 2 1 10 0 0 0 0 0 0

50 Mbps

Packet loss

0 2 5 10 30 60 800

2 2 2 2 21 10 0 0 0 0 0 0

10 Mbps

Packet loss

0 2 5 10 30 60 800

2 2 2 2 21

00 0 0 0 0 0 0

3 Mbps

Packet loss

0 2 5 10 30 60 800

2 2 2 2 21

00 0 0 0 0 0 0

3 Mbps

Packet loss

0 2 5 10 30 60 800

2 2 2 21 1

00 0 0 0 0 0 0

1 Mbps

Packet loss

0 2 5 10 30 60 800

2 2 2 2 10 00 0 0 0 0 0 0

50 Kbps

Packet loss

0 2 5 10 30 60 800

2 2 2 2 2 100 0 0 0 0 0 0

500 Kbps

Packet loss

0 2 5 10 30 60 800

2 2 2 2 10 00 0 0 0 0 0 0

50 Kbps

Packet loss

ltresourcegt

ltapplicationgt

Bibliography

Introduction

Motivation



Structure

Background



Services in Web

RESTful services




Swagger

RIDDL



Summary

State of the Art


Design Rules



Conclusion





Conclusion




DR-OSGI

FT-REST

Conclusion

Summary



Discussion




Summary

Implementation





Basic components

Extension points





Summary

Evaluation

Test environment

Objective testing

Test preconditions

Results discussion


Description

Results discussion


Summary

Epilogue

Conclusion







Bibiliography

Mobile application

System

Mobile application

Service

If data is in cache

laquousesraquo

System

1 Introduction

2 Background

223 Swagger

5httpwwwwordnikcom

2 Background

6httpwwwwrmlorg

2 Background

3 State of the Art

developers

Data model

3 State of the Art

HTTP response codes

Data adaptation

c compression

3 Data reduction

b lossy conversion

c pagination

Provided SDKs

3 State of the Art

mdash mdash mdash

3 State of the Art

HTTP Status Codes

mdash mdash

1b 3a 3c

3 State of the Art

314 Conclusion

3 State of the Art

Android features

3 State of the Art

+ + + + ndash

Exception wrap-ping

+ + + ndash +

3 State of the Art

AndroidSDK

AmazonS3 AndroidSDK

FT-REST

Requests Executor

Service

1 Network Manager

2 Requests Executor

3 Requests Queue

4 Cache

intraquo

laquotr

nraquo

laquocu

nraquo

Controller

Adaptive Execution

Controller

Network Errors

Service Errors

Service API

Check of cache

time signal

Stage 1

Stage 2

Stage 3

Cache hit

API mappingplugin

Request Execmanager

Cachemanager

configuration

getCachedResponse()

a l tcachedResponse

generatedResponse

generateResponse()

responseFromServer

handleResponse()

responseFromServer

Server

Request Execmanager

RequestQueue

NetworkManager

canonicalRequest

Service

request

getRequest()

[network connected]

triggerExecution()

wait()

responseFromServer

isConnected()

executeRequest()

sendResponse()

retry()

sendRequest()

Client

checkResponse()

backOffEstimation()

t imeout()

canRetry()

retry()canRetry()

constructResponse()

in the Section 44

5 Implementation

apimapper

uicomponents

codegenerator

datainterfaces

handlers

datatypes

dataprocessing

orgtudresup

adaptation

entit ies

executionhandlers

network

adcomp

entit ies

pdcomp

network

5 Implementation

Datatypes

Handlers

Wizard

RequestGenerator

AbstractReSupWizard

5 Implementation

BaseQueue

5 Implementation

HttpCacheStorage

CacheStorageFactory

+CUSTOM_STORAGEint

Client

IQueueStorage

5 Implementation

ReSupRequest

FirstCustomRequest

N-CustomRequest

Message handlers

5 Implementation

Step 1

Caching

Yes No

Step 2

Asynchrony

Yes No

5 Implementation

bull OS Ubuntu 1204

6 Evaluation

SoundCloudBase URI

HTTP11 200 OK

6 Evaluation

Packet loss 0 5 10 30 60 80

Bandwidth 100Mbps

50Mbps

10Mbps

50Kbps

mobile(3G)

mobile(EDGE)

mobile(GPRS)

1 Network awareness

2 Asynchrony

0 2 5 10 30 60 800

100 Mbps

Packet loss

0 2 5 10 30 60 800

100 Mbps

Packet loss

0 2 5 10 30 60 800

3 Mbps

Packet loss

0 2 5 10 30 60 800

10 Mbps

Packet loss

0 2 5 10 30 60 800

50 Kbps

Packet loss

6 Evaluation

0 2 5 10 30 60 800

2 2 2 2 2 21

0 0 0 0 0 0 0

100 Mbps

Packet loss

0 2 5 10 30 60 800

2 2 2 2 21

00 0 0 0 0 0 0

3 Mbps

Packet loss

0 2 5 10 30 60 800

2 2 2 2 10 00 0 0 0 0 0 0

50 Kbps

Packet loss

Cache performance

Timing

6 Evaluation

0 10 20 30 40 50 60 70 80

100 Mbps - 0

10 Mbps ndash 5

1 Mbps ndash 30

50 Kbps ndash 80

146 151 152

297 286

144 150 150 152 159

191267

1 API Mapping tool

WADL etc)

6 Evaluation

default

6 Evaluation

yes yes

no yes

7 Epilogue

c compression

3 Data reduction

b lossy conversion

c pagination

1b 1c 3c 1b 1c 2a 3c 1b 2a 3c

mdash mdash mdash

Custom HTTP schema

HTML XML JSON

HTTP Status Codes

mdash mdash mdash

1c 1b 3a 3c

Command Line Client

0 2 5 10 30 60 800

100 Mbps

Packet loss

0 2 5 10 30 60 800

100 Mbps

Packet loss

0 2 5 10 30 60 800

3 Mbps

Packet loss

0 2 5 10 30 60 800

50 Mbps

Packet loss

0 2 5 10 30 60 800

10 Mbps

Packet loss

0 2 5 10 30 60 800

3 Mbps

Packet loss

0 2 5 10 30 60 800

1 Mbps

Packet loss

0 2 5 10 30 60 800

10 Mbps

Packet loss

0 2 5 10 30 60 800

50 Kbps

Packet loss

0 2 5 10 30 60 800

500 Kbps

Packet loss

0 2 5 10 30 60 800

10 Mbps

Packet loss

0 2 5 10 30 60 800

50 Kbps

Packet loss

0 2 5 10 30 60 800

2 2 2 2 2 21

0 0 0 0 0 0 0

100 Mbps

Packet loss

0 2 5 10 30 60 800

2 2 2 2 2 1 10 0 0 0 0 0 0

50 Mbps

Packet loss

0 2 5 10 30 60 800

2 2 2 2 21 10 0 0 0 0 0 0

10 Mbps

Packet loss

0 2 5 10 30 60 800

2 2 2 2 21

00 0 0 0 0 0 0

3 Mbps

Packet loss

0 2 5 10 30 60 800

2 2 2 2 21

00 0 0 0 0 0 0

3 Mbps

Packet loss

0 2 5 10 30 60 800

2 2 2 21 1

00 0 0 0 0 0 0

1 Mbps

Packet loss

0 2 5 10 30 60 800

2 2 2 2 10 00 0 0 0 0 0 0

50 Kbps

Packet loss

0 2 5 10 30 60 800

2 2 2 2 2 100 0 0 0 0 0 0

500 Kbps

Packet loss

0 2 5 10 30 60 800

2 2 2 2 10 00 0 0 0 0 0 0

50 Kbps

Packet loss

ltresourcegt

ltapplicationgt

Bibliography

Introduction

Motivation



Structure

Background



Services in Web

RESTful services




Swagger

RIDDL



Summary

State of the Art


Design Rules



Conclusion





Conclusion




DR-OSGI

FT-REST

Conclusion

Summary



Discussion




Summary

Implementation





Basic components

Extension points





Summary

Evaluation

Test environment

Objective testing

Test preconditions

Results discussion


Description

Results discussion


Summary

Epilogue

Conclusion







Bibiliography

1 Introduction

2 Background

223 Swagger

5httpwwwwordnikcom

2 Background

6httpwwwwrmlorg

2 Background

3 State of the Art

developers

Data model

3 State of the Art

HTTP response codes

Data adaptation

c compression

3 Data reduction

b lossy conversion

c pagination

Provided SDKs

3 State of the Art

mdash mdash mdash

3 State of the Art

HTTP Status Codes

mdash mdash

1b 3a 3c

3 State of the Art

314 Conclusion

3 State of the Art

Android features

3 State of the Art

+ + + + ndash

Exception wrap-ping

+ + + ndash +

3 State of the Art

AndroidSDK

AmazonS3 AndroidSDK

FT-REST

Requests Executor

Service

1 Network Manager

2 Requests Executor

3 Requests Queue

4 Cache

intraquo

laquotr

nraquo

laquocu

nraquo

Controller

Adaptive Execution

Controller

Network Errors

Service Errors

Service API

Check of cache

time signal

Stage 1

Stage 2

Stage 3

Cache hit

API mappingplugin

Request Execmanager

Cachemanager

configuration

getCachedResponse()

a l tcachedResponse

generatedResponse

generateResponse()

responseFromServer

handleResponse()

responseFromServer

Server

Request Execmanager

RequestQueue

NetworkManager

canonicalRequest

Service

request

getRequest()

[network connected]

triggerExecution()

wait()

responseFromServer

isConnected()

executeRequest()

sendResponse()

retry()

sendRequest()

Client

checkResponse()

backOffEstimation()

t imeout()

canRetry()

retry()canRetry()

constructResponse()

in the Section 44

5 Implementation

apimapper

uicomponents

codegenerator

datainterfaces

handlers

datatypes

dataprocessing

orgtudresup

adaptation

entit ies

executionhandlers

network

adcomp

entit ies

pdcomp

network

5 Implementation

Datatypes

Handlers

Wizard

RequestGenerator

AbstractReSupWizard

5 Implementation

BaseQueue

5 Implementation

HttpCacheStorage

CacheStorageFactory

+CUSTOM_STORAGEint

Client

IQueueStorage

5 Implementation

ReSupRequest

FirstCustomRequest

N-CustomRequest

Message handlers

5 Implementation

Step 1

Caching

Yes No

Step 2

Asynchrony

Yes No

5 Implementation

bull OS Ubuntu 1204

6 Evaluation

SoundCloudBase URI

HTTP11 200 OK

6 Evaluation

Packet loss 0 5 10 30 60 80

Bandwidth 100Mbps

50Mbps

10Mbps

50Kbps

mobile(3G)

mobile(EDGE)

mobile(GPRS)

1 Network awareness

2 Asynchrony

0 2 5 10 30 60 800

100 Mbps

Packet loss

0 2 5 10 30 60 800

100 Mbps

Packet loss

0 2 5 10 30 60 800

3 Mbps

Packet loss

0 2 5 10 30 60 800

10 Mbps

Packet loss

0 2 5 10 30 60 800

50 Kbps

Packet loss

6 Evaluation

0 2 5 10 30 60 800

2 2 2 2 2 21

0 0 0 0 0 0 0

100 Mbps

Packet loss

0 2 5 10 30 60 800

2 2 2 2 21

00 0 0 0 0 0 0

3 Mbps

Packet loss

0 2 5 10 30 60 800

2 2 2 2 10 00 0 0 0 0 0 0

50 Kbps

Packet loss

Cache performance

Timing

6 Evaluation

0 10 20 30 40 50 60 70 80

100 Mbps - 0

10 Mbps ndash 5

1 Mbps ndash 30

50 Kbps ndash 80

146 151 152

297 286

144 150 150 152 159

191267

1 API Mapping tool

WADL etc)

6 Evaluation

default

6 Evaluation

yes yes

no yes

7 Epilogue

c compression

3 Data reduction

b lossy conversion

c pagination

1b 1c 3c 1b 1c 2a 3c 1b 2a 3c

mdash mdash mdash

Custom HTTP schema

HTML XML JSON

HTTP Status Codes

mdash mdash mdash

1c 1b 3a 3c

Command Line Client

0 2 5 10 30 60 800

100 Mbps

Packet loss

0 2 5 10 30 60 800

100 Mbps

Packet loss

0 2 5 10 30 60 800

3 Mbps

Packet loss

0 2 5 10 30 60 800

50 Mbps

Packet loss

0 2 5 10 30 60 800

10 Mbps

Packet loss

0 2 5 10 30 60 800

3 Mbps

Packet loss

0 2 5 10 30 60 800

1 Mbps

Packet loss

0 2 5 10 30 60 800

10 Mbps

Packet loss

0 2 5 10 30 60 800

50 Kbps

Packet loss

0 2 5 10 30 60 800

500 Kbps

Packet loss

0 2 5 10 30 60 800

10 Mbps

Packet loss

0 2 5 10 30 60 800

50 Kbps

Packet loss

0 2 5 10 30 60 800

2 2 2 2 2 21

0 0 0 0 0 0 0

100 Mbps

Packet loss

0 2 5 10 30 60 800

2 2 2 2 2 1 10 0 0 0 0 0 0

50 Mbps

Packet loss

0 2 5 10 30 60 800

2 2 2 2 21 10 0 0 0 0 0 0

10 Mbps

Packet loss

0 2 5 10 30 60 800

2 2 2 2 21

00 0 0 0 0 0 0

3 Mbps

Packet loss

0 2 5 10 30 60 800

2 2 2 2 21

00 0 0 0 0 0 0

3 Mbps

Packet loss

0 2 5 10 30 60 800

2 2 2 21 1

00 0 0 0 0 0 0

1 Mbps

Packet loss

0 2 5 10 30 60 800

2 2 2 2 10 00 0 0 0 0 0 0

50 Kbps

Packet loss

0 2 5 10 30 60 800

2 2 2 2 2 100 0 0 0 0 0 0

500 Kbps

Packet loss

0 2 5 10 30 60 800

2 2 2 2 10 00 0 0 0 0 0 0

50 Kbps

Packet loss

ltresourcegt

ltapplicationgt

Bibliography

Introduction

Motivation



Structure

Background



Services in Web

RESTful services




Swagger

RIDDL



Summary

State of the Art


Design Rules



Conclusion





Conclusion




DR-OSGI

FT-REST

Conclusion

Summary



Discussion




Summary

Implementation





Basic components

Extension points





Summary

Evaluation

Test environment

Objective testing

Test preconditions

Results discussion


Description

Results discussion


Summary

Epilogue

Conclusion







Bibiliography

Application-agnostic resource-centric service handling support for

Documents