- Email: [email protected]
Robust design to optimize client–server bi-directional communication for structural analysis web applications or services
ARTICLE IN PRESS
JID: ADES
[m5G;May 10, 2017;8:31]
Advances in Engineering Software 0 0 0 (2017) 1–11
Contents lists available at ScienceDirect
Advances in Engineering Software journal homepage: www.elsevier.com/locate/advengsoft
Robust design to optimize client–server bi-directional communication for structural analysis web applications or services J. Calvo a,∗, J. Gracia b, E. Bayo a a b
Department of Building Construction, Services and Structures, University of Navarra, Pamplona, Navarra 31009, Spain Department of Construction and Manufacturing Engineering, University of Oviedo, Oviedo, Asturias 33003, Spain
a r t i c l e
i n f o
Article history: Received 20 January 2017 Revised 17 April 2017 Accepted 30 April 2017 Available online xxx Keywords: Cloud computing Web application Bi-directional communication Engineering structures Factorial design Robust design
a b s t r a c t Current trends in web application development favours bi-directional communication between front-end and back-end applications instead of the traditional ones where the front-end is constantly monitoring the back-end. This way of communication improves the user experience and this work tries to find the best bi-directional way of communication particularized to structural analysis software as a service or web applications. The effects of the most significant factors have been studied to optimize the total time involved in the communication, which is comprised of: time spent sending data from the client to the server, server data processing, and time consumed returning the data back. Design of experiments (DoE) techniques have been used to characterize the influence of four factors: serialization language, communication protocol, amount of data (size of the structure measured by the number of elements), and server post-processing. Moreover, factors like server workload and network congestion have also been addressed. The first factor is dealt with as a nuisance factor whose influence is to be minimized, and the second one as an uncontrollable variable. © 2017 Elsevier Ltd. All rights reserved.
1. Introduction The software market trend is evolving towards software as a service for consuming products (SaaS) over the Internet. The number of companies following this trend is constantly increasing. Office 365, AutoCad 360 or file storing services like Dropbox, OneDrive or Google Drive, have become successful examples. The SaaS distribution system has many benefits over traditional ones, as explained by Calvo et al. [1], by Subashini and Kavitha [2], and by Miller [3]: high availability through any device connected to Internet, real time software updates and pay-per-use business model. Previous works done by Gracia and Bayo [4], Nuggehally et al. [5], Peng and Law [6], Chen et al. [7,8], Yang et al. [9], and Mackie [10], show that structural analysis software can be provided as a SaaS. SaaS is similar to traditional client–server applications where each one is responsible for some particular task, therefore optimal communication is crucial for the service to succeed. Moreover, client requirements are beyond one-way communications systems. Current services require that the client will receive data and notifications not only when it is requested but also when the server produces them. Facebook and Twitter are examples of services that
∗
Corresponding author. E-mail addresses: [email protected] (J. Calvo), [email protected] (J. Gracia), [email protected] (E. Bayo).
make use of bidirectional communication to keep the client up-todate. They use traditional techniques like Long-Polling or new ones like WebSocket, that is, socket over HTTP protocol. Nowadays, it is relatively fast for a computer to solve a structural system with thousands of degrees of freedom. This has benefited structural engineers who can develop more complex structural models. However, if we want to move structural analysis software to the internet environment we will have to deal with large amounts of data that need to be sent across Internet. The time data takes to travel from the client to the server, and vice versa, will strongly influence the user experience. Consequently, several decisions have to be made: what processes will be performed in the client and which ones in the server; what type of communications protocol; and what data serialization format, among others. This paper is aimed at providing enough information to choose the best communication technology for structural analysis applications on the Internet environment. This paper identifies the factors that affect communication time and the technology (or combination of technologies) that is best suited to exchange structural data for Structural Analysis Software as a Service. In this respect, Gracia and Bayo [11] performed previous research focused on conventional client–server communication technology. In order to simulate user experience, the communication time is measured from client data serialization until data is returned
http://dx.doi.org/10.1016/j.advengsoft.2017.04.010 0965-9978/© 2017 Elsevier Ltd. All rights reserved.
Please cite this article as: J. Calvo et al., Robust design to optimize client–server bi-directional communication for structural analysis web applications or services, Advances in Engineering Software (2017), http://dx.doi.org/10.1016/j.advengsoft.2017.04.010
JID: ADES 2
ARTICLE IN PRESS
[m5G;May 10, 2017;8:31]
J. Calvo et al. / Advances in Engineering Software 000 (2017) 1–11
back from the server. Specifically, the client application stores the data of the structure (nodes, elements, material properties, etc.) as a JavaScript object that needs to be serialized before is sent to the server. Once the data is received, the server relocates the nodes and the elements, and calculates the total weight of the structure (thus considering the server arithmetic operations). Finally, it will serialize the modified structure and send it back to the client, which will parse the data again as a JavaScript object. The client has been implemented following HTML5 standards: JavaScript, CSS and HTML, while the server has been developed with PHP, a wellknown server-side programming language designed for web applications. This DoE is mainly focused on four primary factors: serialization language, communication protocol, size of the structure and server post-processing. Server workload (noise) and network congestion are also considered but as nuisance factors. Factors like the web browser and the web server are not relevant for this study and have been considered as constant factors. To identify parameter interactions a full factorial design is chosen. Finally, robust parameter design (RPD) techniques are applied to minimize the influence of the noise factor. Different models of DoE techniques are summarized by Tanco el al. [12]. In the following sections, the factors analysed in the experimental program are identified. Then, the application developed to measure response times is introduced. Finally, and after following DoE methodology, an analysis of the results is presented. 2. Experimental program This section describes the experimental program that has been developed to identify the best bi-directional communication setup for web services (or web applications) specialized in the analysis and design of structures. As mentioned before, several tools and protocols are studied by means of a DoE. One of the main difficulties of this experimental program is to deal with uncontrollable factors. As stated before, in order to develop structural analysis software on Internet several software architectural decisions have to be made. One of these is which processes are implement on the client side (front-end) and which ones on the server side (backend). If heavy processes are implemented at the server side the computer hosting the server should be able to handle large amount of simultaneous user requests and also to resolve each request as quickly as possible, so that the user experience is not compromised. The main advantage of this architecture is that users do not need high performance computers, since heavy processes are executed at the server. Conversely, if these processes are executed at the client side, the response will be fastest and the server workload will decrease accordingly. User experience will be improved and cheaper servers would be enough to host the web application. However, the main disadvantage is that the code is accessible by users, in some sense it becomes public. One option is to obfuscate the JavaScript code but it will continue to be accessible. In this research, the first option is adopted and therefore heavy processes are implemented at the server side along with client and server exchanging all the information relative to the structural models. In this way, communication times will be measured to find which technology performs better. 2.1. Objective and variables Experimental software has been developed to automatize the measurements and the testing needed to identify the influence of the factors mentioned above. This software allows the selection of a combination of levels for each primary factor and to simu-
late client–server communications. It also simulates the workload at the server side. The total time consumed in a full communication cycle is selected as the response measurement for each experiment. Time becomes critical when identifying the efficiency of each factor and when assessing the user experience. The time is measured in milliseconds and the main target of the DoE is to identify the factors that minimize it. The experiment factors can be classified into three types: primary, constant and nuisance. The former ones are factors whose influence is unknown and are selected as the main target of the experimental program. Constant factors can also affect the experiments but they are not selected as targets of the research. Nuisance factors are not interesting for the research; they are uncontrollable and can modify measurements unexpectedly. Nuisance factors that can be controlled in the experimental setup are referred to as noise factors. Four primary factors have been identified in this experimental program: serialization language, communication protocol between client and server, data size of the engineering structure and server data processing. The main constant factors that will not be studied are: web browser (it has an influence but does not determine the best primary factors for optimal bi-directional communication), server programing language, and web server application. Finally, there are two factors that affect the time measures but are uncontrollable: network congestion during experiments and server workload. The last one will be treated as a noise factor. Hereafter a thorough explanation of each primary factor that has been studied will be described. 2.1.1. Serialization language Each application defines its own data model as arrays, objects, databases or any other data structure. However, in order to communicate with other applications, this data model has to be serialized. This process translates data into a format that can be stored or transmitted across the network so that it can be reconstructed in the same or another computer (the server in this case). The main drawback is that data is commonly translated into ASCII strings. The ASCII representation of numeric values is larger than the binary representation. However, serialized data is standard while binary data has to be transformed depending on whether the destination machine is low endian or big endian. The most widely supported languages in SaaS are XML (eXtensible Markup Language) and JSON (JavaScript Object Notation). Wang [13] provided an interesting comparison between these two languages. In this research, a less popular serialization language named YAML (recursive acronym for “YAML Ain’t Another Markup Language”) has been also studied. Fig. 1 shows a small example of the syntax of these three languages. XML is the most widely supported. It was design as a simple, very flexible, text formatting language. It is playing an increasingly important role in the exchange of a wide variety of data on the Web and elsewhere. There are a variety of APIs to access XML data; some of them have been standardized. Nonetheless, XML support has been implemented in different ways on each browser and as a consequence performance is not constant among them. It is extremely compelling, compared to JSON and YAML, when dealing with complex data structures. However, its heavy use of mark-up tags tends to transform data structures into large strings, increasing the amount of information to be transferred. Meanwhile, JSON is gaining adepts in web development environments, and it has a huge support in most browsers. Its syntax is similar to JavaScript, key/value pair notation is the mechanism to store and read data. Data serialised in JSON is lighter than in XML: it represents the same amount of data with less characters. Front-end web developers used it to speed up the development of
Please cite this article as: J. Calvo et al., Robust design to optimize client–server bi-directional communication for structural analysis web applications or services, Advances in Engineering Software (2017), http://dx.doi.org/10.1016/j.advengsoft.2017.04.010
JID: ADES
ARTICLE IN PRESS
[m5G;May 10, 2017;8:31]
J. Calvo et al. / Advances in Engineering Software 000 (2017) 1–11
3
Fig. 2. Differences in communication protocols.
Fig. 3. 19 elements structural system.
Fig. 1. Comparison of the structure of XML, JSON and YAML.
client–server communication in order to design rich and dynamic web pages. One of its main drawbacks is the possible improper use of the JavaScript ‘eval()’ function which may cause security issues. Finally, YAML is a human-readable data serialization language. It is also much more compact than XML, because break lines and white spaces are used instead of explicit mark-ups or brackets. Nevertheless, it is a less common language and it is not well supported by web browsers, as a consequence external libraries are required most of the time. Its main feature is that serialized data becomes more legible and readable. 2.1.2. Communication protocol A communication protocol is defined as a system of rules that allow two or more entities of a communication system to transmit information. Communication protocols are implemented in hardware and software but we will only focus on software. As mention before, the aim of this research is to improve asynchronous bi-directional client–server web application communication so that we can update client and server contents simultaneously. Currently there are several technologies, which are not explicitly protocols, but we will treat them as if they were. They define the same parameters as protocols: syntax, semantics and synchronization of communication. As an example, AJAX (Asynchronous JavaScript and XML) use HTTP as its main protocol defining additional rules for requesting data. At the other end, we have technologies such as WebSocket that use TCP/IP socket layer over HTTP port. Hereafter, the most commonly known technologies will be presented. However, the experimental setup will only include the most relevant ones. AJAX technology is widely supported by most web browsers. It is based on open standards like JavaScript, DOM (Document Object Model) and XMLHttpRequest object (W3C 2014) [14]. With AJAX, web browsers can send data to and retrieve from a server asynchronously (in the background) without interfering with the display and behaviour of the existing page. Long-Polling is a variation of the traditional polling technique. The client requests information from the server trough an AJAX request. Then, the server keeps the communication channel open until it has information available for the client. Once the client receives the data, a new request is generated so the communication channel is always open. Most web browsers also support this method. Server-sent events (SSE) is a new technology part of HTML 5 standard (W3C 2015) [15]. In this case, the web browser receives automatic updates from the server through the HTTP connection. Its main feature is that only the server can send data. If data transmission from the client is required, it has to be implemented
Fig. 4. 480 elements structural system.
by means of another mechanism. This technology is easy to implement and most web browsers, excluding Internet Explorer, support it. Finally, WebSocket is a protocol that provides full-duplex bidirectional communication over a TCP socket (W3C 2012) [16]. After the connection is established, the client and the server can send data back and forth at any time. It supports multiplexing over the same connection and is not blocked by firewall policy rules (HTTP port is usually open), unlike network sockets that are usually blocked by network infrastructure managers. Once the HTTP protocol handshake is finished, communication efficiency is similar to native network sockets. WebSocket is best suited for applications where data exchange is frequent or happens in real time. However, implementation at the server side is usually more complex depending on the programing language. Fig. 2 shows a flow chart for each communication technique. Long-Polling is similar to AJAX. The main difference is the communication trigger. With AJAX, clients start the request-response loop while with Long-Polling the server becomes the trigger of the loop. In this research, the server response always comes after the client request; consequently, AJAX is preferred over Long-Polling. For the same reason, SSE will not be considered. Server-sent event is focused on real-time communication in one-way only, server to client, similar to a publish-subscribe service. Therefore, this research includes AJAX and WebSocket as levels for the communication protocol. 2.1.3. Structure data size This research is focused on structural analysis web applications and/or services. The data to be transmitted is composed of all the information that completely defines a 3D structural system of frames. In this experiment the structure is composed of three different objects: nodes, elements and cross sections. The node objects include three-dimensional coordinates, the applied loads, and the restrain information about each degree of freedom. Then, element objects contain a node reference for each node of the element (two in this case), a reference to a cross section, and definition of the type of connection at each node, simple or rigid. Finally, the cross sections are defined by means of material properties: elastic modulus and density; and main properties of the section: areas and moment of inertias. Figs. 3 and 4 show two topologies used in the experimentation with 19 and 480 elements, respectively.
Please cite this article as: J. Calvo et al., Robust design to optimize client–server bi-directional communication for structural analysis web applications or services, Advances in Engineering Software (2017), http://dx.doi.org/10.1016/j.advengsoft.2017.04.010
JID: ADES 4
ARTICLE IN PRESS
[m5G;May 10, 2017;8:31]
J. Calvo et al. / Advances in Engineering Software 000 (2017) 1–11
The size of the structure is a relevant factor; larger structures will lead to larger serialized strings that will require more time to be transmitted. In addition, the server will take more time to process it and serialization/deserialization time will also increase accordingly. In this study, the number of elements is the variable chosen to characterize the size of the structure. 2.1.4. Server processing The main task of structural analysis software is to compute displacements and internal forces. In this case, the research is focused on communication not on computing efficiency. However, a solver to obtain displacements from known loads has been implemented in the server. Additionally, the weight of the structure is calculated and sent to the client together with the nodal displacements. Server processing is not equal for every user: it depends on the size of the problem to be solved and on the type of analysis to be performed. The size of the structure is chosen as one of the primary factors to be analysed. To account for different types of server workload a factor named “server processing” is included. This factor defines how many times the structure will be solved at the server. In this way, a non-linear analysis setting can be tested. It is important to note that the main target of the experimentation is not the values that are measured but how each factor affects data communication. 2.1.5. Server workload (noise factor) The server workload when an experiment is conducted is another factor that may have an impact on the results. This workload is due to multiple circumstances such as operating system processes or user applications executing in the background. This workload is not constant, therefore its influence on the experiment is not uniform. Nonetheless, its influence is not interesting for this research and can be controlled during the experiment. The server workload is controlled allowing two levels of intensity, light and heavy CPU workload. The former is guaranteed by disabling all non-critical system services after a fresh start-up of the machine. The server workload has been always below 5% and close to 2%. For heavy workload, the program Intel Burn Text 2 has been used to raise the CPU utilization to 100%. 2.1.6. Network congestion (nuisance factor) Lastly, network congestion is another factor that affects communication. Any subtle variation of the network traffic will generate delays of data packets transmitted between client and server. Local land network congestion can be easily controlled, however controlling it over an Internet connection is not possible. 2.2. Design of experiments Experimentation is necessary to study the behaviour and relation between two or more distinct variables. Traditional experimentation is focused on studying variables one by one. It means one variable is modified while the rest are kept fixed. This methodology requires a huge amount of experimentation and all possible combinations have to be tested. Sometimes this is not possible due to time or budget limits. Moreover, it has another important drawback: interaction between factors is harder to identify. For this research, a Design of Experiments (DoE) methodology has been chosen. With DoE, interaction between factors can be easily identified and the influence of nuisance factors can also be reduced, as explained in Montgomery (2005) [17]. To minimize variability caused by server workload (noise factor), a robust design method has been preferred (Pozueta and TortMartorell, 2007) [18]. First, an initial set of tests is performed to identify which levels of the primary factors reduce the server workload impact. Then, a second round of tests are conducted. In
Fig. 5. Displacements of a 480 elements structural system.
this round, levels identified are used to perform a factorial design where the server workload factor is set at fixed values. Conversely, noise factor, the network congestion, cannot be controlled during the experimentation. Its influence has been minimized by executing all the runs of the experiment randomly. In this study, the experimentation has been carried out with software developed for this purpose. This software can easily test any number of combinations of factors. Because of this, full factorial design will be performed and it will be done twice to allow a better identification of the variability sources. 3. Experimental prototype Client–server software to automatize the experimentation and response time are described below. 3.1. Client–server software The software developed is composed of one client application, two server applications and a structural analysis solver library. The first one is a web application developed in JavaScript and HTML. Both servers are developed with PHP. One of them is hosted on an Apache Web Server to dispatch AJAX requests and the other is developed as a standalone server to dispatch WebSocket requests. Finally, a solver has been developed as a C++ command application. Both servers call the solver. Fig. 5 shows the displaced structure of Fig. 4 rendered from the calculated displacements by the server and returned to the client. The web application provides a user-friendly interface to select values for each factor and to run the combination. It implements subroutines to serialize/deserialize data for each language and to transmit data trough AJAX or WebSocket calls (see Fig. 6). At the client side, functions to code and decode JSON objects are provided by JavaScript. However, XML and YAML format are not natively supported by Javascript so two third party libraries have been used (see Fig. 7). Server communication at the client has been implemented with jQuery for AJAX requests and standard HTML5 API calls for WebSocket requests (see Fig. 8). On the other hand, both server applications share a common core (see Figs. 10 and 13). They implement subroutines to serialize/deserialize and process data. In this case, PHP core has native support for JSON and XML data. However, YAML format has been handled by means of a third party library (see Fig. 9). The AJAX server version has been developed using standard PHP functions to dispatch requests (Fig. 11). The WebSocket version uses the Ratchet library, which provides tools to create WebSocket communications (Fig. 12). Ratchet uses the React library to implement event-loop mechanisms that keep the application listening all the time. The full stack works as follows. Firstly, both services are started at the server. Then, the client initializes both connections and keeps them ready on memory. Two JavaScript objects are created for this purpose. They contain all the methods and events necessary to communicate with both servers. This operation is important so that the initial setup will not affect the tests.
Please cite this article as: J. Calvo et al., Robust design to optimize client–server bi-directional communication for structural analysis web applications or services, Advances in Engineering Software (2017), http://dx.doi.org/10.1016/j.advengsoft.2017.04.010
JID: ADES
ARTICLE IN PRESS
[m5G;May 10, 2017;8:31]
J. Calvo et al. / Advances in Engineering Software 000 (2017) 1–11
Fig. 9. Serialization/deserialization server subroutines.
Fig. 6. Capture of the client application.
Fig. 7. Serialization/deserialization client subroutines.
Fig. 8. Client communication subroutines.
Fig. 10. Overall view of process involved.
Please cite this article as: J. Calvo et al., Robust design to optimize client–server bi-directional communication for structural analysis web applications or services, Advances in Engineering Software (2017), http://dx.doi.org/10.1016/j.advengsoft.2017.04.010
5
ARTICLE IN PRESS
JID: ADES 6
[m5G;May 10, 2017;8:31]
J. Calvo et al. / Advances in Engineering Software 000 (2017) 1–11 Table 1 Levels of factors in the preliminary experimentation. Factors
Levels
Serialization language Communication protocol Structure data size Server processing Server workload (Noise)
A B C D E
JSON AJAX 64 1 Heavy
XML WebSocket 800 20 Light
YAML
Fig. 11. Server AJAX communication subroutine. Table 2 Factors and codes. Factors Serialization language Communication protocol Structure data size Server processing Server workload (Noise)
Fig. 12. Server WebSocket communication subroutine.
As mentioned before, the other task performed by servers is data processing. The received data is deserialized into PHP objects so they can be processed. Two operations are performed with the data: structural analysis and weight analysis. The weight is calculated by the same PHP process that receives the data, while the structural analysis is carried out through a call to an external C++ command solver executed by means of PHP “exec” function (see Fig. 13). 3.2. Response time The total response time of each conducted test will include several measures: data serialization/deserialization (at the client and at the server), transmission time and processing time at the server. This value can be measured in several ways. However, most of the time the response time is very small (milliseconds) and the clock time coincidence of each machine cannot be guaranteed at this level of precision. The best way to measure is to use the difference between the time measured before the client serializes the data and the time measured once the client deserializes the server response. Both values will be measured at the client side. Nonetheless, for the purpose of collecting as much information as possible from each experiment, the software stores the time spent for each sub-process. Sub-process time at the server side is evaluated in the same way and each value is concatenated into a string that is appended to the response data. The only value that is not directly measured is the transmission time. However, it can be easily assessed from the other measures. Although this information is not quite relevant for DoE, it is useful for a general overview of all the sub-processes involved in a test. Besides, the impact of performing these measurements as well as transmitting them attached to the response data is almost negligible for the experiment. Fig. 14 shows a chart with all the measured sub-process that affect the response time. 3.3. Testing environment Experimental tests have been performed with two types of computers: one for the client application, a personal computer run locally; and another for the server, a virtual private server (VPS) hosted in Amazon Web Services (AWS). VPS is a t2.micro EC2 instance type. This is a virtual server equivalent to a physical computer with one Intel Xeon (E5-2676)
Description A B C D E
Serialization language used Client–server communication protocol Structure size (number of frames) Server editing operations (loops) Server load (stress CPU program)
CPU core (up to 2,4 Ghz) and 1GB of RAM. VPS runs a Windows Server 2012 (x64 version) operation system. Apache 2.4.9 with php_mod enabled (version 5.5.12) was used as web server. Both technologies were installed as 64 bits version. WebSocket server was developed with PHP 5.6 (x86 version) and two specific libraries: Ratchet and React. Client machine hardware specifications are: Intel Core i7 2720Q (up to 3,30 GHz) 4 cores (8 threads) CPU and 8GB DDR3 1600 Mhz dual channel memory. During the test client machine was also running Windows 10 Pro (x64 version) as operating system. Internet Explorer 11 was used as the web browser. The AWS instance is located at one of the data centres that Amazon has deployed in Ireland. The client machine (laptop) is in Spain and is connected to Internet through a high-speed connection. 4. Experimentation results As mentioned above, a robust parametric design is proposed to minimize the noise factor that depends on the server load. For this purpose, a first experimentation is done to assess the levels of the relevant factors involved in the response. Then, taking these levels into account, a full factorial design is performed to obtain the influence of each of the individual factors on the overall response: elapsed total time in milliseconds. However, prior to the proposed selective robust design and acquisition of preliminary data, a full factorial design is performed with all the factor levels. 4.1. Initial experimentation We consider four primary factors: language, protocol, data size and solver process; and we are interested in knowing their influence in the overall response. In addition, we consider two nuisance factors: network congestion and server workload that also intervene and whose influence needs to be minimized. The server workload factor is controllable during the experimentation; however, the Internet network congestion is not controllable. Due to this reason, all the runs that have been performed during this and the following experimentations have been carried out in a random manner, although for the sake of the reader’s convenience the resulting data is presented in table form in an orderly way. Therefore, after eliminating the Internet factor, a full mixed factorial design is performed with five factors. A replica is also added, thus yielding a design of size 3 × 24 x 2. Tables 1 and 2 show the factors and codes used in the experimentation and their respec-
Please cite this article as: J. Calvo et al., Robust design to optimize client–server bi-directional communication for structural analysis web applications or services, Advances in Engineering Software (2017), http://dx.doi.org/10.1016/j.advengsoft.2017.04.010
JID: ADES
ARTICLE IN PRESS
[m5G;May 10, 2017;8:31]
J. Calvo et al. / Advances in Engineering Software 000 (2017) 1–11
Fig. 13. System architecture of experimental prototype.
Fig. 14. Sequence of process involved on each measured response.
Fig. 15. Main effects affecting the response.
Please cite this article as: J. Calvo et al., Robust design to optimize client–server bi-directional communication for structural analysis web applications or services, Advances in Engineering Software (2017), http://dx.doi.org/10.1016/j.advengsoft.2017.04.010
7
ARTICLE IN PRESS
JID: ADES 8
[m5G;May 10, 2017;8:31]
J. Calvo et al. / Advances in Engineering Software 000 (2017) 1–11 Table 4 Levels of factors in the first experimentation.
Table 3 Responses in the preliminary experimentation. Factors
Response
Factors
A
B
C
D
E (Noise)
Results
Replica
JSON JSON JSON JSON JSON JSON JSON JSON JSON JSON JSON JSON JSON JSON JSON JSON XML XML XML XML XML XML XML XML XML XML XML XML XML XML XML XML YAML YAML YAML YAML YAML YAML YAML YAML YAML YAML YAML YAML YAML YAML YAML YAML
AJAX AJAX AJAX AJAX AJAX AJAX AJAX AJAX WebSocket WebSocket WebSocket WebSocket WebSocket WebSocket WebSocket WebSocket AJAX AJAX AJAX AJAX AJAX AJAX AJAX AJAX WebSocket WebSocket WebSocket WebSocket WebSocket WebSocket WebSocket WebSocket AJAX AJAX AJAX AJAX AJAX AJAX AJAX AJAX WebSocket WebSocket WebSocket WebSocket WebSocket WebSocket WebSocket WebSocket
64 64 64 64 800 800 800 800 64 64 64 64 800 800 800 800 64 64 64 64 800 800 800 800 64 64 64 64 800 800 800 800 64 64 64 64 800 800 800 800 64 64 64 64 800 800 800 800
1 1 20 20 1 1 20 20 1 1 20 20 1 1 20 20 1 1 20 20 1 1 20 20 1 1 20 20 1 1 20 20 1 1 20 20 1 1 20 20 1 1 20 20 1 1 20 20
Heavy Light Heavy Light Heavy Light Heavy Light Heavy Light Heavy Light Heavy Light Heavy Light Heavy Light Heavy Light Heavy Light Heavy Light Heavy Light Heavy Light Heavy Light Heavy Light Heavy Light Heavy Light Heavy Light Heavy Light Heavy Light Heavy Light Heavy Light Heavy Light
79 77 91 79 277 269 265 267 141 150 143 143 1648 1058 1709 1141 397 213 419 385 1787 1947 3126 1781 341 347 345 345 4092 3338 4060 3267 1586 967 1636 885 26,804 13,455 26,955 25,628 1606 2255 1570 1080 29,303 14,875 27,488 14,898
77 81 73 76 242 240 306 239 88 91 86 72 327 334 346 338 225 208 224 244 1818 2114 1760 1837 258 254 257 257 1992 1981 2137 2006 281 292 1542 475 6885 3711 8097 5143 385 373 380 389 7761 6111 7749 6224
tive levels. Table 3 depicts all the responses corresponding to the different runs and their replicas. Lastly, Figs. 15 and 16 show the main effects and the interactions between variables after the experimentation analyses. It may be seen that YAML notably increases the response time when compared with the other languages, therefore in the next round of experiments YAML is discarded as serialization language. 4.2. First experimentation The objective of this experimentation is to reduce the influence of the noise factor on the response. Robust design (RPD) is used for this task. Since the YAML effect has already been discarded, there will be two level designs for all the factors (see Table 4). A full factorial design for 4 primary factors is performed for each of the two levels of the noise factor (light and heavy server workload). Finally, the experiment is conducted again (replica) thus conforming a 24 x 2 × 2 design. Table 5 depicts all the responses. The resulting data is analysed considering the variance as the measure of the response. The sig-
Serialization language Communication protocol Structure data size Server processing Server workload (Noise)
Levels A B C D E
JSON AJAX 64 1 Heavy
XML WebSocket 800 20 Light
nificant primary factors are the size (C) and the protocol (B). Thus, considering these significant factors the following regression equation is obtained:
Ln(V ar ) = 8, 796 − 4, 191B + 0, 005019C
(1)
Consequently, in order to reduce the variability, one will have to increase the factor B and decrease the factor C. Notice however, that since the protocol (B) is an attribute, it cannot be modified. B↑, C↓ The next step is to carry out another analysis, but this time taking the average time as the response measure. The following significant factors are considered: the size (C), the language (A) and the protocol (B). The resulting regression equation becomes:
Y = 96, 04 + 6, 105A − 69, 49B + 2, 88C
(2)
Similarly, it is observed that in order to reduce the average time, one will have to decrease A and C, and increase B. The factor A (language) and B (protocol) will remain unchanged. A↓ , B↑ , C↓ Consequently, in order to reduce the influence of the noise factor (server) one will have to consider lower levels for the size factor (C). 4.3. Second experimentation We now proceed with another experimentation in which we will exclude the noise factor. The noise will remain constant, with a low value, during the whole experiment. In view of the results of the previous experimentation, we will decrease the level values of the size factor so that the noise effect will also decrease. As done before, the simulations will be carried out in a random order to minimize other perturbing factors. Consequently, the new factors to be considered are shown in Table 6. The experimentation is comprised of a full factorial design of size 24 with an additional replica, thus resulting in a 24 x 2 design. Table 7 shows the responses while Fig. 17 illustrates the values of the variables (factors) and their interactions after the experimentation analyses. It may be observed that the factors C, A and AC become very significant and also, although to a lower extent, the factor B and the combination BC. The statistical significance level (Alpha) is 0.05 for all the experiments. The main effects and interactions between factors are depicted in Figs. 18 and 19. It may be seen that the factors that have the most influence on the response are the language (A) and the size of the structure (C) and, although to a lower extent, the protocol (B). However, it may also be observed from the graphs that the choice of language in combination with size becomes also important (interaction AC). Finally, the regression equation that relates the different factors and that is obtained after the experiment becomes:
Y = 78 + 11, 8A + 6, 3B + 1, 8235C + 1, 1388AC + 0, 09BC + 0, 4514BC + 2, 5AB + 0, 0844ABC
(3)
5. Analysis and assessment The preliminary experimentation provided an estimation of the influence of each factor. It showed that factors such as language,
Please cite this article as: J. Calvo et al., Robust design to optimize client–server bi-directional communication for structural analysis web applications or services, Advances in Engineering Software (2017), http://dx.doi.org/10.1016/j.advengsoft.2017.04.010
ARTICLE IN PRESS
JID: ADES
[m5G;May 10, 2017;8:31]
J. Calvo et al. / Advances in Engineering Software 000 (2017) 1–11
9
Fig. 16. Interactions among factors. Table 5 Responses, averages and variances. Factors
Results
Response
A
B
C
D
Result (E+)
Replica (E+)
Result (E-)
Replica (E-)
Average
Ln(Var)
JSON JSON JSON JSON JSON JSON JSON JSON XML XML XML XML XML XML XML XML
AJAX AJAX AJAX AJAX WebSocket WebSocket WebSocket WebSocket AJAX AJAX AJAX AJAX WebSocket WebSocket WebSocket WebSocket
64 64 800 800 64 64 800 800 64 64 800 800 64 64 800 800
1 20 1 20 1 20 1 20 1 20 1 20 1 20 1 20
1440 1449 1782 319 156 177 2326 2115 1600 1756 2829 2973 380 428 5458 5516
89 93 370 350 152 182 2257 2152 244 264 3380 2319 375 529 5187 5525
273 211 634 705 184 169 1241 1166 491 498 2600 2677 373 399 3844 3851
79 96 301 306 158 180 1292 1165 231 273 2568 2139 350 452 3989 3883
181 153.5 502 334.5 157 178.5 1774.5 1640.5 367.5 385.5 2714.5 2498 374 440 4588 4699.5
12.96199957 12.98485208 13.06937654 10.50344065 5.35501271 3.48635519 12.769781 12.65258266 12.95425158 13.14108356 11.85706525 11.83796112 5.179909135 8.040661635 13.42200811 13.72288884
Table 6 New levels of factors for the second experimentation. Factors
Levels
Serialization language Communication protocol Structure data size Server processing
A B C D
JSON AJAX 19 1
XML WebSocket 480 20
Table 7 Responses for the second experimentation. Factors
Response
A
B
C
D
Results
Replica
JSON JSON JSON JSON JSON JSON JSON JSON XML XML XML XML XML XML XML XML
AJAX AJAX AJAX AJAX WebSocket WebSocket WebSocket WebSocket AJAX AJAX AJAX AJAX WebSocket WebSocket WebSocket WebSocket
19 19 480 480 19 19 480 480 19 19 480 480 19 19 480 480
1 20 1 20 1 20 1 20 1 20 1 20 1 20 1 20
68 72 223 219 88 88 597 577 128 126 1397 1482 166 170 1862 1924
69 69 220 237 92 93 594 600 127 142 1195 1175 165 174 1841 1923
Fig. 17. Pareto chart for standardized effects.
size and server workload have a significant influence on the response. In addition, it was observed that the interactions among the factor language and the factors data size and workload are very important when using the language YAML. Since the use of YAML increases the total time significantly, it was decided not to include it in the following experiments, and only use XML and JSON. The following experimentation indicated which of the two is the most efficient language. After the preliminary experimentation, a robust parameter design was carried out to minimize the impact of the noise factor
Please cite this article as: J. Calvo et al., Robust design to optimize client–server bi-directional communication for structural analysis web applications or services, Advances in Engineering Software (2017), http://dx.doi.org/10.1016/j.advengsoft.2017.04.010
JID: ADES 10
ARTICLE IN PRESS
[m5G;May 10, 2017;8:31]
J. Calvo et al. / Advances in Engineering Software 000 (2017) 1–11
Fig. 18. Main effects affecting for response.
Fig. 19. Interactions among factors.
generated by the server workload. This robust design consisted in two experimentations; the first one was aimed at selecting the levels of primary factors for which the influence of the noise factor is small; and the second to measure the influence of the factors in the overall response. The experimentations were carried out using a full factorial design. It was found, after the first experimentation, that the levels of the language and size factors should be reduced and the protocol factor should be increased to minimize the influence of the noise factor. However, the language and protocol factors are qualitative variables and their values cannot be increased or reduced. Only the size factor can be modified by changing the number of elements included in the structural model. The primary factors are tested in the second experimentation in which the value of the noise factor remains constant. The results showed the importance of the size and the language factors, and their interaction, in the overall response. Also, the protocol-size interaction was important. In addition, all the independent primary factors (except processing and protocol) have a significant influence in the response. The language factor has a large impact; in fact, the language XML leads to a much larger execution time than JSON. Also the size of the structure becomes important, since, as expected, the larger the structure the longer the simulation is. It is important to mention that the interaction between size and language is very significant: when the language XML is used, the size of the structure slows the response much more than when the language JSON is used. This makes JSON a better candidate for the simulations of large structural systems. Finally, it is important to mention that the experimentation has been performed in the best scenario of each protocol. This means,
in the case of AJAX, that before each test was conducted a previous connection was executed to keep-alive the connection, so initialization time did not become part of the response. AJAX communications are not keep-alive by default while WebSockets are. In a real environment, where calls to the server are not continuous, the time consumed by the AJAX calls will be close to the WebSocket calls, although the former will still be faster. 6. Conclusions It seems clear, from the results shown in this paper that the serial language JSON is the most efficient for client–server communication, and more so when large structural systems are considered. In addition, it is easy to implement in standard browsers, and its simple syntax makes it very suitable for this type of application in structural analysis. On the other hand, XML seems only suitable in the case of small structural systems, or in cases were compatibility with different platforms is at stake. In general terms when considering the efficiency in the communication protocol, there is a minor advantage in using AJAX over WebSocket. However, if PHP and Apache are simultaneously used in the server, then a communication based on AJAX is easier to implement, particularly in the side of the server. On the other hand, the use of WebSocket would require the implementation of a protocol, although some libraries such as Ratchet would facilitate this task. Conversely, WebSocket has the advantage of providing bidirectional and full-duplex communications, making it very attractive when frequent calls between the server and the client are needed. The communication design should not depend only on the conclusions stated in this research. There are other factors and vari-
Please cite this article as: J. Calvo et al., Robust design to optimize client–server bi-directional communication for structural analysis web applications or services, Advances in Engineering Software (2017), http://dx.doi.org/10.1016/j.advengsoft.2017.04.010
JID: ADES
ARTICLE IN PRESS J. Calvo et al. / Advances in Engineering Software 000 (2017) 1–11
ables that cannot be optimized from the response time point of view but could provide other benefits. Factors such as implementation time, development stack and compatibility with previous services are quite significant and valuable for software development companies. Acknowledgement The financial support provided by the Spanish Ministerio de Economía y Competitividad under contract BIA2013-48069-C2-1-P is gratefully acknowledged. References [1] Calvo J, Gracia J, Bayo E. Aplicación web para el análisis y diseño de estructuras. Informes de la Construcción 2014;66(extra-1):m001. doi:10.3989/ic.13. 075. [2] Subashini S, Kavitha V. A survey on security issues in service delivery models of cloud computing. J Netw Comput Appl 2011;34(1):1–11. [3] Miller M. Cloud computing: Web-based applications that change the way you work and collaborative online. 1st ed. Que Publishing; 2008. ISBN 0-7897-3803-5. [4] Gracia J, Bayo E. Integrated 3D web application for structural analysis software as a service. J Comput Civ Eng 2013;27(2):159–66 doi: 10.1061.
[m5G;May 10, 2017;8:31] 11
[5] Nuggehally M, Liu YS, Chaudhari SB, Thampi P. An internet-based computing platform for the boundary element method. Adv Eng Softw 2003;34:261–9. [6] Peng J, Law KH. Building finite element analysis programs in distributed services environment. Comput Struct 2004;82:1813–33. [7] Chen H, Lin Y, Chao Y. Application of web services for structural engineering systems. J Comput Civ Eng 2006;20(3):154–64. [8] Chen H, Lin Y. Web-FEM: an internet-based computing framework for the simulation of multi-scale response of structural systems. Struct Eng Mech 2011;13(1):17–37. [9] Yang Z, Lu J, Elgamal A. A Web-based platform for computer simulation of seismic ground response. Adv Eng Softw 2004;35:249–59. [10] Mackie RI. Application of service oriented architecture to finite element analysis. Adv Eng Softw 2012;52:72–80. doi:10.1016/j.advengsoft.2012.07.002. [11] Gracia J, Bayo E. Stream sockets versus web services for high-performance and secure structural analysis in internet environments. J. Comput. Civ. Eng. 2009;23:47–56. [12] Tanco M, Viles E, Pozueta L. Diferentes enfoques del diseño de experimentos. Memoria de Trabajos de Difusión Científica y Técnica 2009;7:29–37 ISSN 1510-7450. [13] Wang G. Improving data transmission in web applications via the translation between XML and JSON. Third Int Conf Commun Mobile Comput 2011:182–5. [14] http://www.w3.org/TR/XMLHttpRequest/. [15] http://www.w3.org/TR/eventsource/. [16] http://www.w3.org/TR/websockets/. [17] Montgomery DC. Design and analysis of experiments. 6th ed. Willey; 2005. [18] Pozueta L, Tort-Martorell X. Identifying dispersion effects in robust design experiments—issues and improvements. J Appl Stat 2007;34(6):683–99.
Please cite this article as: J. Calvo et al., Robust design to optimize client–server bi-directional communication for structural analysis web applications or services, Advances in Engineering Software (2017), http://dx.doi.org/10.1016/j.advengsoft.2017.04.010
JID: ADES
[m5G;May 10, 2017;8:31]
Advances in Engineering Software 0 0 0 (2017) 1–11
Contents lists available at ScienceDirect
Advances in Engineering Software journal homepage: www.elsevier.com/locate/advengsoft
Robust design to optimize client–server bi-directional communication for structural analysis web applications or services J. Calvo a,∗, J. Gracia b, E. Bayo a a b
Department of Building Construction, Services and Structures, University of Navarra, Pamplona, Navarra 31009, Spain Department of Construction and Manufacturing Engineering, University of Oviedo, Oviedo, Asturias 33003, Spain
a r t i c l e
i n f o
Article history: Received 20 January 2017 Revised 17 April 2017 Accepted 30 April 2017 Available online xxx Keywords: Cloud computing Web application Bi-directional communication Engineering structures Factorial design Robust design
a b s t r a c t Current trends in web application development favours bi-directional communication between front-end and back-end applications instead of the traditional ones where the front-end is constantly monitoring the back-end. This way of communication improves the user experience and this work tries to find the best bi-directional way of communication particularized to structural analysis software as a service or web applications. The effects of the most significant factors have been studied to optimize the total time involved in the communication, which is comprised of: time spent sending data from the client to the server, server data processing, and time consumed returning the data back. Design of experiments (DoE) techniques have been used to characterize the influence of four factors: serialization language, communication protocol, amount of data (size of the structure measured by the number of elements), and server post-processing. Moreover, factors like server workload and network congestion have also been addressed. The first factor is dealt with as a nuisance factor whose influence is to be minimized, and the second one as an uncontrollable variable. © 2017 Elsevier Ltd. All rights reserved.
1. Introduction The software market trend is evolving towards software as a service for consuming products (SaaS) over the Internet. The number of companies following this trend is constantly increasing. Office 365, AutoCad 360 or file storing services like Dropbox, OneDrive or Google Drive, have become successful examples. The SaaS distribution system has many benefits over traditional ones, as explained by Calvo et al. [1], by Subashini and Kavitha [2], and by Miller [3]: high availability through any device connected to Internet, real time software updates and pay-per-use business model. Previous works done by Gracia and Bayo [4], Nuggehally et al. [5], Peng and Law [6], Chen et al. [7,8], Yang et al. [9], and Mackie [10], show that structural analysis software can be provided as a SaaS. SaaS is similar to traditional client–server applications where each one is responsible for some particular task, therefore optimal communication is crucial for the service to succeed. Moreover, client requirements are beyond one-way communications systems. Current services require that the client will receive data and notifications not only when it is requested but also when the server produces them. Facebook and Twitter are examples of services that
∗
Corresponding author. E-mail addresses: [email protected] (J. Calvo), [email protected] (J. Gracia), [email protected] (E. Bayo).
make use of bidirectional communication to keep the client up-todate. They use traditional techniques like Long-Polling or new ones like WebSocket, that is, socket over HTTP protocol. Nowadays, it is relatively fast for a computer to solve a structural system with thousands of degrees of freedom. This has benefited structural engineers who can develop more complex structural models. However, if we want to move structural analysis software to the internet environment we will have to deal with large amounts of data that need to be sent across Internet. The time data takes to travel from the client to the server, and vice versa, will strongly influence the user experience. Consequently, several decisions have to be made: what processes will be performed in the client and which ones in the server; what type of communications protocol; and what data serialization format, among others. This paper is aimed at providing enough information to choose the best communication technology for structural analysis applications on the Internet environment. This paper identifies the factors that affect communication time and the technology (or combination of technologies) that is best suited to exchange structural data for Structural Analysis Software as a Service. In this respect, Gracia and Bayo [11] performed previous research focused on conventional client–server communication technology. In order to simulate user experience, the communication time is measured from client data serialization until data is returned
http://dx.doi.org/10.1016/j.advengsoft.2017.04.010 0965-9978/© 2017 Elsevier Ltd. All rights reserved.
Please cite this article as: J. Calvo et al., Robust design to optimize client–server bi-directional communication for structural analysis web applications or services, Advances in Engineering Software (2017), http://dx.doi.org/10.1016/j.advengsoft.2017.04.010
JID: ADES 2
ARTICLE IN PRESS
[m5G;May 10, 2017;8:31]
J. Calvo et al. / Advances in Engineering Software 000 (2017) 1–11
back from the server. Specifically, the client application stores the data of the structure (nodes, elements, material properties, etc.) as a JavaScript object that needs to be serialized before is sent to the server. Once the data is received, the server relocates the nodes and the elements, and calculates the total weight of the structure (thus considering the server arithmetic operations). Finally, it will serialize the modified structure and send it back to the client, which will parse the data again as a JavaScript object. The client has been implemented following HTML5 standards: JavaScript, CSS and HTML, while the server has been developed with PHP, a wellknown server-side programming language designed for web applications. This DoE is mainly focused on four primary factors: serialization language, communication protocol, size of the structure and server post-processing. Server workload (noise) and network congestion are also considered but as nuisance factors. Factors like the web browser and the web server are not relevant for this study and have been considered as constant factors. To identify parameter interactions a full factorial design is chosen. Finally, robust parameter design (RPD) techniques are applied to minimize the influence of the noise factor. Different models of DoE techniques are summarized by Tanco el al. [12]. In the following sections, the factors analysed in the experimental program are identified. Then, the application developed to measure response times is introduced. Finally, and after following DoE methodology, an analysis of the results is presented. 2. Experimental program This section describes the experimental program that has been developed to identify the best bi-directional communication setup for web services (or web applications) specialized in the analysis and design of structures. As mentioned before, several tools and protocols are studied by means of a DoE. One of the main difficulties of this experimental program is to deal with uncontrollable factors. As stated before, in order to develop structural analysis software on Internet several software architectural decisions have to be made. One of these is which processes are implement on the client side (front-end) and which ones on the server side (backend). If heavy processes are implemented at the server side the computer hosting the server should be able to handle large amount of simultaneous user requests and also to resolve each request as quickly as possible, so that the user experience is not compromised. The main advantage of this architecture is that users do not need high performance computers, since heavy processes are executed at the server. Conversely, if these processes are executed at the client side, the response will be fastest and the server workload will decrease accordingly. User experience will be improved and cheaper servers would be enough to host the web application. However, the main disadvantage is that the code is accessible by users, in some sense it becomes public. One option is to obfuscate the JavaScript code but it will continue to be accessible. In this research, the first option is adopted and therefore heavy processes are implemented at the server side along with client and server exchanging all the information relative to the structural models. In this way, communication times will be measured to find which technology performs better. 2.1. Objective and variables Experimental software has been developed to automatize the measurements and the testing needed to identify the influence of the factors mentioned above. This software allows the selection of a combination of levels for each primary factor and to simu-
late client–server communications. It also simulates the workload at the server side. The total time consumed in a full communication cycle is selected as the response measurement for each experiment. Time becomes critical when identifying the efficiency of each factor and when assessing the user experience. The time is measured in milliseconds and the main target of the DoE is to identify the factors that minimize it. The experiment factors can be classified into three types: primary, constant and nuisance. The former ones are factors whose influence is unknown and are selected as the main target of the experimental program. Constant factors can also affect the experiments but they are not selected as targets of the research. Nuisance factors are not interesting for the research; they are uncontrollable and can modify measurements unexpectedly. Nuisance factors that can be controlled in the experimental setup are referred to as noise factors. Four primary factors have been identified in this experimental program: serialization language, communication protocol between client and server, data size of the engineering structure and server data processing. The main constant factors that will not be studied are: web browser (it has an influence but does not determine the best primary factors for optimal bi-directional communication), server programing language, and web server application. Finally, there are two factors that affect the time measures but are uncontrollable: network congestion during experiments and server workload. The last one will be treated as a noise factor. Hereafter a thorough explanation of each primary factor that has been studied will be described. 2.1.1. Serialization language Each application defines its own data model as arrays, objects, databases or any other data structure. However, in order to communicate with other applications, this data model has to be serialized. This process translates data into a format that can be stored or transmitted across the network so that it can be reconstructed in the same or another computer (the server in this case). The main drawback is that data is commonly translated into ASCII strings. The ASCII representation of numeric values is larger than the binary representation. However, serialized data is standard while binary data has to be transformed depending on whether the destination machine is low endian or big endian. The most widely supported languages in SaaS are XML (eXtensible Markup Language) and JSON (JavaScript Object Notation). Wang [13] provided an interesting comparison between these two languages. In this research, a less popular serialization language named YAML (recursive acronym for “YAML Ain’t Another Markup Language”) has been also studied. Fig. 1 shows a small example of the syntax of these three languages. XML is the most widely supported. It was design as a simple, very flexible, text formatting language. It is playing an increasingly important role in the exchange of a wide variety of data on the Web and elsewhere. There are a variety of APIs to access XML data; some of them have been standardized. Nonetheless, XML support has been implemented in different ways on each browser and as a consequence performance is not constant among them. It is extremely compelling, compared to JSON and YAML, when dealing with complex data structures. However, its heavy use of mark-up tags tends to transform data structures into large strings, increasing the amount of information to be transferred. Meanwhile, JSON is gaining adepts in web development environments, and it has a huge support in most browsers. Its syntax is similar to JavaScript, key/value pair notation is the mechanism to store and read data. Data serialised in JSON is lighter than in XML: it represents the same amount of data with less characters. Front-end web developers used it to speed up the development of
Please cite this article as: J. Calvo et al., Robust design to optimize client–server bi-directional communication for structural analysis web applications or services, Advances in Engineering Software (2017), http://dx.doi.org/10.1016/j.advengsoft.2017.04.010
JID: ADES
ARTICLE IN PRESS
[m5G;May 10, 2017;8:31]
J. Calvo et al. / Advances in Engineering Software 000 (2017) 1–11
3
Fig. 2. Differences in communication protocols.
Fig. 3. 19 elements structural system.
Fig. 1. Comparison of the structure of XML, JSON and YAML.
client–server communication in order to design rich and dynamic web pages. One of its main drawbacks is the possible improper use of the JavaScript ‘eval()’ function which may cause security issues. Finally, YAML is a human-readable data serialization language. It is also much more compact than XML, because break lines and white spaces are used instead of explicit mark-ups or brackets. Nevertheless, it is a less common language and it is not well supported by web browsers, as a consequence external libraries are required most of the time. Its main feature is that serialized data becomes more legible and readable. 2.1.2. Communication protocol A communication protocol is defined as a system of rules that allow two or more entities of a communication system to transmit information. Communication protocols are implemented in hardware and software but we will only focus on software. As mention before, the aim of this research is to improve asynchronous bi-directional client–server web application communication so that we can update client and server contents simultaneously. Currently there are several technologies, which are not explicitly protocols, but we will treat them as if they were. They define the same parameters as protocols: syntax, semantics and synchronization of communication. As an example, AJAX (Asynchronous JavaScript and XML) use HTTP as its main protocol defining additional rules for requesting data. At the other end, we have technologies such as WebSocket that use TCP/IP socket layer over HTTP port. Hereafter, the most commonly known technologies will be presented. However, the experimental setup will only include the most relevant ones. AJAX technology is widely supported by most web browsers. It is based on open standards like JavaScript, DOM (Document Object Model) and XMLHttpRequest object (W3C 2014) [14]. With AJAX, web browsers can send data to and retrieve from a server asynchronously (in the background) without interfering with the display and behaviour of the existing page. Long-Polling is a variation of the traditional polling technique. The client requests information from the server trough an AJAX request. Then, the server keeps the communication channel open until it has information available for the client. Once the client receives the data, a new request is generated so the communication channel is always open. Most web browsers also support this method. Server-sent events (SSE) is a new technology part of HTML 5 standard (W3C 2015) [15]. In this case, the web browser receives automatic updates from the server through the HTTP connection. Its main feature is that only the server can send data. If data transmission from the client is required, it has to be implemented
Fig. 4. 480 elements structural system.
by means of another mechanism. This technology is easy to implement and most web browsers, excluding Internet Explorer, support it. Finally, WebSocket is a protocol that provides full-duplex bidirectional communication over a TCP socket (W3C 2012) [16]. After the connection is established, the client and the server can send data back and forth at any time. It supports multiplexing over the same connection and is not blocked by firewall policy rules (HTTP port is usually open), unlike network sockets that are usually blocked by network infrastructure managers. Once the HTTP protocol handshake is finished, communication efficiency is similar to native network sockets. WebSocket is best suited for applications where data exchange is frequent or happens in real time. However, implementation at the server side is usually more complex depending on the programing language. Fig. 2 shows a flow chart for each communication technique. Long-Polling is similar to AJAX. The main difference is the communication trigger. With AJAX, clients start the request-response loop while with Long-Polling the server becomes the trigger of the loop. In this research, the server response always comes after the client request; consequently, AJAX is preferred over Long-Polling. For the same reason, SSE will not be considered. Server-sent event is focused on real-time communication in one-way only, server to client, similar to a publish-subscribe service. Therefore, this research includes AJAX and WebSocket as levels for the communication protocol. 2.1.3. Structure data size This research is focused on structural analysis web applications and/or services. The data to be transmitted is composed of all the information that completely defines a 3D structural system of frames. In this experiment the structure is composed of three different objects: nodes, elements and cross sections. The node objects include three-dimensional coordinates, the applied loads, and the restrain information about each degree of freedom. Then, element objects contain a node reference for each node of the element (two in this case), a reference to a cross section, and definition of the type of connection at each node, simple or rigid. Finally, the cross sections are defined by means of material properties: elastic modulus and density; and main properties of the section: areas and moment of inertias. Figs. 3 and 4 show two topologies used in the experimentation with 19 and 480 elements, respectively.
Please cite this article as: J. Calvo et al., Robust design to optimize client–server bi-directional communication for structural analysis web applications or services, Advances in Engineering Software (2017), http://dx.doi.org/10.1016/j.advengsoft.2017.04.010
JID: ADES 4
ARTICLE IN PRESS
[m5G;May 10, 2017;8:31]
J. Calvo et al. / Advances in Engineering Software 000 (2017) 1–11
The size of the structure is a relevant factor; larger structures will lead to larger serialized strings that will require more time to be transmitted. In addition, the server will take more time to process it and serialization/deserialization time will also increase accordingly. In this study, the number of elements is the variable chosen to characterize the size of the structure. 2.1.4. Server processing The main task of structural analysis software is to compute displacements and internal forces. In this case, the research is focused on communication not on computing efficiency. However, a solver to obtain displacements from known loads has been implemented in the server. Additionally, the weight of the structure is calculated and sent to the client together with the nodal displacements. Server processing is not equal for every user: it depends on the size of the problem to be solved and on the type of analysis to be performed. The size of the structure is chosen as one of the primary factors to be analysed. To account for different types of server workload a factor named “server processing” is included. This factor defines how many times the structure will be solved at the server. In this way, a non-linear analysis setting can be tested. It is important to note that the main target of the experimentation is not the values that are measured but how each factor affects data communication. 2.1.5. Server workload (noise factor) The server workload when an experiment is conducted is another factor that may have an impact on the results. This workload is due to multiple circumstances such as operating system processes or user applications executing in the background. This workload is not constant, therefore its influence on the experiment is not uniform. Nonetheless, its influence is not interesting for this research and can be controlled during the experiment. The server workload is controlled allowing two levels of intensity, light and heavy CPU workload. The former is guaranteed by disabling all non-critical system services after a fresh start-up of the machine. The server workload has been always below 5% and close to 2%. For heavy workload, the program Intel Burn Text 2 has been used to raise the CPU utilization to 100%. 2.1.6. Network congestion (nuisance factor) Lastly, network congestion is another factor that affects communication. Any subtle variation of the network traffic will generate delays of data packets transmitted between client and server. Local land network congestion can be easily controlled, however controlling it over an Internet connection is not possible. 2.2. Design of experiments Experimentation is necessary to study the behaviour and relation between two or more distinct variables. Traditional experimentation is focused on studying variables one by one. It means one variable is modified while the rest are kept fixed. This methodology requires a huge amount of experimentation and all possible combinations have to be tested. Sometimes this is not possible due to time or budget limits. Moreover, it has another important drawback: interaction between factors is harder to identify. For this research, a Design of Experiments (DoE) methodology has been chosen. With DoE, interaction between factors can be easily identified and the influence of nuisance factors can also be reduced, as explained in Montgomery (2005) [17]. To minimize variability caused by server workload (noise factor), a robust design method has been preferred (Pozueta and TortMartorell, 2007) [18]. First, an initial set of tests is performed to identify which levels of the primary factors reduce the server workload impact. Then, a second round of tests are conducted. In
Fig. 5. Displacements of a 480 elements structural system.
this round, levels identified are used to perform a factorial design where the server workload factor is set at fixed values. Conversely, noise factor, the network congestion, cannot be controlled during the experimentation. Its influence has been minimized by executing all the runs of the experiment randomly. In this study, the experimentation has been carried out with software developed for this purpose. This software can easily test any number of combinations of factors. Because of this, full factorial design will be performed and it will be done twice to allow a better identification of the variability sources. 3. Experimental prototype Client–server software to automatize the experimentation and response time are described below. 3.1. Client–server software The software developed is composed of one client application, two server applications and a structural analysis solver library. The first one is a web application developed in JavaScript and HTML. Both servers are developed with PHP. One of them is hosted on an Apache Web Server to dispatch AJAX requests and the other is developed as a standalone server to dispatch WebSocket requests. Finally, a solver has been developed as a C++ command application. Both servers call the solver. Fig. 5 shows the displaced structure of Fig. 4 rendered from the calculated displacements by the server and returned to the client. The web application provides a user-friendly interface to select values for each factor and to run the combination. It implements subroutines to serialize/deserialize data for each language and to transmit data trough AJAX or WebSocket calls (see Fig. 6). At the client side, functions to code and decode JSON objects are provided by JavaScript. However, XML and YAML format are not natively supported by Javascript so two third party libraries have been used (see Fig. 7). Server communication at the client has been implemented with jQuery for AJAX requests and standard HTML5 API calls for WebSocket requests (see Fig. 8). On the other hand, both server applications share a common core (see Figs. 10 and 13). They implement subroutines to serialize/deserialize and process data. In this case, PHP core has native support for JSON and XML data. However, YAML format has been handled by means of a third party library (see Fig. 9). The AJAX server version has been developed using standard PHP functions to dispatch requests (Fig. 11). The WebSocket version uses the Ratchet library, which provides tools to create WebSocket communications (Fig. 12). Ratchet uses the React library to implement event-loop mechanisms that keep the application listening all the time. The full stack works as follows. Firstly, both services are started at the server. Then, the client initializes both connections and keeps them ready on memory. Two JavaScript objects are created for this purpose. They contain all the methods and events necessary to communicate with both servers. This operation is important so that the initial setup will not affect the tests.
Please cite this article as: J. Calvo et al., Robust design to optimize client–server bi-directional communication for structural analysis web applications or services, Advances in Engineering Software (2017), http://dx.doi.org/10.1016/j.advengsoft.2017.04.010
JID: ADES
ARTICLE IN PRESS
[m5G;May 10, 2017;8:31]
J. Calvo et al. / Advances in Engineering Software 000 (2017) 1–11
Fig. 9. Serialization/deserialization server subroutines.
Fig. 6. Capture of the client application.
Fig. 7. Serialization/deserialization client subroutines.
Fig. 8. Client communication subroutines.
Fig. 10. Overall view of process involved.
Please cite this article as: J. Calvo et al., Robust design to optimize client–server bi-directional communication for structural analysis web applications or services, Advances in Engineering Software (2017), http://dx.doi.org/10.1016/j.advengsoft.2017.04.010
5
ARTICLE IN PRESS
JID: ADES 6
[m5G;May 10, 2017;8:31]
J. Calvo et al. / Advances in Engineering Software 000 (2017) 1–11 Table 1 Levels of factors in the preliminary experimentation. Factors
Levels
Serialization language Communication protocol Structure data size Server processing Server workload (Noise)
A B C D E
JSON AJAX 64 1 Heavy
XML WebSocket 800 20 Light
YAML
Fig. 11. Server AJAX communication subroutine. Table 2 Factors and codes. Factors Serialization language Communication protocol Structure data size Server processing Server workload (Noise)
Fig. 12. Server WebSocket communication subroutine.
As mentioned before, the other task performed by servers is data processing. The received data is deserialized into PHP objects so they can be processed. Two operations are performed with the data: structural analysis and weight analysis. The weight is calculated by the same PHP process that receives the data, while the structural analysis is carried out through a call to an external C++ command solver executed by means of PHP “exec” function (see Fig. 13). 3.2. Response time The total response time of each conducted test will include several measures: data serialization/deserialization (at the client and at the server), transmission time and processing time at the server. This value can be measured in several ways. However, most of the time the response time is very small (milliseconds) and the clock time coincidence of each machine cannot be guaranteed at this level of precision. The best way to measure is to use the difference between the time measured before the client serializes the data and the time measured once the client deserializes the server response. Both values will be measured at the client side. Nonetheless, for the purpose of collecting as much information as possible from each experiment, the software stores the time spent for each sub-process. Sub-process time at the server side is evaluated in the same way and each value is concatenated into a string that is appended to the response data. The only value that is not directly measured is the transmission time. However, it can be easily assessed from the other measures. Although this information is not quite relevant for DoE, it is useful for a general overview of all the sub-processes involved in a test. Besides, the impact of performing these measurements as well as transmitting them attached to the response data is almost negligible for the experiment. Fig. 14 shows a chart with all the measured sub-process that affect the response time. 3.3. Testing environment Experimental tests have been performed with two types of computers: one for the client application, a personal computer run locally; and another for the server, a virtual private server (VPS) hosted in Amazon Web Services (AWS). VPS is a t2.micro EC2 instance type. This is a virtual server equivalent to a physical computer with one Intel Xeon (E5-2676)
Description A B C D E
Serialization language used Client–server communication protocol Structure size (number of frames) Server editing operations (loops) Server load (stress CPU program)
CPU core (up to 2,4 Ghz) and 1GB of RAM. VPS runs a Windows Server 2012 (x64 version) operation system. Apache 2.4.9 with php_mod enabled (version 5.5.12) was used as web server. Both technologies were installed as 64 bits version. WebSocket server was developed with PHP 5.6 (x86 version) and two specific libraries: Ratchet and React. Client machine hardware specifications are: Intel Core i7 2720Q (up to 3,30 GHz) 4 cores (8 threads) CPU and 8GB DDR3 1600 Mhz dual channel memory. During the test client machine was also running Windows 10 Pro (x64 version) as operating system. Internet Explorer 11 was used as the web browser. The AWS instance is located at one of the data centres that Amazon has deployed in Ireland. The client machine (laptop) is in Spain and is connected to Internet through a high-speed connection. 4. Experimentation results As mentioned above, a robust parametric design is proposed to minimize the noise factor that depends on the server load. For this purpose, a first experimentation is done to assess the levels of the relevant factors involved in the response. Then, taking these levels into account, a full factorial design is performed to obtain the influence of each of the individual factors on the overall response: elapsed total time in milliseconds. However, prior to the proposed selective robust design and acquisition of preliminary data, a full factorial design is performed with all the factor levels. 4.1. Initial experimentation We consider four primary factors: language, protocol, data size and solver process; and we are interested in knowing their influence in the overall response. In addition, we consider two nuisance factors: network congestion and server workload that also intervene and whose influence needs to be minimized. The server workload factor is controllable during the experimentation; however, the Internet network congestion is not controllable. Due to this reason, all the runs that have been performed during this and the following experimentations have been carried out in a random manner, although for the sake of the reader’s convenience the resulting data is presented in table form in an orderly way. Therefore, after eliminating the Internet factor, a full mixed factorial design is performed with five factors. A replica is also added, thus yielding a design of size 3 × 24 x 2. Tables 1 and 2 show the factors and codes used in the experimentation and their respec-
Please cite this article as: J. Calvo et al., Robust design to optimize client–server bi-directional communication for structural analysis web applications or services, Advances in Engineering Software (2017), http://dx.doi.org/10.1016/j.advengsoft.2017.04.010
JID: ADES
ARTICLE IN PRESS
[m5G;May 10, 2017;8:31]
J. Calvo et al. / Advances in Engineering Software 000 (2017) 1–11
Fig. 13. System architecture of experimental prototype.
Fig. 14. Sequence of process involved on each measured response.
Fig. 15. Main effects affecting the response.
Please cite this article as: J. Calvo et al., Robust design to optimize client–server bi-directional communication for structural analysis web applications or services, Advances in Engineering Software (2017), http://dx.doi.org/10.1016/j.advengsoft.2017.04.010
7
ARTICLE IN PRESS
JID: ADES 8
[m5G;May 10, 2017;8:31]
J. Calvo et al. / Advances in Engineering Software 000 (2017) 1–11 Table 4 Levels of factors in the first experimentation.
Table 3 Responses in the preliminary experimentation. Factors
Response
Factors
A
B
C
D
E (Noise)
Results
Replica
JSON JSON JSON JSON JSON JSON JSON JSON JSON JSON JSON JSON JSON JSON JSON JSON XML XML XML XML XML XML XML XML XML XML XML XML XML XML XML XML YAML YAML YAML YAML YAML YAML YAML YAML YAML YAML YAML YAML YAML YAML YAML YAML
AJAX AJAX AJAX AJAX AJAX AJAX AJAX AJAX WebSocket WebSocket WebSocket WebSocket WebSocket WebSocket WebSocket WebSocket AJAX AJAX AJAX AJAX AJAX AJAX AJAX AJAX WebSocket WebSocket WebSocket WebSocket WebSocket WebSocket WebSocket WebSocket AJAX AJAX AJAX AJAX AJAX AJAX AJAX AJAX WebSocket WebSocket WebSocket WebSocket WebSocket WebSocket WebSocket WebSocket
64 64 64 64 800 800 800 800 64 64 64 64 800 800 800 800 64 64 64 64 800 800 800 800 64 64 64 64 800 800 800 800 64 64 64 64 800 800 800 800 64 64 64 64 800 800 800 800
1 1 20 20 1 1 20 20 1 1 20 20 1 1 20 20 1 1 20 20 1 1 20 20 1 1 20 20 1 1 20 20 1 1 20 20 1 1 20 20 1 1 20 20 1 1 20 20
Heavy Light Heavy Light Heavy Light Heavy Light Heavy Light Heavy Light Heavy Light Heavy Light Heavy Light Heavy Light Heavy Light Heavy Light Heavy Light Heavy Light Heavy Light Heavy Light Heavy Light Heavy Light Heavy Light Heavy Light Heavy Light Heavy Light Heavy Light Heavy Light
79 77 91 79 277 269 265 267 141 150 143 143 1648 1058 1709 1141 397 213 419 385 1787 1947 3126 1781 341 347 345 345 4092 3338 4060 3267 1586 967 1636 885 26,804 13,455 26,955 25,628 1606 2255 1570 1080 29,303 14,875 27,488 14,898
77 81 73 76 242 240 306 239 88 91 86 72 327 334 346 338 225 208 224 244 1818 2114 1760 1837 258 254 257 257 1992 1981 2137 2006 281 292 1542 475 6885 3711 8097 5143 385 373 380 389 7761 6111 7749 6224
tive levels. Table 3 depicts all the responses corresponding to the different runs and their replicas. Lastly, Figs. 15 and 16 show the main effects and the interactions between variables after the experimentation analyses. It may be seen that YAML notably increases the response time when compared with the other languages, therefore in the next round of experiments YAML is discarded as serialization language. 4.2. First experimentation The objective of this experimentation is to reduce the influence of the noise factor on the response. Robust design (RPD) is used for this task. Since the YAML effect has already been discarded, there will be two level designs for all the factors (see Table 4). A full factorial design for 4 primary factors is performed for each of the two levels of the noise factor (light and heavy server workload). Finally, the experiment is conducted again (replica) thus conforming a 24 x 2 × 2 design. Table 5 depicts all the responses. The resulting data is analysed considering the variance as the measure of the response. The sig-
Serialization language Communication protocol Structure data size Server processing Server workload (Noise)
Levels A B C D E
JSON AJAX 64 1 Heavy
XML WebSocket 800 20 Light
nificant primary factors are the size (C) and the protocol (B). Thus, considering these significant factors the following regression equation is obtained:
Ln(V ar ) = 8, 796 − 4, 191B + 0, 005019C
(1)
Consequently, in order to reduce the variability, one will have to increase the factor B and decrease the factor C. Notice however, that since the protocol (B) is an attribute, it cannot be modified. B↑, C↓ The next step is to carry out another analysis, but this time taking the average time as the response measure. The following significant factors are considered: the size (C), the language (A) and the protocol (B). The resulting regression equation becomes:
Y = 96, 04 + 6, 105A − 69, 49B + 2, 88C
(2)
Similarly, it is observed that in order to reduce the average time, one will have to decrease A and C, and increase B. The factor A (language) and B (protocol) will remain unchanged. A↓ , B↑ , C↓ Consequently, in order to reduce the influence of the noise factor (server) one will have to consider lower levels for the size factor (C). 4.3. Second experimentation We now proceed with another experimentation in which we will exclude the noise factor. The noise will remain constant, with a low value, during the whole experiment. In view of the results of the previous experimentation, we will decrease the level values of the size factor so that the noise effect will also decrease. As done before, the simulations will be carried out in a random order to minimize other perturbing factors. Consequently, the new factors to be considered are shown in Table 6. The experimentation is comprised of a full factorial design of size 24 with an additional replica, thus resulting in a 24 x 2 design. Table 7 shows the responses while Fig. 17 illustrates the values of the variables (factors) and their interactions after the experimentation analyses. It may be observed that the factors C, A and AC become very significant and also, although to a lower extent, the factor B and the combination BC. The statistical significance level (Alpha) is 0.05 for all the experiments. The main effects and interactions between factors are depicted in Figs. 18 and 19. It may be seen that the factors that have the most influence on the response are the language (A) and the size of the structure (C) and, although to a lower extent, the protocol (B). However, it may also be observed from the graphs that the choice of language in combination with size becomes also important (interaction AC). Finally, the regression equation that relates the different factors and that is obtained after the experiment becomes:
Y = 78 + 11, 8A + 6, 3B + 1, 8235C + 1, 1388AC + 0, 09BC + 0, 4514BC + 2, 5AB + 0, 0844ABC
(3)
5. Analysis and assessment The preliminary experimentation provided an estimation of the influence of each factor. It showed that factors such as language,
Please cite this article as: J. Calvo et al., Robust design to optimize client–server bi-directional communication for structural analysis web applications or services, Advances in Engineering Software (2017), http://dx.doi.org/10.1016/j.advengsoft.2017.04.010
ARTICLE IN PRESS
JID: ADES
[m5G;May 10, 2017;8:31]
J. Calvo et al. / Advances in Engineering Software 000 (2017) 1–11
9
Fig. 16. Interactions among factors. Table 5 Responses, averages and variances. Factors
Results
Response
A
B
C
D
Result (E+)
Replica (E+)
Result (E-)
Replica (E-)
Average
Ln(Var)
JSON JSON JSON JSON JSON JSON JSON JSON XML XML XML XML XML XML XML XML
AJAX AJAX AJAX AJAX WebSocket WebSocket WebSocket WebSocket AJAX AJAX AJAX AJAX WebSocket WebSocket WebSocket WebSocket
64 64 800 800 64 64 800 800 64 64 800 800 64 64 800 800
1 20 1 20 1 20 1 20 1 20 1 20 1 20 1 20
1440 1449 1782 319 156 177 2326 2115 1600 1756 2829 2973 380 428 5458 5516
89 93 370 350 152 182 2257 2152 244 264 3380 2319 375 529 5187 5525
273 211 634 705 184 169 1241 1166 491 498 2600 2677 373 399 3844 3851
79 96 301 306 158 180 1292 1165 231 273 2568 2139 350 452 3989 3883
181 153.5 502 334.5 157 178.5 1774.5 1640.5 367.5 385.5 2714.5 2498 374 440 4588 4699.5
12.96199957 12.98485208 13.06937654 10.50344065 5.35501271 3.48635519 12.769781 12.65258266 12.95425158 13.14108356 11.85706525 11.83796112 5.179909135 8.040661635 13.42200811 13.72288884
Table 6 New levels of factors for the second experimentation. Factors
Levels
Serialization language Communication protocol Structure data size Server processing
A B C D
JSON AJAX 19 1
XML WebSocket 480 20
Table 7 Responses for the second experimentation. Factors
Response
A
B
C
D
Results
Replica
JSON JSON JSON JSON JSON JSON JSON JSON XML XML XML XML XML XML XML XML
AJAX AJAX AJAX AJAX WebSocket WebSocket WebSocket WebSocket AJAX AJAX AJAX AJAX WebSocket WebSocket WebSocket WebSocket
19 19 480 480 19 19 480 480 19 19 480 480 19 19 480 480
1 20 1 20 1 20 1 20 1 20 1 20 1 20 1 20
68 72 223 219 88 88 597 577 128 126 1397 1482 166 170 1862 1924
69 69 220 237 92 93 594 600 127 142 1195 1175 165 174 1841 1923
Fig. 17. Pareto chart for standardized effects.
size and server workload have a significant influence on the response. In addition, it was observed that the interactions among the factor language and the factors data size and workload are very important when using the language YAML. Since the use of YAML increases the total time significantly, it was decided not to include it in the following experiments, and only use XML and JSON. The following experimentation indicated which of the two is the most efficient language. After the preliminary experimentation, a robust parameter design was carried out to minimize the impact of the noise factor
Please cite this article as: J. Calvo et al., Robust design to optimize client–server bi-directional communication for structural analysis web applications or services, Advances in Engineering Software (2017), http://dx.doi.org/10.1016/j.advengsoft.2017.04.010
JID: ADES 10
ARTICLE IN PRESS
[m5G;May 10, 2017;8:31]
J. Calvo et al. / Advances in Engineering Software 000 (2017) 1–11
Fig. 18. Main effects affecting for response.
Fig. 19. Interactions among factors.
generated by the server workload. This robust design consisted in two experimentations; the first one was aimed at selecting the levels of primary factors for which the influence of the noise factor is small; and the second to measure the influence of the factors in the overall response. The experimentations were carried out using a full factorial design. It was found, after the first experimentation, that the levels of the language and size factors should be reduced and the protocol factor should be increased to minimize the influence of the noise factor. However, the language and protocol factors are qualitative variables and their values cannot be increased or reduced. Only the size factor can be modified by changing the number of elements included in the structural model. The primary factors are tested in the second experimentation in which the value of the noise factor remains constant. The results showed the importance of the size and the language factors, and their interaction, in the overall response. Also, the protocol-size interaction was important. In addition, all the independent primary factors (except processing and protocol) have a significant influence in the response. The language factor has a large impact; in fact, the language XML leads to a much larger execution time than JSON. Also the size of the structure becomes important, since, as expected, the larger the structure the longer the simulation is. It is important to mention that the interaction between size and language is very significant: when the language XML is used, the size of the structure slows the response much more than when the language JSON is used. This makes JSON a better candidate for the simulations of large structural systems. Finally, it is important to mention that the experimentation has been performed in the best scenario of each protocol. This means,
in the case of AJAX, that before each test was conducted a previous connection was executed to keep-alive the connection, so initialization time did not become part of the response. AJAX communications are not keep-alive by default while WebSockets are. In a real environment, where calls to the server are not continuous, the time consumed by the AJAX calls will be close to the WebSocket calls, although the former will still be faster. 6. Conclusions It seems clear, from the results shown in this paper that the serial language JSON is the most efficient for client–server communication, and more so when large structural systems are considered. In addition, it is easy to implement in standard browsers, and its simple syntax makes it very suitable for this type of application in structural analysis. On the other hand, XML seems only suitable in the case of small structural systems, or in cases were compatibility with different platforms is at stake. In general terms when considering the efficiency in the communication protocol, there is a minor advantage in using AJAX over WebSocket. However, if PHP and Apache are simultaneously used in the server, then a communication based on AJAX is easier to implement, particularly in the side of the server. On the other hand, the use of WebSocket would require the implementation of a protocol, although some libraries such as Ratchet would facilitate this task. Conversely, WebSocket has the advantage of providing bidirectional and full-duplex communications, making it very attractive when frequent calls between the server and the client are needed. The communication design should not depend only on the conclusions stated in this research. There are other factors and vari-
Please cite this article as: J. Calvo et al., Robust design to optimize client–server bi-directional communication for structural analysis web applications or services, Advances in Engineering Software (2017), http://dx.doi.org/10.1016/j.advengsoft.2017.04.010
JID: ADES
ARTICLE IN PRESS J. Calvo et al. / Advances in Engineering Software 000 (2017) 1–11
ables that cannot be optimized from the response time point of view but could provide other benefits. Factors such as implementation time, development stack and compatibility with previous services are quite significant and valuable for software development companies. Acknowledgement The financial support provided by the Spanish Ministerio de Economía y Competitividad under contract BIA2013-48069-C2-1-P is gratefully acknowledged. References [1] Calvo J, Gracia J, Bayo E. Aplicación web para el análisis y diseño de estructuras. Informes de la Construcción 2014;66(extra-1):m001. doi:10.3989/ic.13. 075. [2] Subashini S, Kavitha V. A survey on security issues in service delivery models of cloud computing. J Netw Comput Appl 2011;34(1):1–11. [3] Miller M. Cloud computing: Web-based applications that change the way you work and collaborative online. 1st ed. Que Publishing; 2008. ISBN 0-7897-3803-5. [4] Gracia J, Bayo E. Integrated 3D web application for structural analysis software as a service. J Comput Civ Eng 2013;27(2):159–66 doi: 10.1061.
[m5G;May 10, 2017;8:31] 11
[5] Nuggehally M, Liu YS, Chaudhari SB, Thampi P. An internet-based computing platform for the boundary element method. Adv Eng Softw 2003;34:261–9. [6] Peng J, Law KH. Building finite element analysis programs in distributed services environment. Comput Struct 2004;82:1813–33. [7] Chen H, Lin Y, Chao Y. Application of web services for structural engineering systems. J Comput Civ Eng 2006;20(3):154–64. [8] Chen H, Lin Y. Web-FEM: an internet-based computing framework for the simulation of multi-scale response of structural systems. Struct Eng Mech 2011;13(1):17–37. [9] Yang Z, Lu J, Elgamal A. A Web-based platform for computer simulation of seismic ground response. Adv Eng Softw 2004;35:249–59. [10] Mackie RI. Application of service oriented architecture to finite element analysis. Adv Eng Softw 2012;52:72–80. doi:10.1016/j.advengsoft.2012.07.002. [11] Gracia J, Bayo E. Stream sockets versus web services for high-performance and secure structural analysis in internet environments. J. Comput. Civ. Eng. 2009;23:47–56. [12] Tanco M, Viles E, Pozueta L. Diferentes enfoques del diseño de experimentos. Memoria de Trabajos de Difusión Científica y Técnica 2009;7:29–37 ISSN 1510-7450. [13] Wang G. Improving data transmission in web applications via the translation between XML and JSON. Third Int Conf Commun Mobile Comput 2011:182–5. [14] http://www.w3.org/TR/XMLHttpRequest/. [15] http://www.w3.org/TR/eventsource/. [16] http://www.w3.org/TR/websockets/. [17] Montgomery DC. Design and analysis of experiments. 6th ed. Willey; 2005. [18] Pozueta L, Tort-Martorell X. Identifying dispersion effects in robust design experiments—issues and improvements. J Appl Stat 2007;34(6):683–99.
Please cite this article as: J. Calvo et al., Robust design to optimize client–server bi-directional communication for structural analysis web applications or services, Advances in Engineering Software (2017), http://dx.doi.org/10.1016/j.advengsoft.2017.04.010