Mohamed et al. SpringerPlus 2013, 2:511http://www.springerplus.com/content/2/1/511
RESEARCH Open Access
A study of an adaptive replication framework fororchestrated composite web servicesMarwa F Mohamed1*, Hany F ElYamany1 and Hamed M Nassar2
Abstract
Replication is considered one of the most important techniques to improve the Quality of Services (QoS) ofpublished Web Services. It has achieved impressive success in managing resource sharing and usage in order tomoderate the energy consumed in IT environments. For a robust and successful replication process, attentionshould be paid to suitable time as well as the constraints and capabilities in which the process runs. The replicationprocess is time-consuming since outsourcing some new replicas into other hosts is lengthy. Furthermore,nowadays, most of the business processes that might be implemented over the Web are composed of multipleWeb services working together in two main styles: Orchestration and Choreography. Accomplishing a replicationover such business processes is another challenge due to the complexity and flexibility involved. In this paper, wepresent an adaptive replication framework for regular and orchestrated composite Web services. The suggestedframework includes a number of components for detecting unexpected and unhappy events that might occurwhen consuming the original published web services including failure or overloading. It also includes a specificreplication controller to manage the replication process and select the best host that would encapsulate a newreplica. In addition, it includes a component for predicting the incoming load in order to decrease the time neededfor outsourcing new replicas, enhancing the performance greatly. A simulation environment has been created tomeasure the performance of the suggested framework. The results indicate that adaptive replication with predictionscenario is the best option for enhancing the performance of the replication process in an online businessenvironment.
IntroductionSoftware architecture is a set of structures that aims tounderstand the software capabilities and efficiency. Basic-ally, it defines and structures a software system into inter-related and well-established components (Len et al. 2003;May et al. 2009). Service-Oriented Architecture (SOA) isa particular architectural style to decompose the softwaresystem into a set of reusable, scalable, interoperable andbusiness-encapsulated components, typically called Webservices (Thomas 2005). Web services (WS) are pub-lished, described, discovered and accessed using severalstandard protocols including WSDL for service descrip-tion, SOAP for intercommunication, HTTP for binding
* Correspondence: [email protected] Science Department, Faculty of Computers and Informatics, SuezCanal University, 41522, Ismailia, EgyptFull list of author information is available at the end of the article
data over networks, and UDDI for service registrationand discovery (Papazoglou 2007).In the last decade, the number of web services has
increased steadily and the Business-to-Business (B2B)(Albert Napier et al. 2005) applications that demand themhave proportionally increased. Nowadays, the global mar-ket advocates web services vendors to integrate and worktogether under specific rules and constraints to implementcomplex business transactions that fulfill all customers’requirements. This type of web service integration andcombination is called web service composition. In particu-lar, there are a couple ways to composite web services:orchestration and choreography (Abdaldhem et al. 2009).In orchestration, a central component, called orchestrator,controls the communication and interaction among thedifferent running web services in an SOA environment.The invoked web services may not know that it is involved
is an open access article distributed under the terms of the Creative Commonsg/licenses/by/2.0), which permits unrestricted use, distribution, and reproductionroperly cited.
Mohamed et al. SpringerPlus 2013, 2:511 Page 2 of 18http://www.springerplus.com/content/2/1/511
in a composite process. Choreography, by contrast,has no central component, and the web services cer-tainly recognize that they are involved in a compos-ition process and therefore, can exchange messagesdirectly among themselves.WS providers are obligated to enhance the perform-
ance and availability of the exposed web service in themarket to quickly and effectively respond to all incomingrequests. Due to the huge number of messages that aWS may receive in a short time, the WS can fail or be-come intensively loaded, adversely affecting performanceand availability. The replication technology which meansproviding multiple resources, e.g. software or hardwarecomponents (Maamar et al. 2008), is considered one ofthe best solutions that would help WS providers to im-prove the performance and availability of their publishedWSs (Maamar et al. 2008). The availability ensures thatthe web service is ready for immediate customer con-sumption (W3C Working Group Note 2003). For exampleif a single service becomes overloaded or fails, other copieswill be initiated in order to answer the customer requests.Performance is concerned mainly with decreasing the re-sponse time of the incoming requests, through balancingthe requests among the available replicas.The replication process clearly requires extra space
and extra processing time. Thus, it should be establishedin a way that it can reduce the number of deployed rep-licas and continuously remove unused ones. Two im-portant factors should be monitored when checking thestatus of running replicas: ‘service load’ and ‘service pre-diction load’. Of course, when the service is overloadedit requires other copies to balance the load and hence, itmight consume unexpected large number of resources.So it is necessary to monitor and predict the incomingload as well as the involved resource utilization.A web service might be available and unloaded, in
which case the consumer would try to access it with noresponse. This possibly occurs in the case of compositeservices, where the target web service may be dependenton other unavailable or overloaded web services. There-fore, the replication process should consider all web ser-vices either those invoked alone or those involved in acomposition process. Also, it should consider the inter-actions and dependencies among the original web ser-vices and their replicas in addition to the other involvedweb services in the composition process.In this paper, we discuss and develop an adaptive
replication framework for automatically monitoring andreplicating basic or composite web services when theyfail or become overloaded. The suggested frameworkconducts composition by orchestration, where a com-ponent, called the orchestrator, controls the compos-ition activity. The framework adaptively improves theavailability of the published services. It also dynamically
enhances the performance of the running web servicesduring runtime. Furthermore, it predicts the load ofthe main running services. Finally, it provides systemscalability through facilitating the addition of extra webservices or resources as required by the establishedenvironment.The rest of the paper is organized as follows. Section
2 shows the related work. Section 3 introduces a fulldescription of the suggested adaptive replication frame-work. Section 4 explains the workflow of the proposedframework. Section 5 shows Implementation and Per-formance. Finally, conclusion and future work arepresented in section 6.
Related workThe replication process has been classified in severalways according to the involved components and theircharacteristics including requests, replicas and hosts. Forinstance, which QoS parameters should be considered toselect a particular server in order to host a new replicawhen the original web service is failed or being over-loaded. The work in (Salas et al. 2006) partitioned the rep-lication process, with respect to the interaction amongreplicas and requests, into three types: active, passive andsemi-active. In the active type, the consumer broadcastshis/her requests to all available replicas. The one whichmanipulates the request first would respond to that re-quest and interact with the consumer directly. In the pas-sive type, one of the available replicas would be elected tobe the primary replica to communicate with incomingrequests and be responsible for updating all other availablereplicas of the data interchanged and the operationscarried out with the consumers. Another primary replicawill be determined if the original one fails. Unlike theactive and passive types, the semi-active type allows allavailable replicas to process the incoming requests simul-taneously. In the meantime, a master replica is specified tomanage and control the communications among the con-sumers and replicas.The proposed research in (May et al. 2009) studied the
replication process and suggested three other strategies:parallel, serial and composite strategies. The parallel strat-egy works just like the active type in (Salas et al. 2006).However, in the serial strategy, the consumer is notified,by an ordered list, of all available replicas which can ma-nipulate the incoming request as needed. Therefore, theconsumer communicates with the first replica in the de-fined list; if the selected replica fails or does not answerthe request during a certain period of time, the consumerselects the next replica in the list and starts binding withit. Finally, the composite strategy is a combination of thetwo mentioned strategies, aiming to improve the inter-action between the consumers and the available replicas,taking the network traffic status into consideration.
Mohamed et al. SpringerPlus 2013, 2:511 Page 3 of 18http://www.springerplus.com/content/2/1/511
The suggested study in (Zheng and Lyu 2008) expandsthe replication types in (Salas et al. 2006) into nine strat-egies, by considering other constraints including time re-dundancy that might have an impact on the replicationprocess. They can be considered as a combination of theactive and passive replication types. For example, thetime redundancy constraint enables the consumer to tol-erate faults by sending several requests to a specific rep-lica when it encounters failure or overloading till he/sheobtains an answer in a reasonable period of time.In (Liu et al. 2011), a Genetic Algorithm (GA) is pro-
posed to produce a near-optimal replication scheme viaa Directed Acyclic Graph (DAG), which is used to dis-cover all possible replication schemas.In this work, an adaptive replication framework is sug-
gested to allow a consumer to pass requests to a specificreplica in the same way as in the passive replication case.However, when the target replica fails or becomesoverloaded, the framework replicates the original serviceinto another server during runtime and then forwardsthe consumer’s requests to the new replica automatic-ally. Notably, the suggested framework considers onlyreplicating the target services without replicating the in-coming requests.One of the main aims of replication is to provide avail-
ability as discussed in (Wenbing 2007; Liang and Bin2010; Ooi et al. 2012). In addition, it also improves theperformance of the entire system that the different Webservices operate on (Keidl et al. 2003; You et al. 2009;Björkqvist et al. 2012).In paper (Wenbing 2007), a fault tolerant framework is
designed and implemented for managing replication. Thesuggested framework dynamically supports switching be-tween replication and non-replication operation modesdepending on the Web service status and in particular itsavailability and reliability.A framework has been proposed in (Liang and Bin
2010) for accomplishing a changeable-location replica atruntime. Fundamentally, the suggested framework estab-lishes an adaptive re-selection of a higher priority servicewhen the main service or host fails. The service priorityorder is organized based on considering some QoS con-straints including the network availability as well as thehost machine performance, in addition to the executiontime and reliability of the services. The main disadvan-tage of this framework is that it does not consider anyother crucial metrics within the replica re-selectionprocess such as the service or host load.In (Ooi et al. 2012), a dynamic replication framework
is proposed for enhancing the services availability andperformance using a hybrid set of artificial intelligencetechniques including Neural Networks (NN) and Fuzzylogics. A simulation environment to study the suggestedframework with respect to different circumstances such
as placing and removing the involved resources dynam-ically, is presented there. However, the work does notaddress the replication process in a composite serviceenvironment.The framework in (Keidl et al. 2003) is designed to en-
hance the performance of the published Web services.Basically, it studies a dynamic Web service selection andreplication processes at runtime, particularly when thehost becomes unavailable or overloaded. However, itdoes not address the hosts’ selection strategies. More-over, it only replicates the regular or basic services, notthe composite services.The framework suggested in (You et al. 2009) aims to
improve the QoS parameters of the composite servicesby deploying multiple replicas on the idle servers toovercome the main server problems such as failure oroverloading. Two main components have been defined:Longest Delay Service Component Selection (LDCS) forservices failure monitoring and Maximum AvailableCapacity Path (MACP) for investigating the involvedservers. When LDCS detects that a particular service isbottlenecked or overloaded, the framework selects an-other server for hosting a new replica from some specificavailable servers utilizing MACP.The authors in (Björkqvist et al. 2012) introduce a pol-
icy for detecting the number of replicas required foraccomplishing a specific composition process. The pol-icy reduces the operational cost and minimizes the re-sponse time of the running composition applications.The number of required replicas is determined on thebasis of the predicted workload. The main drawback ofthe work proposed in (You et al. 2009; Björkqvist et al.2012) is that both do not discuss the case when the fail-ure occurs on the host side.The work in (Mohamed-K and Mohamed-H 2012) is
similar to the work in (Mohamed et al. 2012); however,instead of using linear aggression for predicting the load,it uses they deployed a generalized time series tech-nique, without providing details about that algorithm.Several researchers restrict the replication management
process to just selecting the optimal web server for hostingthe needed replica, as is the case in (Mehmet et al. 1998;Silva and Mendonca 2004; Björkqvist et al. 2012). Thework in (Mehmet et al. 1998) explains six server selectionalgorithms like Fixed, Ping, Hops, Parallel, Probabilisticand Refresh. The research in (Silva and Mendonca 2004)demonstrates five server selection policies as RandomSelection, Parallel Invocation, HTTPing (or Probe), BestLast, and Best Median. Finally, the authors in (Björkqvistet al. 2012) used two replicas selection algorithms, namelyDistributed Shortest Queue Selection (D-SQ) and Distrib-uted Round Robin Selection (D-RR).The authors in (Marco 2001) classify the sever selection
algorithms into three applied policies: static, statistical,
Mohamed et al. SpringerPlus 2013, 2:511 Page 4 of 18http://www.springerplus.com/content/2/1/511
and dynamic. In the static policy, the server selection isbased on such resource parameters as the number ofhops, connection bandwidth, and server architecture. Thestatistical policy considers the competition among theservers depending on pervious collected performancemetrics such as latencies and bandwidths. Finally, the dy-namic or runtime policy elects the optimal server basedon the current network status in addition to the serverconditions such as server workload and response times. Inthe present paper, we use a similar technique to the lastpolicy dynamic selection algorithm (Marco 2001) in whichthe server selection process is dynamically established dur-ing runtime by considering some QoS parameters such asavailability and performance.
The adaptive replication frameworkThis section explains the main components of the adap-tive replication framework which is structured for hand-ling and managing the basic and composite Webservices running in a SOA environment. In an earlierwork (Mohamed et al. 2012), we proposed and brieflydescribed an adaptive replication framework for dynam-ically replicating a single web service, the basic type,when a service approaches failure or overloading. In thepresent work, the proposed framework is designed formonitoring and replicating the running basic or com-posite web services when it fails or becomes overloaded.In particular, the suggested framework conducts onlythe orchestration composite type in which a compo-nent, the orchestrator, controls the composition processamong a set of s basic web services integrated togetherfor implementing a certain business process. In otherwords, the orchestration composite type would be con-sidered as a generalization of the basic type as there isno mutual dependency among the invoked web servicesin a composite business process.The proposed adaptive framework improves the
availability of the published web services throughreacting to failures on the servers of the consumedservices. The adaptation is realized by automaticallyreplicating the failed services on another server.Then, the incoming requests would be transparentlyredirected to that server. Remarkably, the requests ofa consumer will not be replicated; they will just beforwarded to the free replicas. The framework en-hances the performance of the published services byusing a centralized dynamic load balancing process(Alakeel 2010). The dynamic load balancing processis needed to make request balancing decisions atruntime. And the load balancing process, being cen-tralized, will execute the utilized load balancing algo-rithm, e.g. the Round-Robin algorithm (Silberschatzet al. 2010), as a single service, called Load balancer.For example, if the server that publishes a particular
web service becomes overloaded at some point intime, the suggested replication framework will makethe required decision immediately to replicate thepublished web service on another server and balancethe incoming requests between the original and thecopied services.
The proposed adaptive replication frameworkFigure 1 shows the suggested adaptive replication frame-work. It includes three layers: the clients or Web serviceconsumers, the replication middleware and the serverlayer (Mohamed et al. 2012).The Server layer:
1. The Main Server (MS) is located at the replicationmiddleware layer, and is responsible for managingthe incoming client requests to the consumedservices, and then passing them to the suitablesecondary servers that host the required services.
2. The Secondary Servers (SSs) are located in theServer layer, and are responsible for processing theclient requests and then passing the results to themain server. The number of secondary servers thatprocess client requests is not fixed but changesover the time depending on the current loads.The main server forwards requests to a singlereplica when the original server load is less thana predefined threshold set by the service provider;otherwise it balances the requests between tworeplicas.
The main server componentsA- A number of sensors are used to observe changes thatmight occur in the secondary servers. These sensors are:
1. Failure sensor: checks the status (available or failed)of secondary servers. It sends ping requests to eachsecondary server periodically (typically, every 20seconds). If the server does not respond, the serverstatus will be changed to fail.
2. Performance sensor: collects information about thesecondary servers such as the capacity of memoryand hard disk in addition to the processor type. Inthe secondary server reservation phase, theframework sends automatically two web services toeach secondary server: the first collects capabilityinformation, such as hard disk size, memory sizeand processor type, and the second collects the CPUload on the server.
3. Load sensor: gathers the CPU usage of thesecondary servers periodically (typically, every 20seconds). Like the Failure sensor, it stores theinformation in the Replica_InformationDB databaseas depicted in Figure 1.
Figure 1 The adaptive replication framework.
Mohamed et al. SpringerPlus 2013, 2:511 Page 5 of 18http://www.springerplus.com/content/2/1/511
B- A Selector analyzes the sensors outputs. Con-sequently, it sorts the available Secondary serversdescendingly, from best to worst, according to the fol-lowing performance metrics:
� Server Status, which includes the following twocomponents:
1- Availability: if a failure sensor detects a fault on a
secondary server, the server will be deleted fromthe selection list.
2- Type (Permanent or temporary): a server istemporary if it is, for example, rented or cannotbe used for a specific period of time; otherwisethe server is permanent.
� Server Load, which includes the following threecomponents:1- The current average CPU usage of the available
secondary servers for the last minute. Naturally,low-load servers get a higher rank than heavyload servers.
2- Future load on the available secondary servers,which can be predicated using linear regressionanalysis (Montgomery and Runger 2007). Logically,servers with low predicted loads get a higher rankthan those with heavy predicted loads.
3- Scheduling of secondary servers. Obviously, aserver that has a free schedule is better than onethat does not.
� Server capabilities, which includes the followingcomponent:
1- Capabilities of the secondary servers such as theprocessor type, memory capacity and hard diskcapacity. In our simulation, all secondary servershave the same capabilities, so this factor isignored in the calculations.
The selection process is mainly accomplished by calcu-lating a value equal to the sum of the pervious listed pa-rameters by utilizing Equation 1.
S ¼ Rs þ Rl þ Rc ð1Þ
Where Rs is a number describing the server status(e.g. Available_permanent= 2, Available_rented = 1 andFailed = −1), Rl is a scaling number representing the ser-ver load and Rc is a normalized number identifying theserver capabilities. The server with the highest value isselected first, then the second, and so on.C- Dispatcher: It acts as a mediator between the con-
sumers and the secondary servers; it accomplishes thefollowing roles:
1- Responder: exchanges and organizes message trafficbetween the consumers and Secondary servers.
2- Load balancer: applies the dynamic load balancingprocess (Alakeel 2010), which is basicallyimplemented through executing three stages:Information, Transfer, and Location (Alakeel 2010).The Information stage is for collecting data includingthe running and administration data relating to the
Figure 2 Example of web services composition with orchestration.
Mohamed et al. SpringerPlus 2013, 2:511 Page 6 of 18http://www.springerplus.com/content/2/1/511
deployed SOA environment and that accomplishedvia several sensors such as load, performance, andfailure. The main function of the Transfer stage is totransfer decisions issued when some changes havebeen detected such as a server failure. Finally, the
Figure 3 Example of web services composition with orchestration.
Location stage is assigned for the alternative serversselection process which would be performed based ona hybrid set of QoS metrics, including the serveravailability, performance and load. Finally, it balancesthe load of the incoming requests.
Figure 4 The sequence diagram of the static scenario.
Mohamed et al. SpringerPlus 2013, 2:511 Page 7 of 18http://www.springerplus.com/content/2/1/511
3- Orchestrator: the dispatcher acts as an orchestratoror coordinator in the case of the composite webservices. It controls the communication andinteraction among the WSs constituting a particularbusiness process. For example an orchestratorinvokes WS1, WS2 and WS3, then passes theoutcomes ‘A, B and C’ to WS4 in order to allowWS4 to accomplish its task as seen in Figure 2.
Note that when WS2 which is involved in a specificcomposite process is overloaded, the dispatcher or theOrchestrator, in this case, acts as the Load balancer to
Figure 5 The dispatcher algorithm for a basic web service.
control and distribute the incoming messages among thereplicas shown in Figure 3. More details about the rep-licas management process within the WSs compositecase are given in the following section.D- Replicator: It checks the server availability and
performance, assumed in this work to be every 20seconds. Once it detects that a server stopped work-ing, it replicates the web services files on a secondaryserver automatically. Hence, the load sensor obtainsthe server load periodically, and then the average loadof secondary servers is updated. The replicator checksthis update and also ensures the server availability to
Mohamed et al. SpringerPlus 2013, 2:511 Page 8 of 18http://www.springerplus.com/content/2/1/511
take the appropriate action. Generally, two approacheshave been used to control access to replicated resourceson the Internet: the server side and client side ap-proaches (Silva and Mendonca 2004). The Server sideapproach is utilized in cases where server holding rep-licas are connecting and communicating together phys-ically or under the same administration, as is the case inserver clusters.The second approach basically considers the client’s
characteristics and preferences to access the neededreplicas. Thus, the client side approach is mostly suit-able in cases where replicas are geographically dis-persed. In the adaptive replication framework proposedin the present work, the server side approach is utilizedfor controlling and managing the replication processwhere the clients access the replicas through sendingrequests and receiving responses.E- Cleaner: It examines the usage status of all second-
ary servers and their embedded WSs. In other words, itchecks the secondary servers that have inactive replicaswhich have not received any messages during a certainperiod, assumed to be every 60 seconds. Therefore, itdeletes the inactive web services from the secondaryservers and changes the status of the servers to be “un-used” if it does not have any active replicas.
Workflow of the adaptive replication frameworkThe workflow of the suggested replication frameworkcan be divided into two phases: Reservation andRuntime. The Reservation phase is for collecting
Figure 6 The sequence diagram of the dispatcher scenario.
information about the involved Secondary serversand the running web services. The Runtime phase isfor invoking the replication process during runtimeaccording to particular QoS metrics including per-formance and availability.
ReservationIn this phase, the Main server records and maintains thebasic information about Secondary servers and web ser-vices such as server name and IP in addition to the webservice name and URL.At the beginning, the servers are registered manually
and then monitored dynamically by the failure sensor.Periodically, Equation 1 is recalculated by the selector toupdate the servers’ selection list.
Secondary servers reservationThe server reservation phase includes saving the basicinformation about the available Secondary servers inReplica_InformationDB. The information look likes
� Name, IP addresses, FTP information (i.e. FTPName, username and password). That information isneeded in order to transfer the copied WSs to theselected secondary servers.
� Status (permanent or temporary), and if it is atemporary server, the date and timestamp of therenting period will be registered.
� Schedule list: it registers the date of the possibleactivities that may make a server loaded.
Mohamed et al. SpringerPlus 2013, 2:511 Page 9 of 18http://www.springerplus.com/content/2/1/511
Web service reservationThe Web services reservation phase includes savingthe basic information about the web service on theReplica_InformationDB. The information look likes:
� Web service Name� Initial position of the web service ‘secondary server IP’.� Web service file: it used by replicator when the
master replica fails or becomes overloaded.
RuntimeThere are three scenarios for implementing the replica-tion process:
� Static scenario: there is no replication, only oneservice executes the consumer request.
� Adaptive scenario: in this scenario, the replication isdone automatically when the service fails or overloaded.
� Adaptive with prediction scenario: is the same as theprevious scenario except that it is including theprediction load capability.
Of course, some other scenarios might be locatedbetween the main discussed in this work includingthe regular load balancing scenario. In such a scenario,the servers and the embedded replicas are fixed and the
Figure 7 The dispatcher algorithm for composite web services.
incoming requests are distributed and manipulatedamong them whether the detected load is high or low.In this work, we are only interested in the dynamic en-vironment in which the load, servers and replicaschange periodically.A full comparison between these scenarios is demon-
strated in the Implementation and Performance section.
The static scenarioIn this scenario, the dispatcher determines some server(s)to process the client requests. If the server(s) and thehosted web services are working properly, no action wouldbe taken. Figure 4 explains how this scenario works.
� A client sends a request to the Dispatcher.� The dispatcher forwards the request to the
secondary server(s) for processing.� The secondary server(s) processes the client
requests and sends the response to the Dispatcher.� The dispatcher sends the response back to the client.
The adaptive scenarioThe functionalities of the Dispatcher, Replicator and cleanerwithin the adaptive scenario are demonstrated below.
� A client sends a request to the dispatcher.
Mohamed et al. SpringerPlus 2013, 2:511 Page 10 of 18http://www.springerplus.com/content/2/1/511
� The dispatcher reads the number of replicas andserver IPs used from the Replica_InformationDBdatabase. If the number of replicas is 1, the dispatcherforwards the request to a single secondary server. Ifthere multiple copies of the same service, thedispatcher balances the client request and otherincoming requests between these replicas using theround robin algorithm.
� The Secondary server(s) processes the incomingrequest (s) and sends the response to the dispatcher.Then the dispatcher sends the response back to theclient. The algorithm in Figure 5 shows how thedispatcher works. Also, the sequence diagram inFigure 6 summarizes the main dispatcherfunctionalities.
Figure 8 The replicator algorithm for a basic web service.
As seen in Figure 6, the dispatcher uses the informa-tion stored in Replica_InformationDB to decide when itshould replicate a loaded service and then balance theload between the original service and its replica(s). Thereplicator is the responsible component for specifyingthe replication time, as explained later. In this frame-work, the three components: dispatcher, replicator andcleaner work in parallel.In the case of composite web services, the dispatcher
acts as an orchestrator to coordinate the different web ser-vices that are involved in the WSs composition process.First, the orchestrator reads the information availableabout all the WSs registered in Replica_InformationDB.Second, it calls and collects the outputs from WSs asshown in Figure 2. Finally, it forwards these outputs to a
Figure 9 The sequence diagram of the replicator scenario.
Mohamed et al. SpringerPlus 2013, 2:511 Page 11 of 18http://www.springerplus.com/content/2/1/511
specific WS in order to accomplish its task. The algorithmin Figure 7 formalizes the preceding steps.The replicator checks the used secondary server(s) every
20 sec. If the secondary server fails, the replicator calls theselector to choose the best available secondary server (s).Then it replicates the original web service on the selectedserver(s). Also, it updates Replica_InformationDB by thewriting the new IP address of replica(s).The algorithm in Figure 8 formalizes how the replica-
tor works. Also, the sequence diagram in Figure 9 sum-marizes the main replicator functionalities.In the composition case, the replicator checks the
availability and performance of the WSs involved in
Figure 10 The replicator algorithm for composite web services.
implementing the composition process. It should benoted that in the orchestration composite case, none ofthe involved WSs calls any of the others. However, theOrchestrator is the component which manages thecommunications among those WSs and consequentlytheir replicas as well. In other words, the invoked webservices are fully operated and controlled through a re-lationship loosely coupled with the central Orchestrator.The orchestration composite replication in this case
would be considered repetition n times of the Basic rep-lication process with respect to the n loaded or failedWSs embedded in establishing the orchestration com-posite case as shown in Figure 10.
Figure 11 The cleaner algorithm for basic web services.
Mohamed et al. SpringerPlus 2013, 2:511 Page 12 of 18http://www.springerplus.com/content/2/1/511
After checking the status (i.e. active or inactive) ofthe existing replicas, the cleaner removes all un-needed replicas. The inactive replica is the WS thathas no longer in call by the consumer or any othercomponents. To investigate that, the following state-ment is applied:IF currentTime > LastUpdateOfServerIP + ProcessingTimeTHEN Replica_Status = InactiveElse Replica_Status = ActiveWhere LastUpdateOfServerIP is the last time in which
the Replicator changes the status of the host server forthat replica from ‘used’ to ‘unused’. The ProcessingTimeis the period needed by the host server to process con-sumers’ requests.The algorithm in Figure 11 formalizes how the clean-
er works in basic web services case. Also, the sequencediagram in Figure 12 summarizes the main cleanerfunctionalities.
Figure 12 The sequence diagram of the Cleaner scenario.
In the composition case, the cleaner deletes all inactivereplicas ‘WSs’ involved in the composition process. Thealgorithm in Figure 13 shows the steps that the cleanerfollows to delete the inactive replicas within the compos-ition case.
Adaptive with load prediction scenarioIn this scenario, the dispatcher, selector and cleanermechanisms for basic and composite WSs work asexplained in the adaptive scenario. However, a predic-tion utility is added to the replicator in order to predictthe incoming load in a specific day using the followingfactors:
� Linear regression can be used to explain the relationbetween x (the load of the current day) and y (theload of the next day) by using Equations 2, 3 and 4.Notably, it might be known that the server load
Figure 13 The cleaner algorithm for composite web services.
Mohamed et al. SpringerPlus 2013, 2:511 Page 13 of 18http://www.springerplus.com/content/2/1/511
follows a nonlinear statistical model (Montgomeryand Runger 2007).
β1 ¼ ∑ixi−�xð Þ yi−�yð Þ=∑
ixi−�xð Þ2 ð2Þ
β0 ¼ �y þ β1�x ð3Þy ¼ β0 þ β1
1x
� �þ ε ð4Þ
Where �x and �y denote average. These equations willbe verified by an example in the following section. Thealgorithm in Figure 14 demonstrates the way in whichthe replicator works.
Figure 14 The replicator algorithm for basic web services.
Implementation and performanceIn (Mohamed et al. 2012), we introduced a case study fordemonstrating the Basic replication workflow. Hence, itwould be worthy to only focus here on the scenario of theComposite WSs replication. In this section, we will discussa case study for showing the Composite replication work-flow in order to evaluate the proposed framework.The composite replication case study is described as
follows. In our University, at the beginning of eachacademic year, the students often access the Universityhome page, hence the interconnected University servers,to know whether they have been accepted in the
Figure 15 The orchestrated composite dormitories web services.
Mohamed et al. SpringerPlus 2013, 2:511 Page 14 of 18http://www.springerplus.com/content/2/1/511
dormitories. A student is accepted if and only if he/shesatisfies the following conditions:
� The grade in the previous year must be C or higher.� The tuition fees have been fully paid.� The medical examination shows no infectious
diseases.
In this scenario, at least three different web services arerunning to handle the above conditions; they are deployedon different web servers which are established as follows:
� The academic server located in each faculty wherethe student registered. This server managesregulations A and B through a published web servicenamed ‘academic_WS’.
� The medical server located inside the Universityhospital in which the student establishes his annualmedical examination. This server conducts
Figure 16 The orchestrated composite dormitories web services with
regulation C by a particular web service called‘medical_WS’.
� The Dormitories server located in the mainUniversity Dormitory in which the previousregulations (A, B and C) are passing to in order tocheck the acceptance status of each registeredstudent through consuming the Dormitories webservice defined as ‘Dormitories_ws’.
The University server is responsible for controllingand monitoring the interaction among the previouslymentioned servers as depicted in Figure 15.Each student is usually asked to submit his/her national
ID or University ID, and then a specific data verificationprocess will be accomplished through the suggestedreplication framework. First, the dispatcher invokes the‘academic_WS’ to check the status of regulations A and B;the tuition fees and academic report of each registeredstudent. Then, the dispatcher calls the ‘Medical_WS’ to
a replica.
Table 1 The history average load of the target academic server
Mohamed et al. SpringerPlus 2013, 2:511 Page 15 of 18http://www.springerplus.com/content/2/1/511
verify regulation C, the student health report. Then, thedispatcher passes all outcomes of the running web servicesto the ‘Dormitories_WS’ in order to determine whether thestudent would be accepted or rejected.In the Static scenario ‘without Replication’: If any of
the published web services, such as ‘academic_WS’, or ofthe host servers, such as the academic servers fails, thestudent will not get a response. Furthermore, if any ofthe host servers is overloaded, the student has to waitlonger to get a response because, in that case, no loadbalancing technique is supported.The Adaptive Replication scenario: The University ser-
ver manages the web services replication process. If itdetects the failure of a web service or a host server,the framework automatically replicates the consumedservice on another server (i.e. a Secondary server) lo-cated inside the University campus based upon certainService-Level Agreements (SLAs) including their per-formance and availability. Moreover, if the Universityserver detects the overloading of a web service or hostserver, the framework automatically replicates the con-sumed service on another server then uses the RoundRobin load balancing algorithm (Silberschatz et al. 2010)to balance the requests on the replicas.Adaptive with a load prediction scenario: Adding to the
previous case, a prediction utility using linear regression isemployed in order to save the replica deployment time. Inthis experiment, we assume that the academic server isoverloaded by the incoming requests, so the replicatortransfers the academic_WS to another academic serverlocated in the University campus (i.e. located in anotherfaculty inside the campus) and balances the incoming re-quests between the two servers as shown in Figure 16.
Table 2 The load prediction calculation of the target academ
x y xy x2 y2
1 62 80 4960 3844 6400
2 50 45 2250 2500 2025
3 72 52 3744 5184 2704
4 39 67 2613 1521 4489
5 69 55 3795 4761 3025
6 50 85 4250 2500 7225
7 45 30 1350 2025 900
Total 387 414 22962 22335 26768
The following example explains how the server loadprediction works. The Load sensor collects the historicaldata about the load of all available servers in the cam-pus, for two weeks. This data is saved in a particulardatabase virtualized as a queue that is updated daily,with the newest value added at the tail of the queue andthe oldest value removed from the head (As a shiftingprocess). This shown in Table 1, where the odd days(i.e. 1st, 3rd May and… etc.) are expressed as x with re-spect to the mentioned equations in Section 4 and theeven days (i.e. 2nd, 4th May and… etc.) are presented asy with respect to the same equations in Section 4.If the load of the target academic server for the day
comes directly after the two monitored weeks (i.e. Satur-day, May 15th) it is measured and expressed as x= 60 re-quests then the predicted load of the academic serverfor the day after (i.e. May 16th) which is presented as yas will be calculated.Remarkably, we assume the load will be predicted daily
because it is more suitable for our case study. For ex-ample, at the beginning of the academic year, theDormitories server will understandably become over-loaded during the entire day.Table 2 involves the needed values to calculate β1, β0
and y as explained in section 4.3 using the Equations 2-4
β1 ¼ :074
β0 ¼ 54:8
y ¼ 54:8þ :074=60 ¼ 54:8
The following experiments were conducted to evaluatethe performance of the framework using the previousscenarios (static, adaptive and adaptive with load
Mohamed et al. SpringerPlus 2013, 2:511 Page 16 of 18http://www.springerplus.com/content/2/1/511
prediction). The test environment in VMware simulationconsists of 6 servers: 1 MS, 5 SSs and 1 DNS. The DNSserver is used also as a secondary server. The capabilitiesof these servers are established in Table 3. All suggestedsecondary servers are academic servers running insidethe University.The experiments were conducted using ApacheBench
Version 2.0.40-dev <$Revision: 1.146 $>apache-2.0 bypassing parameter such as:
� The number of requests that are passed to theUniversity web page. In this experiment, therequests are passed to the dispatcher component,which is located on the University server.
� The concurrency level is the number of concurrentrequests passed to the web page at the same time.For example, if we want to run 1000 requests andthe concurrency level is 10, then the requests will besent over 100 times. Of course, there is positivecorrelation between concurrency level and serverload, in the sense that when the concurrency levelincreases, the server load also increases.
Figure 17 The response time of running 1500 requests.
� The web page URL required for testing ‘Dispatcherweb page’.
� Number of periods required to be tested and thetime in seconds between these periods.
The experiment is accomplished by passing a number ofrequests equal to (150, 300, 450 and 600) representing thenumber of target students who would like to submit inDormitories. Also passed are their concurrency levels (1,3, 6, 9 and 12) indicating the number of students who sub-mit their requests simultaneously. Then, the response timeand throughput are calculated at each concurrency level.At level 1, say, the response time is calculated by summingthe response time values resulting from passing (150, 300,450 and 600(. At the other levels the response time will becalculated similarly.Figure 17 demonstrates the charts for the above experi-
ment with the three different scenarios: static, adaptive andadaptive with prediction. As shown in Figure 17, the con-currency levels (1and 3) reflect the low load of requests, theconcurrency level (6) reflects the average load of requests,and also (9 and 12) reflect the high load of requests; de-pending on the used server capabilities.The performance order of the previous approaches
shown in Figures 17 and 18 from best to worst is adap-tive with load prediction property, adaptive replicationand static approaches. Note that when the concurrencylevel is increased above 3 requests per second “low loadcase”, the gap between static and adaptive is increased,whereas the gap between adaptive and adaptive withprediction is decreased. When the concurrency levelequals 1, i.e. a request passing at a time, the response
Mohamed et al. SpringerPlus 2013, 2:511 Page 17 of 18http://www.springerplus.com/content/2/1/511
time and throughput of the three techniques approachthe same value. In this case, there is no need to balancethe incoming requests and typically the adaptive sce-nario would act as the static one by forwarding requeststo a single replica.If the concurrency level is 3 or 6, the adaptive replication
technique pass more requests to a single replica, so that theaverage load takes longer time to reach to the threshed (as-sumed 75%). Thus, it becomes nearer to static and far fromadaptive with load prediction property.When the concurrency level is 9 or 12, the adaptive
replication technique balances the requests on the tworeplicas because the average load reaches the threshedquickly (75%). So it becomes nearer to adaptive withload prediction property and far from static approach.
Conclusions and future workIn this paper, an adaptive replication framework for basicand composite web services is introduced and described.The framework aims to improve the web services avail-ability. It also minimizes the response time throughsupporting an adaptive replication of the consumed webservices, considering the environment changes thatmight occur at the service provider side such as failureor overloading. In particular, the suggested frameworkstudies the orchestration composite type through man-aging the interconnection among some regular web ser-vices and replicates the poorly-operated service.Moreover, the framework includes a particular utility
for predicting the future load on the servers hosting theoriginal copies of the web services. The prediction helps
Figure 18 The throughput of running 1500 requests.
decrease the time of outsourcing the replicas on otheravailable servers.A case study of accomplishing the replication process
for an orchestrated composite web service is presented.The associated experiments study the proposed frame-work in three different scenarios: static ‘without replica-tion’, adaptive and adaptive with load predictionproperty, and measure the response time and through-put. The shown outcomes prove that the frameworkoperates most efficiently when it runs with the adaptivewith prediction property mode.For the future, we plan to apply the adaptive repli-
cation framework on choreographically composite webservices, where no central component controls the inter-action between Web services, but rather the Web ex-changes messages directly among them.Furthermore, we aim to apply a partially adaptive rep-
lication over the published coarse granular web services,where a service encapsulates different business processesor operations. We believe that it would be better to rep-licate the service operations which often have a highload in the form of a standalone web service to guaran-tee the privacy of the main service as well as to enhancethe interoperability and granularity of the composite ser-vice processMoreover, we plan to utilize other prediction load algo-
rithms by accomplishing another robust statistical predic-tion technique for managing properly all types of data sets,including linear and nonlinear sets. Likewise, we are willingto improve the server selection techniques through consid-ering the consumer requirement preferences.
Mohamed et al. SpringerPlus 2013, 2:511 Page 18 of 18http://www.springerplus.com/content/2/1/511
Finally, we plan to apply the adaptive replication onanother distributed system including a cloud computingplatform.
Competing interestsThe authors have no competing interests.
Authors’ contributionsMFM constructed and implemented the proposed framework as well aswrote the preliminary version of the manuscript. HFE enhanced the structureof the suggested framework, supervised and reviewed the implementationprocess and wrote the final version of the manuscript. HMN reviewed anddrafted the final version of the manuscript. All authors read and approvedthe final manuscript.
Author details1Computer Science Department, Faculty of Computers and Informatics, SuezCanal University, 41522, Ismailia, Egypt. 2Electrical and Computer EngineeringDepartment, Beirut Arab University, Beirut, Lebanon.
Received: 14 April 2013 Accepted: 1 October 2013Published: 5 October 2013
ReferencesAbdaldhem A, Patrik F, Jacques P (2009) Web services orchestration and
composition: case study of web services composition. Internal workingpaper; Department of Informatics, University of Fribourg, Fribourg, Canton ofFribourg, Switzerland
Alakeel AM (2010) A guide to dynamic load balancing in distributed computersystems. International Journal of Computer Science and Network Security(IJCSNS) 10(6):153–160
Albert Napier H, Rivers ON, Wagner SW, Napier JB (2005) Creating a winningE-business (2nd edition). Course Technology
Björkqvist M, Chen LY, Binder W (2012) Dynamic replication in service-orientedsystems, 12th IEEE/ACM international symposium on cluster, cloud and gridcomputing. Ottawa, Canada
Keidl M, Seltzsam S, Kemper A (2003) Reliable web service execution anddeployment in dynamic environments, In 4thInternational workshop ontechnologies for E-services (TES). Springer, Germany, Berlin
Len B, Paul C, Rick K (2003) Software architecture in practice (2nd edition).Addison-Wesley Professional, United States
Liang G, Bin Z (2010) A modeling approach on self-adaptive composite services.In: International conference on multimedia information networking andsecurity. Nanjing, Jiangsu China
Liu A, Li Q, Huang L (2011) Quality driven web services replication using directedacyclic graph coding, In WISE’11 proceedings of the 12th internationalconference on web information system engineering. Springer-Verlag Berlin,Heidelberg
Maamar Z, Sheng QZ, Benslimane D (2008) Sustaining web services high-availability using communities: the third international conference onavailability. Reliability and Security, Barcelona
Marco B (2001) A simulation analysis of dynamic server selection algorithms forreplicated web services. In: proc. of the 9th int. symp. on modeling, analysisand simulation of computer and telecommunication systems (MASCOTS2001). IEEE-CS Press, Cincinnati, OH
May NR, Schmidt HW, Thomas IE (2009) Service redundancy strategies in service-oriented architectures: in software engineering and advanced application.IEEE Comp. Soc, Patras, Greece
Mehmet S, Yuri B, Peter S, Radek V (1998) Selection algorithms for replicated webservers. In Proc. of the Workshop on Internet Server Performance,SIGMETRICS, USA
Mohamed MF, El Yamany HF, Hussien MK, Yhiea NM, Nassar HM (2012) Anadaptive replication framework for improving the QoS of web services.CLOSER 2012 - 2nd international conference on cloud computing andservices science, Portugal
Mohamed-K H, Mohamed-H M (2012) A framework for adaptive QoS of webservices using replication. International Journal of Computer Science &Communication Networks 2(2):288–294
Montgomery DC, Runger GC (2007) Applied statistics and probability forengineers(4th edition). John Wiley & Sons, Inc., USA
Ooi B-Y, Chan H-Y, Cheah Y-N (2012) Dynamic service placement and replicationframework to enhance service availability using team formation algorithm.Journal of systems and Software 85(9):2048–2062
Papazoglou M (2007) Web services: principles and technology. Pearson EducationLimited, England
Salas J, Perez-sorrosal F, Patiño-martínez M, Jiménez-peris R (2006) WS-replication:a framework for highly available web services, In 15th internationalconference on the world wide web. Edinburgh, Scotland
Silberschatz A, Galvin P, Gagne G (2010) Operating system concepts (8th edition).John Wiley & Sons, Asia
Silva JA, Mendonca ND (2004) Dynamic invocation of replicated web services. In:In the proceedings of the WebMedia & LA-web 2004 joint conference 10thBrazilian symposium on multimedia and the web 2nd latin American webcongress (LA-webmedia’04). Ribeirao, Preto, Brazil
Thomas E (2005) Service-oriented architecture (SOA): concepts, technology, anddesign. Prentice Hall, United States
W3C Working Group Note (2003) QoS for web services: requirements andpossible approaches. http://www.w3c.or.kr/kr-office/TR/2003/ws-qos/.Accessed September 28, 2012
Wenbing Z (2007) A lightweight fault tolerance framework for web services, Inweb intelligence. IEEE Comp. Soc, Fremont, CA
You K, Qian Z, Tang B, Lu S, Chen D (2009) Qos-aware replication in servicecomposition. International Journal of Software and Informatics 3(4):465–482
Zheng Z, Lyu MR (2008) A distributed replication strategy evaluation andselection framework for fault tolerant web services: in IEEE internationalconference on web services. Beijing, China
doi:10.1186/2193-1801-2-511Cite this article as: Mohamed et al.: A study of an adaptive replicationframework for orchestrated composite web services. SpringerPlus2013 2:511.
Submit your manuscript to a journal and benefi t from:
