SOCA

DOI 10.1007/s11761-015-0186-x

ORIGINAL RESEARCH PAPER

An aggregated technique for optimization of SOAP performance

in communication in Web services
Kennedy Mutange Senagi1 George Okeyo2 Wilson Cheruiyot2
Michael Kimwele2

Received: 12 July 2014 / Revised: 20 August 2015 / Accepted: 19 October 2015

Springer-Verlag London 2015

Abstract Simple Object Access Protocol (SOAP) among

other techniques implements Web Services (WS). SOAP
offers a lightweight and simple mechanism for exchange of
structured and typed information among computing devices
in a decentralized, distributed computing environment. However, SOAP transmits data in Extensible Markup Language
(XML) format. XML documents are huge in size and verbose thus becoming a major hindrance in performance for
high-performance applications that process lots of data.
In this paper, we develop, implement and evaluate SOAP
performance optimization aggregated architecture in a disadvantaged network, i.e., 10 Mbps bandwidth. The aggregated
architecture entailed: client side caching, documentliteral
Web Services Description Language (WSDL) description,
simple database queries on the server side and Gzip compression technique. The experimental results showed a relatively
high turnaround time and low network throughput. Nevertheless, improved performance of SOAP is evident in terms
of bandwidth utilization and transfer time. This can be useful
in disadvantaged networks.

Kennedy Mutange Senagi

kensenagi@gmail.com
George Okeyo
gokeyo@icsit.jkuat.ac.ke
Wilson Cheruiyot
wilchery68@jkuat.ac.ke
Michael Kimwele
mikekimwele@yahoo.com

Department of Information Technology, Dedan Kimathi

University of Technology, Nyeri, Kenya

Department of Computing, Jomo Kenyatta University

of Agriculture and Technology, Nairobi, Kenya

Keywords SOA Web services SOAP XML SOAP

optimization Disadvantaged network and SOAP evaluation

1 Introduction
The Internet is growing very fast, and it has become an important tool in communication, providing services and sharing
information. Many organizations, institutions and individuals have embraced Internet in many ways, e.g., e-commerce,
blogs, etc. Such services can be provided on the Internet by
using Service-Oriented Architecture (SOA), Web-Oriented
Architecture (WOA) etc. [1]. There are various technologies
that implement SOA, including Common Object Request
Broker Architecture (CORBA) [2], Java Remote Method
Invocation (RMI) [3], Component Object Model (COM) [4]
and Web services (WS) [5].
Implementation of WS using SOAP gives it the capability of being platform independent and the ability of
going through firewalls without being recognized. Firewalls
by default allow traffic through port 80 which Hypertext
Transfer Protocol (HTTP) uses in communication. SOAP
messages are encapsulated within HTTP and transmitted
using the GET/PUT operations. HTTP is a universal standard
in the World Wide Web (WWW). Thus, WS work in heterogeneous systems and makes it stand out among its equals
which are monolithic in nature [6,7].
SOAP does the packaging of actual messages being
transmitted in a communication channel. It relies on XML
in formatting messages. WS can process XML-formatted
SOAP messages. XML and SOAP use their own service
description to deal with the service-specific characteristics
of messages it receives [6].
SOAP provides a lightweight and simple mechanism for
exchange of structured and typed information in decen-

123

SOCA

tralized, distributed environments using XML. XML has a

redundant annotated data structure [6]. SOAPs XML-based
message structure is verbose, which results in high network
traffic and XML parsing and processing. This causes a high
computational burden leading to high latency. SOAPs XMLbased message format hinders its performance. This makes it
unsuitable for high-performance scientific applications. The
deserialization of SOAP messages, which comprises processing of XML data and conversion of strings to in-memory data
types, is one of the major performance drawbacks in a SOAP
message exchange [7,8].
The main contribution of this paper is we developed
a novel technique that optimizes SOAP performance in a
disadvantaged network. The technique aggregates: client
side caching, documentliteral WSDL description, simple
database queries on the server side and Gzip compression.
This technique improved compression ratio, which enhanced
bandwidth utilization. It also improved transfer time, which
reduced the time to send messages from client to server and
vice versa.
The rest of this paper is organized as follows: Sect. 2
discusses related work, Sect. 3 presents the developed architecture and its implementation, Sect. 4 provides experimental
results and discussion, and Sect. 5 concludes this paper.

2 Related work
The dependence of SOAP on XML in messaging is the major
hindrance in performance for high-performance applications.
There is a lot of research on optimize SOAP performance in
WS communication.
One approach is the client side caching. It has been
embraced to improve traffic and latency between a service
and underlying data providers [911]. Client side caching
can store data temporarily in the Internet browsers or by
JavaScript data structures. In client side caching, data are
stored by the client side browser temporarily on the local
disk or Web browsers internal memory. Some browsers have
a limited amount of storage space thus a problem when
the limits are exceeded [11]. Differential Serialization (DS)
avoids serializing of the whole message structure. In DS,
once a serialized message has been sent by a SOAP communication endpoint, the client saves the message so that it
can be reused by subsequent messages as a template. Subsequent messages that have the same structure or are identical
can reuse the structure and avoid the serialization overhead
involved in regenerating the structures from scratch. This
technique improves response time [7,8,1215].
Moreover, WSDL describes the public interface to a specific Web service. WSDL binding describes how the service
is bound on the SOAP messaging protocol [16]. Common SOAP binding styles are RPC-encode and document

123

literal. RPC has more overheads than documentliteral [1].

Phil et al. [1] and IBM [11] recommended adoption of
documentliteral over RPC style. RPC style requires 15 %
more time than documentliteral [17]. Experiments built
on documentliteral encoding style were faster than RPC
[18]. Compression was also noted to be a promising solution
while handling the huge and verbose SOAPs XML messages. Lossless compression algorithm exploits statistical
redundancy to represent the senders data more concisely
without errors. A lossless compression algorithm is good
for SOAPs XML messages which have redundant text [18].
Lossless compression algorithms include Gzip, Bzip2, Fast
Infoset (FI), Efficient XML Interchange (EXI) [1820]. Gzip
compression algorithm was recommended in disadvantaged
network [19]. Compression improved bandwidth utilization
and response time of SOAP messages [9,10,18,19,21,22].
One of the compression trade-off is between compression
processing time and the CPU processing [23]. However, with
the increasing hardware processing capabilities, this trade-off
is beneficial compared to the cost of increasing bandwidth
which is widely under constrains [7,21].
Server side caching improves response time. It is a SOAP
performance optimization technique explored and supported
by [9,11,24]. Server side caching is slightly different from
client side caching as data are temporarily stored in serialized objects [11]. In server side data chunking, the client
specifies the range of data in the request. The server then composes the chunk and returns it. This improves performance
of loading sustainable large amounts of data, by doing so
in chunks or bits [10,25]. Moreover, in server side caching,
database caching gives a better way of modifying data. It
eliminates the need to parse an entire XML structure which
is computationally expensive [11,26]. Another SOAP performance optimization technique is Differential Deserialization
(DDS). It works on the server side. DDS technique has been
supported by [8,9,13,14,27,28]. However, deserialization is
an expensive process that involves the conversion of SOAPs
XML messages to the application object [14,27,29]. Due
to the relatively high memory requirements experienced in
DDS, checkpointing was introduced [28]. Moreover, [29]
introduced Differential Checkpointing (DCP). DCP optimized DDS by improving its speed and reducing memory
requirements. DDS is somehow similar to Differential Serialization (DS). DDS and DS take advantage of a sequence of
similar messages.

3 Developed architecture and implementation

This research came up with an aggregation of the following techniques: client side caching, documentliteral WSDL
description, simple database queries on the server side and
Gzip compression technique. We adopted and modified the

SOCA

Fig. 1 Aggregated architecture for SOAP performance optimization. It entails entailed client side caching, simple server side database queries,
compression technique and documentliteral style description of WSDL

architecture proposed by [9] in aggregating these techniques.

Figure 1 shows the aggregated SOAP performance optimization architecture.
The aggregated architecture shown in Fig. 1 was realized in a software prototype. The software prototype had
three major components: client side component, server side
component and the database component. The client side
was developed in Ext. Js. (JavaScript library) embedded
in an Active Server Pages (ASP.NET) Web page. Server
side was implemented using ASP.NET.asmx Web service.
C# was the back-end programming language for both client
side and server side programming. ASP.NET Web services
were compressed and uncompressed, i.e., introducing and
not introducing Gzip compression algorithm. The database
component was built on MySQL server.
We set up an experiment where we manipulated the file
size of the responses from the Web server as we set constant other experiment environment conditions. The file size
(SOAP-based XML message) from the server contained pure
textual data. The experiment environments were as follows:
Windows Server Operating System installed in the server
computer and Windows XP installed on three client computers. Network bandwidth was set to 10 Mbps to simulate
a disadvantaged network. All computers had 1GB Random Access Memory (RAM) and 3.2GHz processor speed.
Client and server computers were interconnected with a
switch. Microsoft Internet Explorer was used as the default
browser. Fiddler Web Debugger [30] was used in profiling
the client, thus collecting actual performance statistics in the

network. NetBalance Software was used to limit bandwidth

to 10 Mbps. Figure 2 shows clientserver communication.

4 Experimental results and discussion

Experimental results and discussions are categorized as:
compression percentage ratio, time to transfer SOAP messages, time to process SOAP messages, Round Trip Time
(RTT) and throughput.
4.1 Compression ratio percentage
Figure 3 shows a line graph illustrating change in compression ratio percentage against file sizes of SOAP response. The
SOAP messages contained text data. The general trend of this
graph shows the line sloping to the right. This indicates that
smaller file sizes exhibit better compression ratios than large
file sizes after being compressed with Gzip algorithm. Note
that 100 % compression ratio means perfect compression,
while 0 % compression means total compression failure. The
average compression ratio percentage observed was 67.01 %.
SOAP-based XML message data structure is verbose, i.e.,
they have redundant textual characteristics and uses tags to
delimit data [6,8,9]. Lossless compression algorithms, e.g.,
Gzip, maximizes statistical redundancy to represent data in
a compressed format [19].
Nevertheless, large files have more redundant textual characters and uses more tags to delimit data [30]. Therefore,

123

SOCA

Fig. 2 Clientserver communication. This show how SOAP request

is composed on client side and then sent to the server via the communication channel. The server processes the SOAP request, composes

Fig. 3 Change in compression ratio percentage against file sizes of

SOAP response

Gzip compression algorithm collected more statistical information for large file sizes which made the large file sizes
portray larger percentage compression ratio percentages as
compared to smaller file sizes [31].

a SOAP response then forwards it client computer which receives it,

decompresses it and renders it to the Web browser

Fig. 4 Change in transfer time against file size of compressed and

uncompressed SOAP requests

to be transferred in a communication channel. This can theoretically be derived from the bandwidth equation (4.1)
Bandwidth (mbps) = megabytes/seconds

(4.1)

4.2 Time to transfer SOAP messages

4.3 Time to process SOAP messages
Figure 4 represents a graph depicting change in transfer time
against file size of compressed and uncompressed SOAP
requests. The trend of the graph in Fig. 4 shows that both
compressed and uncompressed lines rise steadily indicating
that smaller file sizes portray smaller transfer time than larger
files. The line representing compressed runs below uncompressed. This indicates that uncompressed take much longer
time to transfer files compared to compressed files. Gzip compression reduced the size of a file being transferred by an
average compression percentage ratio of 67.01 %. Large file
size exhibits a large transfer time compared to smaller files
because smaller files have fewer bytes which take lesser time

123

Figure 5 illustrates a line graph representing change in time

to process a SOAP request against change in file size of
compressed and uncompressed. Processing time is the time
difference from when the server got the request to the time the
server begun to compose the SOAP response [30]. It majorly
entails the time to run the SQL query and time involved in
compressing the SOAP message.
The graph shows the line representing change in compressed and uncompressed rising moderately. This points out
that an increase in the file size results in an increase in the
time to process a SOAP request for both compressed and

SOCA

Fig. 5 Change in time to process SOAP request against change in file

size of ASP.NET compressed and ASP.NET uncompressed

uncompressed. Nevertheless, uncompressed line runs below

compressed. This depicts that compressed takes more time
to process SOAP requests compared to uncompressed. This
could be attributed to the fact that compression has tradeoffs, e.g., Extra Central Processing Unit (CPU) processing
time on the server side.

Fig. 6 Change in round trip time against file sizes of ASP.NET compressed and uncompressed requests

4.4 Round trip time

Figure 6 demonstrates a graph describing change in round
trip time against file sizes of compressed and uncompressed.
The general trend of the graph shows that all the lines
rise steadily. This indicates that large files exhibit more
RTT compared to smaller files. Moreover, the line representing compressed runs higher than that of uncompressed,
indicating that compressed files recorded higher RTT than
uncompressed. Equation (4.2) was used to calculate RTT. It
shows that transfer time that was discussed in Sect. 4.2 and
processing time that was discussed in Sect. 4.3 contributed
to the overall RTT. RTT is the turnaround time of the SOAP
message.
RTT = Transfer Time + Processing time

(4.2)

4.5 Throughput
Figure 7 illustrates a line graph outlining change in throughput against change in file size of compressed and uncompressed. The general trend of the graph shows that all the
lines representing compressed and uncompressed slope to
the right. This indicates that smaller file sizes exhibit better
throughput values compared to larger file sizes. Nevertheless,
from the graph, compressed rides slightly below uncompressed. This shows that uncompressed exhibit a better
throughput value than compressed. Throughput was calculated using Eq. 4.3. This measured the number of requests

Fig. 7 Change in throughput against change in file size of compressed

and uncompressed

processed by the Web server per second. Throughput is

highly affected by the round trip time. As we discussed
RTT in Sect. 4.4, we saw that compressed recorded lower
RTT compared to uncompressed resulting in uncompressed
exhibiting better throughput values than compressed. The
slope becomes significantly smaller when the file size is
greater than 2367KB for both ASP.NET compressed and
ASP.NET uncompressed. This is because the change in
throughput against time depreciates when the file size
increases in size.
Throughput = Request RTT

(4.3)

5 Conclusion and future work

In this paper, we developed an aggregate architecture that
entailed: client side caching, simple server side database

123

SOCA

queries, compression technique and documentliteral style

description of WSDL. From our experimental results, we
recorded an improved compression ratio, which was significant for better bandwidth utilization and SOAP transfer time.
This resulted in improved speeds, while SOAP messages are
in transit in the communication channel. However, a relatively high turnaround time and low network throughput
was recorded. Notwithstanding, this research recommends
the aggregated architecture for disadvantaged networks that
have bandwidth speed of <10 Mbps.
Furthermore, we found that processing SOAP request
on the server side took longer when the SOAP messages
are compressed. This was a trade-off between compression
and extra CPU processing time. However, deploying servers
with high processing power can considerably mitigate this
trade-off [7,21]. Further work should come up with a better
compression algorithm that: has the best compression ratio
percentage, utilizes minimal CPU resource (e.g., Time) and
is interoperable among clients (e.g., Web browsers). In addition, better ways of XML parsing and processing can improve
the high computational burden experienced that leads to high
latency.

References
1. Phil B, Kotermanski R, Paulo M (2007) Evaluating a serviceoriented architecture. Carnegie Mellon University, Hanscom
2. IONA Technologies (2005) CORBA programmers guide, Java, vol
6.3. Sun Microsystems
3. Grosso William (2001) Java RMI. OReilly, Sebastopol
4. Microsoft. COM (Component Object Model Technologies). http://
www.microsoft.com/com/default.mspx. Cited Aug 23 2013
5. David B, Haas H, McCabe F, Newcomer E, Champion M, Ferris
C, Orchard D, Web Services Architecture. W3C. http://www.w3.
org/TR/ws-arch/#whatis. Cited Aug 13 2013
6. George C, Dollimore J, Tim K (2009) Distributed systems concepts
and design, vol IV. Pearson Education Limited, Essex, p 789
7. Mutange K, Okeyo G, Cheruiyot W, Sati A, Kalunda J (2014) A
review of SOAP performance optimization techniques to improve
communication in web services in loosely coupled systems. IJCSI
Int J Comput Sci Issues. Mauritius, vol XI. ISBN 1694-0814
8. Joe T, Damiani E, Chbeir R, Gianini G (2011) Similarity-based
SOAP processing performance and enhancement. IEEE 5:387403
9. Hasan S, Zareh R (2011) A combination approach for improvement
web service performance. International association of engineers.
In: Proceeding of the international multiconference of engineers
and computer scientists 2011, vol I, Hong Kong
10. Mouli C, Rajendra C (2012) Caching and SOAP compression techniques in service oriented architecture. Int JAdv Res Comput Eng
Technol, vol I. ISSN: 22781323
11. Schapranow M, Krueger J, Borovskiy V, Zeier A, Plattner H (2009)
Data loading & caching strategies in service-oriented enterprise
applications. Congress on services, 978-0-7695-3708-5/09

123

12. Al-Shammary D, Khalil I (2010) SOAP web services compression

using variable and fixed length coding. In: Ninth IEEE international
symposium on network computing and applications, Cambridge,
pp 8491
13. Abu-Ghazaleh N, Lewis M, Govindaraju M (2004) Differential
serialization for optimized SOAP performance. In: International
symposium on high performance distributed computing (HPDC),
New York, pp 5564
14. Minaei B, Saadat P (2009) SOAP serialization performance
enhancement design and implementation of a middleware. IJCSIS
Int J Comput Sci Inf Secur 6(1):106110
15. AbuGhazaleh N, Lewis M (2005) Differential deserialization for
optimized soap performance. In: ACM/IEEE conference on supercomputing. Binghamton, pp 112
16. IBM. Web services performance best practice. http://www14.
software.ibm.com/webapp/wsbroker/redirect?version=compass&
product=was-express-dist&topic=rwbs_perfbestpractices. Cited
Aug 06 2013
17. Tere G, Mudholkar R, Jadhav B (2013) JAX-WS web service for
transferring images. Int J Comput Sci Eng (IJCSE) 5(3):196204
18. Ng A, Greenfield P, Chen S (2008) A study of the impact of compression and binary encoding on SOAP performance, pp 4656
19. Podlasek T, Sliwa J, Amanowicz M (2010) Efficiency of compression techniques in SOAP, pp 199211
20. Liquid Technologies. Product: Liquid XML Compression
Library. http://www.liquid-technologies.com/Liquid-Products/
XMLCompression/XMLCompressionExample.aspx. Cited Aug
13 2013
21. Ivanovski I, Gramatikov S, Trajanov D (2008) Enhancing performance of web services in mobile applications by SOAP In:
Telekomunikacioni forum telfor 2008, Belgrade
22. Wichaiwong T, Koonsanit K, Jaruskulchai C (2008) A simple
approach to optimized text compressions performance. In: 4th
international conference on next generation web services practices
23. Devaram K, Andresen D (2003) SOAP optimization via client-side
caching. Citeseer, Manhattan
24. Zhai-Wei H, Hai-Xia Z, Guo-Hong G (2010) A study on web services performance. In: Third international symposium on electronic
commerce and security workshops, ISBN: 978-952-5726-11-4
25. Sencha. Custom Grid Filters Example (local filtering). www.
sencha.com. Cited Dec 27 2013
26. Tatemura J, Po O, Sawires A, Agrawal D, Candan KS (2005)
WReX: a scalable middleware architecture to enable XML caching
for web-services. In: Alonso G (ed) Middleware 2005. Proceedings
of the ACM/IFIP/USENIX 6th international middleware conference, Grenoble, November 282 December 2005. Lecture notes in
computer science, vol 3790. Springer, Heidelberg, pp 124143
27. Takase T, Tatsubori M (2005) Optimizing web services performance by differential deserialization. Suzumura. In: IEEE international conference on web services. NY, pp 185192
28. Abu-Ghazaleh N, Lewis M (2005) Differential checkpointing for
reducing memory requirements in optimized SOAP deserialization.
In: Grid computing workshop, IEEE, 0-7803-9493-3/05
29. Abu-Ghazaleh N, Lewis M (2006) Lightweight checkpointing for
faster SOAP deserialization. In: International conference on web
services, New York, 0-7695-2669-1/06
30. Terelik. HTTP/HTTPS traffic recording. http://fiddler2.com/
features. Cited Nov 21 2013
31. Mark N, Jean-loup G (1995) The data compression book, 2nd edn