ReSup (RESTful Support), a Java framework for the development of service- bound mobile and desktop applications, turns the RAFT-REST concepts into practice for service clients implemented with the Java language and correspond- ing networking libraries. ReSup consists of a proxy library located between the application and the network stack, similar to existing HTTP client libraries, and an Eclipse wizard to generate service-specific message classes by mapping API specifications to code. A screenshot of the wizard in Fig. 4 highlights the possib- lity to import WADL (Web Application Description Language) service descrip- tions to reduce the manual class modelling effort [8]. Both the wizard and the library need to be present as JAR files (org.tud.resup.apimapper_1.0.0.
2013MMDD.jar, Resup_1.0.0.2013MMDD.jar) in the plugins folder of Eclipse.
The library is subsequently copied into the resulting project archive and used at runtime.
The ReSup library delivers and caches message objects which may be created manually in the application code or as instantiations of the generated classes. Each message object represents a service resource or a request targeting one. The way ReSup is used depends mainly on the application requirements. Fig. 5 demonstrates the possible configuration directive combinations.
Fig. 4.Eclipse wizard to generate API mapping classes for use with the ReSup library
Fig. 5.Flexible configuration of the ReSup objects depending on the desired applica- tion behaviour
The integration of ReSup is particularly easy by its HttpClient interface which mimicks the API of the widely used ApacheHttpClientlibrary. Hence, develop- ers can switch to ReSup by just substituting a Java import statement and after- wards gradually turning on and testing its RAFT features. ReSup can also run as a transparent stand-alone proxy so that applications do not have to be modified except for a system-wide forced HTTP proxy configuration. Proxies, gateways and networked intermediaries are common architectural elements for RESTful service consumption [5]. However, on mobile systems such as Android, this requires sys- tem modification access and is therefore often not a viable solution.
In order to demonstrate the capabilities of ReSup, and therefore acknowledge the RAFT-REST concepts, we have performed a number of measurements and experiments in an evaluation study which includes existing services with REST- ful interfaces in both simulated and real imperfect networks. Fig. 6 shows the setup of the experiment. Off-the-shelf networking tools such as Burp, an inter- cepting proxy, Trickle, a bandwidth variator, and Netem, a packet loss generator, are used to simulate reproducible low-quality connections. Trickle allows scaling the bandwidth within the constraints imposed by the hardware from a zero- throughput connection to the typical speeds of mobile networks, WLANs and LANs. Netem varies typical WAN parameters such as delay, loss, duplication and re-ordering (shuffling).
Fig. 6.Test suite for the experiments involving RESTful services and clients using the ReSup library
The test environment consisted of the test suite running on an Intel Core i5 machine with 4 times 2.4 GHz CPUs, 3 GB DDR2 RAM, the Ubuntu 12.04 operating system and Java 1.6.
The results are shown in Fig. 7 and 8, respectively. The first diagram shows the distribution of error responses still successfully received from one of the test runs, in this case a mobile connection with 50 kbps. On the whole range of possible network losses, ReSup retrieves a higher number of error reponses compared to a pure HttpClient connection. The increase is between 35% and 92%, but still recovers less than half of the lost packets when the loss rate exceeds 80%. The second diagram measures the overall response times over a bivariate range from a perfect connection (100 Mbps with 0% loss) to a nearly unusable one (50 kbps with 80% loss). Due to the caching, ReSup is much faster for all good-enough connections and considerably slower than HttpClient for all worse ones due to the retries. Yet, the retries contribute to the higher success rate as shown in 7, therefore even the highest run-time overhead of 55,4% for a 500 kbps connection with 60% loss will eventually improve the user experience in practice.
Fig. 8.Response times evaluation
5
Conclusion
We have motivated and discussed RAFT-REST, a client-side RESTful service in- tegration concept which addresses reliability, safety and quality concerns. Compared to previous integration concepts, the combination of conventional fault-tolerance schemes, graceful error handling and caching achieves a great user experience for distributed applications connected by imperfect networks. The ReSup framework targets mobile application developers through an API- compatible HTTP client library and an Eclipse code engineering plugin with the aim to increase real-world application robustness through RAFT-REST. It is made available as open source toolkit for use and further improvements1.
Subsequent research questions focus on the global view, i.e. the server-side and total load behaviour when using any of the offered RAFT-REST mecha- nisms, as well as on extended validation with real-time statistics collection and visualisation for immediate feedback about the waiting state of applications to the user.
Acknowledgements. This work has received funding under project number 080949277 by means of the European Regional Development Fund (ERDF), the European Social Fund (ESF) and the German Free State of Saxony.
References
1. Aihkisalo, T., Paaso, T.: Latencies of Service Invocation and Processing of the REST and SOAP Web Service Interfaces. In: Eighth IEEE World Congress on Services (SERVICES), Hawaii, USA, pp. 100–107 (June 2012)
2. Belqasmi, F., Glitho, R.H., Fu, C.: RESTful Web Services for Service Provisioning in Next-Generation Networks: A Survey. IEEE Communications Magazine 49(12), 66–73 (2011)
3. Edstrom, J., Tilevich, E.: Reusable and Extensible Fault Tolerance for REST- ful Applications. In: 11th International Conference on Trust, Security and Pri- vacy in Computing and Communications (TrustCom), pp. 737–744 (June 2012), doi:10.1109/TrustCom.2012.244
4. Fielding, R.T.: Architectural Styles and the Design of Network-based Software Architectures. Ph.D. thesis, University of California, Irvine (2000)
5. Kelly, M., Hausenblas, M.: Using HTTP Link: Header for Gateway Cache Inval- idation. In: Proceedings of the First International Workshop on RESTful Design (WS-REST), Raleigh, North Carolina, USA, pp. 23–26 (April 2010)
6. Kwon, Y.-W., Tilevich, E., Apiwattanapong, T.: DR-OSGi: Hardening Distributed Components with Network Volatility Resiliency. In: Bacon, J.M., Cooper, B.F. (eds.) Middleware 2009. LNCS, vol. 5896, pp. 373–392. Springer, Heidelberg (2009) 7. Leitner, P., Rosenberg, F., Dustdar, S.: Daios – Efficient Dynamic Web Service
Invocation. Internet Computing 13(3), 72–80 (2009)
8. Maleshkova, M., Pedrinaci, C., Domingue, J.: Supporting the creation of seman- tic RESTful service descriptions. In: 8th International Semantic Web Conference (ISWC), Washington D.C., USA (October 2009)
9. Masse, M.: REST API Design Rulebook. O’Reilly (2011)
10. Mulligan, G., Gracanin, D.: A comparison of SOAP and REST implementations of a service based interaction independence middleware framework. In: Proceedings of the Winter Simulation Conference (WSC), Austin, Texas, USA, pp. 1423–1432 (December 2009)
11. Mulloy, B.: Web API Design: Crafting Interfaces that Developers Love. e-Book (March 2012)
12. Salatge, N., Fabre, J.C.: Fault Tolerance Connectors for Unreliable Web Services. In: 37th Annual IEEE/IFIP International Conference on Dependable Systems and Networks (DSN), Edinburgh, UK, pp. 51–60 (June 2007)
13. Santos, G.T., Lung, L.C., Montez, C.: FTWeb: A Fault Tolerant Infrastructure for Web Services. In: Proceedings of the Ninth IEEE International EDOC Enterprise Computing Conference, Enschede, The Netherlands, pp. 95–105 (September 2005) 14. Tilkov, S.: REST Anti-Patterns. InfoQ Article (July 2008)
15. VanderMeer, D., Datta, A., Dutta, K., Ramamritham, K., Navathe, S.B.: Mobile User Recovery in the Context of Internet Transactions. IEEE Transactions on Mobile Computing 2(2), 132–146 (2003)