1 An Investigation of Software Bloat in Web Services K.G.P Thilini 1 , Chamath Keppetiyagama 2 University of Colombo School of Computing No 35, Reid Avenue, Colombo 7, Sri Lanka 1 thilini.gunasekara@gmail.com 2 chamath@ucsc.cmb.ac.lk Abstract—Web services marked a remarkable milestone in the field of distributed computing. But its performance over the ben- efits such as interoperability, modularity was questioned all the time. Due to the added extra layers to facilitate interoperability and modularity contributes heavily to the run-time bloat under different forms, such as excess function calls, generation of excess objects and creation of excessively large data structures. Hence also contributes to more CPU cycles. The research goes beyond just measuring performance of web services, but more focuses on measuring execution bloat associated with web service in terms of energy, memory bloat based on heap memory usage and code bloat in terms of lines of code executed. Index Terms—Web Services, Software Bloat, Runtime Bloat, Code Bloat, SOAP, RPC I. I NTRODUCTION D URING the past two decades software design paradigms have evolved to prioritize programmer productivity over runtime efficiency in some degree due to the dramatic improvements in performance enabled through CMOS(Complementary metaloxidesemiconductor) technology[1]. As enterprises grow, and as the complexity involved in the enterprise integration has increased progressively with time, a number of integration patterns have also evolved over time[2]. RPC (Remote Procedure Calls) is one of the foremost enterprise level integration pattern which is almost obsolete partly due to the above reasons[3]. Instead a successor integration pattern, web services has come in to play[3]. Coding for RPC is much harder than coding for web services and takes time but the gain is in performance. Web services have taken off most of the hard work from the programmers and have provided flexibility, re usability, modularity and interoperability which comes handy in large enterprise level integrations[1]. Having said that, there is always a catch when enabling rapid developments and taking off programmers out of the misery since programmers have to sacrifice program performance for working faster and eventually lead to encounter runtime bloat[1]. The word bloat is horrifying but the outcome is not so noticeable because unlike in older days, today we have increased processing capacity and storage density by orders of magnitude to hold on to whatever performance the web services provide[4]. But to be reasonable this is not a good sign for future, we can’t expect to keep increasing processing capacity and storage density which violates Moore’s law just to get away from poor web services performance[5]. Over-utilizing resources leads to higher power consumptions and waste energy in high magnitudes and it is just the time people should be more aware about the consequences[1]. SOAP based web services are standardized around deeply lay- ered frameworks where each layer facilitates interoperability, higher degree of flexibility for reuse and modularity[1]. This layered architecture of web services have made programmer life much easier but on the other hand these added extra layers heavily contributes to the runtime bloat in many different forms[1]. 1) Excess function calls 2) Generation of excess objects 3) Creation of excessively large data structures Having said SOAP based web services are very flexible, with this flexibility comes a large overhead, for an example data access and business logic in SOAP based web services is decoupled in to two different layers called data access layer and business logic layer, hence the communication overhead between these two layers are high[1]. Flexibility have made SOAP based web services more and more appealing to large enterprise applications, for an example Google is known to use SOAP based web services in lots of their applications[6]. These large scale framework based enterprise systems often incur large resource overhead for typical execution scenarios results higher power consumption and wasted energy[1]. In this research using WSO2 identity server as the use case we intend to measure execution bloat associated with SOAP based web service implementations in terms of energy with compared to the exact RPC implementations which is assumed to be minimal bloated. Also for the same scenarios we showcase memory bloat based on heap memory usage and code bloat in terms of lines of code executed. The objective of this research is to identify the execution bloat in a typical web service execution scenario in terms of energy, memory bloat based on heap memory usage, code bloat in terms of lines of code executed and build a comparison with other standard way of communications, like through RPC. II. DESIGN The design is mostly focused on calculating software bloat under following two categories. 1) Runtime bloat