Analysis and Testing of Ajax-based Single-page Web Applications

out any explicit request from the client. High level of data coherence and
improved network performance compared to the traditional pull style on the
web are the main positive properties of this variant. High server load and
scalability issues are mainly due to the fact that the server has to maintain
state information about the clients and the corresponding connections.
For the sake of comparison, the last entry in Table 2.3 presents the component
and push-based Spiar style itself.
2.8.3 Issues with push Ajax
Scalability is the main issue in a push model with a traditional server model.
Comet uses persistent connections, so a TCP connection between the server
and the client is kept alive until an explicit disconnect, timeout or network
error. So the server has to cope with many connections if the event occurs
infrequently, since it needs to have one or more threads for every client. This
will bring problems on scaling to thousands of simultaneous users. There is a
need for better event-based tools on the server. According to our latest findings
(Bozdag et al., 2009), push can handle a higher number of clients if new
techniques, such as the continuations (Jetty, 2006) mechanism, are adopted
by server applications. However, when the number of users increases, the
reliability in receiving messages decreases.
The results of our empirical study (Bozdag et al., 2009) show that push
provides high data coherence and high network performance, but at the same
time a Comet server application consumes more CPU cycles as in pull.
A stateful server is more resistant to failures, because the server can save
the state at any given time and recreate it when a client comes back. A push
model, however, due to its list of subscribers is less resilient to failures. The
server has to keep the state, so when the state changes, it will broadcast the
necessary updates. The amount of state that needs to be maintained can be
large, especially for popular data items (Bhide et al., 2002). This extra cost of
maintaining a state and a list of subscribers will also have a negative effect on
scalability.
These scalability issues are also inherited by Spiar as can be seen in Table
2.3.
2.8.4 Resource-based versus Component-based
The architecture of the World Wide Web (W3C Technical Architecture Group,
2004) is based on resources identified by Uniform Resource Identifiers (URI),
and on the protocols that support the interaction between agents and resources.
Using a generic interface and providing identification that is common
across the Web for resources has been one of the key success factors of
the Web.
The nature of Web architecture which deals with Web pages as resources
causes redundant data transfers (Bouras and Konidaris, 2005). The deltacommunication
way of interaction in Spiar is based on the component level
48 2.8. Discussion and Evaluation