Abstract

This paper is concerned with the dynamic evolution analysis and quantitative measurement of primary factors that cause service inconsistency in service-oriented distributed simulation applications (SODSA). Traditional methods are mostly qualitative and empirical, and they do not consider the dynamic disturbances among factors in service’s evolution behaviors such as producing, publishing, calling, and maintenance. Moreover, SODSA are rapidly evolving in terms of large-scale, reusable, compositional, pervasive, and flexible features, which presents difficulties in the usage of traditional analysis methods. To resolve these problems, a novel dynamic evolution model extended hierarchical service-finite state automata (EHS-FSA) is constructed based on finite state automata (FSA), which formally depict overall changing processes of service consistency states. And also the service consistency evolution algorithms (SCEAs) based on EHS-FSA are developed to quantitatively assess these impact factors. Experimental results show that the bad reusability (17.93% on average) is the biggest influential factor, the noncomposition of atomic services (13.12%) is the second biggest one, and the service version’s confusion (1.2%) is the smallest one. Compared with previous qualitative analysis, SCEAs present good effectiveness and feasibility. This research can guide the engineers of service consistency technologies toward obtaining a higher level of consistency in SODSA.

1. Introduction

In recent years, service-oriented distributed simulations applications (SODSA) have become a major trend in modeling and simulation (M&S) field [1] mainly because of the enormous popularity of novel information technologies such as service-oriented architecture (SOA) [2], compositional simulation methods [3], cloud computing [4], internet of things [5], gridding, and Web service applications [1, 6, 7]. Owing to the usage of such technologies, SODSA is increasingly featured by service-oriented, composite, large-scale, ubiquitous, and flexible characteristics [8, 9]. For this reason, in order to ensure service consistency, traditional maintenance technologies which do not consider these novel attributes of SODSA exhibit some new difficulties (e.g., bad reusability, troubles of service composition, failures of service encapsulation and messages exchanges). It should be noted, however, that service consistency maintenance plays a critical role in the correctness and reliability of M&S. Therefore, it is crucial for software developers to make use of feasible technologies and methods to maintain service consistency. But prior to this step, we should first analyze the various influential factors that cause service inconsistencies, serving as guidance for the design of service consistency technologies with regard to a specific inconsistent factor. Traditional methods are mostly qualitative and experiential, and they do not consider the dynamic disturbances among factors in service’s evolution behaviors such as producing, publishing, calling, and maintenance. Moreover, SODSA are rapidly evolving in terms of large-scale, reusable, composite, pervasive, and flexible features, which presents difficulties in the usage of traditional analysis methods. To solve these problems, the main contributions of this paper are summarized as follows.(i)We present a new service consistency evolution model, called extended hierarchical service-finite state automata (EHS-FSA), which is based on FSA theory and considers the dynamic disturbances among main inconsistency factors and simulates all transition behaviors and states of combined consistency attributes sets for each simulation service.(ii)On the basis of EHS-FSA, we also develop two service consistency evolution algorithms (SCEAs) by running EHS-FSA and then calculating the number of factors occurrences affecting service inconsistency, which provides the quantitative analysis means of impact factors.(iii)We carry out quantitative evaluation experiments to validate the feasibility and effectiveness of the service evolution model EHS-FSA and the statistical assessment algorithms SCEAs.

As a brief outline of the rest of the paper, Section 2 discusses the background and mechanism of service consistency evolution; Section 3 introduces the service consistency evolution model, including essential formal definitions and EHS-FSA; Section 4 proposes SCEAs and states their main principles; Section 5 gives the quantitative evaluation results and analysis of influencing factors by simulation methods; conclusion and the recommendations for future work are detailed in Section 6.

Over the years, many maintenance techniques have been proposed in prior related studies to maintain all kinds of consistency states and ensure convenient utility of services in service evolution processes from the different emphasis points. Tian et al. [10] consider the software service reuse issues in ubiquitous environments and present a novel reuse approach in service consistency evolution processes, in which the reusable parts of existing services are extracted and directly utilized, and the missing functionalities-based index is then further implemented and built to accelerate the service reuse process. Sindhgatta and Sengupta [11] investigate the model transformation processes and the associated changing service design method in model-based development of SOA and introduce an extensible framework for tracing the dynamic evolution of model and model-based service. Frank and Karl [12] state consistency challenges of service discovery in mobile ad hoc networks and discuss the influencing factors on system efficiency that refers to transmission protocol, correctness of the delivered messages, message overhead, and even geographic distance between service providers and subscribers. Greenfield et al. [13] study the consistency maintenance problems of Web services, ensuring that services calls always be finished in consistent states despite failures and other exceptional events. Reference [13] addresses the relationship between internal service states, messages, and application protocols which facilitate the transformation from the problem of ensuring consistent outcomes into a protocol problem that can be easily validated by established service verification tools. There is also a great deal of other research achievements of service consistency evolution such as the studies in literatures [5, 1418] that analyse the challenges and troubles and give some significative solutions. However, these solutions are usually adopted in such simulation environments where the number of simulation nodes is fixed and service developments are centralized and inflexible. With the emergence of SODSA, some new traits of software service developments are emerging, leading to traditional analysis methods being less applicable.

As for the above-mentioned former literatures [5, 1418] that investigate service consistency in traditional distributed simulations compared with SODSA, there exhibit the following deficiencies in analyzing these influencing factors. (1) Only one or some of these factors are discussed, rather than most of enabled influential factors. (2) These studies only explain why these factors lead to service inconsistency, but do not specify the numerical extent which results in such inconsistent phenomena. (3) Dynamic perturbation mechanism between inconsistent factors in service running and their dynamically impact on all possible transitions of service consistency states are disregarded. (4) Existing researches focus mainly on inconsistency factors in special simulation phases or processes and do not synthetically investigate the issues that affect the overall software life cycle. Thanks to some major features of emerging SODSA such as large-scale attributes, dynamic assemblage, redundancy deployment, plug-in procedures, and flexible composition, the simulation nodes in SODSA are transformable, unpredictable, and therefore stochastic. These traits result in an increasingly unreliable and large number of services. Thus, the dynamic evolution mechanism of impact factors on service inconsistency should be exhaustively investigated, and inconsistent details in each simulation service should be carefully monitored in the whole simulation course. By using this analysis way, we can provide an actual and exact picture of the importance of such factors and can enable the excellent design of technologies for maintaining service consistency when it comes to the influencing factors, which facilitate the avoidance of wrong simulation results. When software engineers take into account all influencing factors in such complicated and dynamic simulation environments, they certainly encounter some difficulties in actual analysis, design, and running of service. In this paper, thus, we restrict the analysis to focus on some important inconsistency factors and temporarily ignore secondary ones.

Emerging automata theories [19], graph-based approaches [20], and formal methods [21] in software engineering supply many valuable solutions for describing and analyzing such complicated state changes and interactive behaviors in distributed systems, which provide us with constructive ideas. In particular, a finite state automaton (FSA) [22] has been widely used in the analysis and behavior modeling for various practical moderate-scale systems. However, in large-scale complex distributed systems, as it involves the complexity of sizes, behaviors, states, and properties, a general FSA is not easy to be used to formally describe such systems. The extended hierarchical FSA (EHFSA) [23] that lets a state itself as an FSA and can depict complex state transitions is deepening and an expansion of FSA, avoiding the state space explosion and improving the efficiency of state transition. Considering the multifarious consistency evolution behaviors of atomic and composite services in large-scale SODSA, as well as the layered distribution of service grid, it is feasible that we use EHFSA to describe the consistency state evolution of service behaviors under compositional SODSA. In order to obtain quantitative analysis results, we also design two statistical evaluation algorithms to detect impact factors of service inconsistency.

3. Analysis of Service Consistency Evolution

3.1. Evolution Mechanism

Considering the actual situations in current SODSA, it is rare that there always exists an appropriate service exactly satisfying the user requirements. Because the popular tendencies of SODSA are that service evolution caters to continually changing requirements and services are dynamically combinated and rapidly updated. Hence, some macrolevel factor refers to service inconsistency, such as the diversity of service behaviors, the complex structures of the service itself, and the service’s function overlap, can be observed in service-oriented simulations, which are the focus of service evolution in this research. Based on the above-mentioned factors, we mainly pay attention to the global consistency state evolution of services, monitoring the service state transition triggered by the impact factors, investigating the occurrence mechanism of inconsistent phenomena, and counting the influence rates of these factors.

In this paper, according to the evolution direction of services, the service consistency evolution can be divided into two categories: horizontal and vertical. Horizontal evolution refers to the internal consistency state changes for the same version of services and vertical evolution refers to service consistency problems between the same service’s different versions. For each single service, we can describe its evolution processes by a three-dimensional view as shown in Figure 1. Additionally, the events of service evolution also can be summarized into two types: essential (ES) and nonessential (NES), on the basis of the product life cycle of service. The ES-events include service composition (SC), interface description (ID), Web encapsulation (WE), and version management (VM), referring to the processes of service’s production and maintenance, whereas the NES-events such as redundant storage (RS), message interaction (MI), search and matching (SM), and share and reusage (SR) refer to the service’s application processes. These events are the important elements of services’ consistency state evolution. Table 1 shows the detailed events or factors of service consistency evolution.

3.2. Inconsistency Factors

In this section some formal method-based concepts for modeling are first introduced. A service consistency evolution model EHS-FSA is then proposed based on FSA. The representation of Section 3.1 indicates that the consistency state of service evolution can be analyzed from macroscopical factors based on structures, behaviors, and functions of service, which consist of service interface protocols (structure), storage deployment (structure), service production and maintenance (behavior), message communication (behavior), share and reusage (function), matching between service publishers and subscribers (function), and other ones. For example, the failures of message interactions among different services can prevent service running due to the network delay, package loss, hardware or software troubles, different service may have a diversity of description styles such as HTTP, SOAP, WSDL, and XML [24], which makes services’ calls and compositions more difficult.

In fact, service composition is very significant in SODSA. It means that one single service can be composed of different atomic services, in which the atomic service is function-simple and relatively independent, but this combinative service has a larger granularity and more applications [25]. The composition among different services can provide some value-added functions and meet the subscribers’ requirements [25]. However, owing to the heterogeneous, distributed, and dynamic network environment, the service composition is affected by changes in communication mode, network block, denial attacks of service, infrastructure failures, and other issues [24], making the compositional behaviors of service not easy.

Note that the occurrence of any inconsistency factors in software engineering must have certain statistical regularity and these factors causing service inconsistency are no exception. Exactly speaking, the factors’ importance degree should have a certain ordinal and numerical relationship, for instance, which factor is the least influential factor?, which factor is the most influential?, and what are the impact proportions of these factors?, respectively. Our main target in this paper is solving these problems by using formal method and FSA theory.

4. Consistency Evolution Model

In this section some formal method-based concepts for modeling are first introduced. A service consistency evolution model EHS-FSA is then proposed based on FSA.

4.1. Definitions and Notations

We first define related concepts which are the background knowledge of proposed EHS-FSA method and its algorithm for factors quantification analysis.

Definition 1 (atomic service). We define as the set of atomic services. (abbreviated as ) is the smallest service unit in SODSA, which encapsulates several models into one kind of web service and can only complete a simple task.

Definition 2 (composite service). Several atomic services can be appropriately assembled into a larger granular service. Let denote the set of compositional services where (abbreviated as ) is a -tuple meaning the composite array and denotes the number of .
We assume that a single that can be used to establish many is the basic service unit and some service activities such as publishing, accessing, and calling can be executed only after the happen of ’s composition behavior.

Definition 3 (global service space). We define a logically transparent space which consists of all and in SODSA system. For GSS, and in different physical nodes logically belong to the same node. That is, the service is transparent and seems to be deployed locally, although actually saved at geographically dispersed regions.
According to Definition 3, GSS is like a container in which each service interaction can be done locally and there donot exist the remote accesses and calls, and all service-related consistency state evolutions can be executed in GSS.
Assume that can no longer be integrated into a higher level of service with other after several are assembled into it. That is, there are only two types of service in SODSA: and , indicating the number of service layer is 2.

Figure 2 shows a simple example of ’s behaviors of composition and reusage and ’s message exchanges in GSS. In Figure 2, symbol “①” denotes the combination of different , symbol “②” denotes message interactions between two business-related , and symbol “③” denotes the migration of , meaning the atomic services’ share and reusage.

To simplify the problems and easily achieve formal descriptions, we consider only dominating influential events (or factors) on consistency state of services. These events include SC, WE, ID, SR, MI, and VM (as shown in Table 1).

Definition 4 (consistency attributes of AtS). Let a three-tuple denote the consistency-related properties set of in GSS. The elements in correspond to the before-mentioned events VM, WE, and SR, respectively, which should be carefully considered in maintaining the consistency state of .

Definition 5 (consistency attributes of CoS). In GSS, use a four-tuple to denote ’s consistency attributes set, where , is the number of current in corresponding , denotes the factor ID’s consistency state, represents the factor MI’s correctness, denotes the composition capability of the factor SC.
Seen as Definition 4, we can observe that all attributes of are included in relevant attributes but are just a subset of . Therefore, the consistency attributes of can be divided into two levels: atomic layer and compositional layer. There are multiple and in GSS.

Definition 6 (consistency state array of AtS). For all , use the state array (abbreviated as ) to denote the monitoring values of atomic service ’s consistency status where is the simulation time, the elements , , and whose range is , respectively, mapped the events VM, WE, and SR in . The logic term “true” denotes consistency, whereas “false” denotes inconsistency.

Definition 7 (consistency state array of CoS). Let the composited state array (abbreviated as ) denote ’s monitor value of consistency states at any where is called the root array, and is called the leaf array. The monitor values in whose range is uniform to that in Definition 6 mapped the attributes in , respectively.
According to Definitions 6 and 7, and can quantitatively describe the consistency states of services. In the running of SODSA, we can use them for each and to monitor service state changes. Note that each and in GSS have eight such state arrays ().
Give an example of consistency state arrays: at , assume that the state arrays of are , , and . If is integrated with to produce and is composed of and , then we have the state arrays of and .

Definition 8 (input events set of service states). Considering several primary consistency factors of and , we define the input events set of service states , , and where and are, respectively, the input set of state transition of and . The element in refers to the following factors: version management confusion (), encapsulation troubles (), hard reusability (), version maintenance (), encapsulation repair (), and reusability improvement (). Similarly, refers to these factors: different interface description (), message communication failure (), ’s noncomposition (), standardization of interface definition (), successful message transmission (), and ’s composability amendment ().

Definition 9 (output events set of service states). The consistency state transition of services can be triggered by input events, resulting in the output events whose set is denoted by , , . and are the output set of state transition of and , respectively. For each , we define the following output events of : version inconsistency (), ’s internal inconsistency (), nonreusability (), version consistency (), encapsulation correctness (), good reusability (). For each , involving the following ’s output events: inconsistent interface (), message exchanges inconsistency (), composition inconsistency (), interface consistency (), message interaction consistency (), and composition consistency ().

4.2. Extended Hierarchical Service-Finite State Automata

In this section, we construct an extended and hierarchical FSA to portray the dynamic evolution mechanism of service consistency states in SODSA.

Definition 10 (extended hierarchical service-finite state automata, EHS-FSA). We define service consistency evolution as a set of extended FSA, which is formally denoted by . is an extended FSA represented by the nine-tuple , where:(i) and denote the finite and nonempty set of consistency states of and in , respectively,(ii) and are the sets of all state arrays of initial and , respectively,(iii) and denote the finite and nonempty set of service state transition’s input events and output ones, respectively,(iv) represents the rule set of state transition of service consistency, that is the changes of state arrays and triggered by from the interval to ,(v) is the state transition function of service evolution,(vi) is the output event function.
In EHS-FSA, we have such transition functions , , and so on. To simplify the transition rule, we assume that there only exists one input event in and one output event in for each state transition. According to Definition 10, there are partial state transition details for each as shown in Table 2.

Figure 3 gives an illustrated way to portray ’s state transition processes, in which the rule denotes the input event and output event for each ’s state change, is the current system time, and the symbol “” represents the service state’s evolution behavior. For example, the state array evolves into triggered by the rule . Similarly, there are the similar state transition courses of root arrays in .

Definition 11 (states transition matrix of ). We define the following transition matrix: where , (), denotes the number of all states, and denotes the amount of ’s state input events that are listed by the sequence in . If the transition function does not exist, in is represented by 0; contrarily, the state arrays , , , , , , and are, respectively, denoted by the values 1, 2, 3, 4, 5, 6, 7, and 8 in .
We can find that the number of ’s actual states is 8 and the number of events is 6. Hence, the actual can be obtained as follows:
It can be observed that the contents of matrix are consistent with those of in Table 2. Similarly, we can define the state transition matrix of ’s root arrays as .

Definition 12 (occurrence probability of event set ). We use and to denote the occurrence probability of events and in respectively. In our model, assume that , , and ; similarly, , , , and .
In general, the majority of and are difficult to be reused and combined, due to the heterogeneity of distributed systems and the diversity of modeling methods and tools and the knowledge differences in different application fields in SODSA. Therefore, the events and will become the very frequent activities. In addition to developing some new services, the events and also will occur usually when fusing the functions and applications in previous and old simulation systems into the new SODSA. From the statistical point of view, the operation running of software systems is basically stable, so the events and will occur occasionally.
On the basis of the above-mentioned actual situations, we assume that the occurrence probabilities of will satisfy the following constraints in the dynamic evolution processes of EHS-FSA: , , , and .

5. Service Consistency Evolution Algorithms

In this section, two algorithms SCEA- and SCEA- to monitor service consistency transition activities are constructed, which focus on the occurrence of impact factors in SODSA on the foundation of executing EHS-FSA. Both SCEAs achieve a dynamic analysis of the influencing factors that lead to inconsistency of and . By statistically counting the number of effects of each factor in the operation running of EHS-FSA, ultimately, the importance of factors can be calculated to get a quantitative analysis results.

At the theoretical level, both SCEAs are dynamic running of EHS-FSA. That is, the dynamic transition processes of service consistency states are modeled by them in software simulation environment with time advancement, in which the continually changing behaviors and their consistency states referring to the elements of EHS-FSA can be monitored. At the application level, SCEAs can identify the factors’ dynamic behaviors that cause and ’s inconsistency phenomena in SODSA and statistically draw the amount of each factor’s occurrence to quantitatively analyze the evolution essence of service inconsistency.

The inputs of SCEA- involve the following: (1) ’s amount and the cycle number are initialized. (2) The counting values of inconsistent factors are initialized: (refer to the events , , and , resp.). (3) Initialize ’s state arrays: . The outputs of SCEA- include: the final numbers of factors occurrence that results in service inconsistency is determined: NumVM, , NumSR and (i.e., the ultimate amounts of state transition events VM, SE, and SR). The detailed processes of SECA- is described as the pseudocode in Algorithm 1.

(1) Initialize ,   ;
(2) NumVM,   ,   0;   /* Counts of ’s input events are initialized */
(3) for   to   do
(4)  (1, 1, 1);   /* Initialize the state array of   */
(5) endfor
(6) for ( ;   ++;   ) do
(7) for each     AtS do
(8) Get current state   ;
(9) Find the rules ts     TS at   ;
(10)   Select   AI according to its event probability;
(11)    Execute operation ;   /* Trigger a state transition */
(12)    if     then
(13)   NumVM++;/* Count the number of event   */
(14)    else  
(15)   NumSE++;/* Add the number of event   */
(16)    else  
(17)   NumSR++; /* Add the number of event   */
(18)    endif
(19)   endfor
(20) endfor

The inputs of SCEA- are as follows. (1) Initialize and ’s counts , , and the cycle number . (2) The original values of inconsistent factors’ counting are assigned: (refers to the events , , and , resp.). (3) ’s state arrays are initialized: . (4) The initial composition schema of : select several randomly. (5) Initialize ’s state arrays: . The outputs of SCEA- are: the ultimate amounts of inconsistency states’ factors: NumID, NumMI, and NumSC. Algorithm 2 gives the pseudocode description of SECA-’s detailed courses.

(1) Initialize , , ;
(2) NumID,  NumMI,  NumSC0; /* Counts of ’s input events are initialized */
(3) for   to     do
(4)  (1, 1, 1); /* Initialize the state array of   */
(5) endfor
(6) Select 2–4 stochastically which are assembled into ;
(7) for   to   do
(8)  ; // Initialize the ’s state array
(9) endfor
(10)for ( ;   ++;   ) do
(11) update by Algorithm 1;
(12) for each     do
(13)   Get current state ;
(14)   Find the rules   at ;
(15)   Select according to its event probability;
(16)   Execute operation   ; /* Transition happens */
(17)   if     then
(18)   NumID++;/* Add the number of event   */
(19)   else  
(20)  NumMI++;/* Count the number of event   */
(21)   else  
(22)  NumSC++; /* Add the number of event   */
(23)   endif
(24)  endfor
(25)  endfor

For the sake of the initial quantitative and dynamic exploration into service inconsistency factors and their evolution mechanism, therefore, ill-considered facets in SECAs design will inevitably appear, but the idea of using such novel analysis is an innovational and significative approach.

6. Quantitative Evaluation Experiment

6.1. Simulation Initialization

We implement the experimental evaluation using MATLAB R2009a on a PC with a Genuine Intel CPU T2400 (1.83 GHz) and 3.0 GB RAM, operated in Windows XP. We set the original number of as 2–4 stochastically. Actually, owing to the small difference in the total number of that minimally affects the algorithms’ outputs when its count exceeds 50, the number of initial could have been 5, 6, or 7 too. For example, if the total number of is 156 or 157, the proportions of inconsistency factors (or events) remain at the same level when ’s count is 155 in simulation experiments.

At the initial evolution moment, several atomic services () are randomly composited into one . The importance of each inconsistency factor (i.e., NumVM, NumSE, NumSR, NumID, NumMI, and NumSC) can then be determined. To get the trustier results, we deploy four groups of experiments to execute the algorithms SECA- and SECA- where the total cycle numbers of them are 100, 200, 300, and 400. In addition, the selection of the input events in evolving EHS-FSA depends on the probability and constraints of the events occurrence defined in Section 4.2. For the exactly and credibly statistical analysis, all the results of the four experiments are averaged.

6.2. Results and Analysis

Table 3 shows that the experimental counting results on the effects of factors on service consistency which were derived by taking a different and running the programs of SECA- and SECA-. According to the collected data in Table 3, the impact ratios of service inconsistency events can be manually calculated, as shown in Table 4, whose data are a more accurate revelation.

To facilitate our experimental analysis in a more obvious manner, the statistical results in Table 3 are exhibited using the bar charts in Figures 4 and 5(b). Figures 4(a)4(d) illustrate the continually rising times of each influence factor’s occurrence while the algorithms’ cycle number , respectively equals 100, 200, 300, and 400, which imply the importance degree for service inconsistency, as shown in Table 4. It can be observed from Figure 4 and Table 4 that the order of these factors’ importance degree is listed as follows.(1): .(2): .(3): .(4): .

From the listed-above sequences, we can observe that factor is the biggest influential one leading to inconsistent states of atomic service and factor exerts minimal effect on ’s consistency states. These sequences also indicate that the order of influencing proportion at different cycle times of SECA- and SECA- is the same despite the ratios’ tiny differences.

In the following parts, we discussed what and why are the actual situations of the influencing rates of factors on service consistency evolution, as indicated by the experiment outcomes in Tables 3 and 4 and Figure 4. We combined some actual software development examples related to distributed service deployment in local area network (LAN) or wide area network (WAN) and evaluations results in this paper to discover some regular behaviors and give significative guidance for actual service consistency maintenance.

(1) The factors with very high impact (ranked 1 and 2) are ’s bad reusability () and ’s noncomposition (i.e., several atomic services are not composited into one larger service ) (). This is mainly for the reasons: firstly, there is a great deal of incompatibilities in interfaces and deployment styles as fusing the old distributed simulation systems into the current SODSA; secondly, there exist many different development tools such as C++, JAVA, MATLAB, Simulink, LABVIEW, and so forth; thirdly, the produced services are from different modeling domains such as electrics, communication system, machine design, hardware, and software. Such heterogeneity and diversity are prevalent, increasing the difficulty of service combination and reusability. These situations are based on objective facts in SODSA deployment and are not easy to be changed nowadays.

(2) The third important factor (ranked 3) is ’s message communication failure (). From the perspective of service application layer, we can say that is actually the most important influential factor on services inconsistency because in current or future SODSA, message is the most popular medium for service communication, and the message interactions between services are frequent and also can be easily blocked, due to the services’ enormous amount, the continually entry and exit of simulation nodes, the instability of distributed network, and so on.

(3) The fourth and fifth factors with moderate impact (ranked 4 and 5) are ’s encapsulation failure () and ’s interface description difference (), respectively. This is mainly because ’s encapsulation and ’s interface description are the basis of service calls, which occupy an important position in simulation service developments and directly affect such services behaviors like composition, reusage, interaction, and so on.

(4) The confusion of version management () is the smallest influential factor (ranked 6). In general, the management mechanism of simulation services is usually effective and stable once it has been established.

Figure 5(a) indicates that the impact of each factor on service inconsistency states is continuously strengthened with the increasing cycle number in SECA. We can also observe from Figure 5(a) that event has the greatest increasing effect on , events and exert a greater increasing influence on , whereas events and have a very small changing extent to affect and ’s consistency states, respectively, and has the smoothest changes whose effect on is the smallest. On the basis of the average statistics at four cycle times, Figure 5(b) depicts the influencing factors’ bar comparison by which the sorting of these factors and their impact rate is . Obviously, this order is consistent with the results in Figure 4 and each factor’s impact rates at different cycle times only have a tiny difference, which improve the reliability of our experiment.

The above analysis results can provide an important concern on overcoming the service inconsistency risks in the design, development, publishing and subscription, operation running and maintenance of services in SODSA. To say the least, our experimental results may not completely reflect the actual influencing mechanism of service inconsistency factors, but most of them are in line with the actual situation. After all, in service evolution processes, the behaviors are complex, the attributes are various, and the system size is unpredictable, and so on. Hence, we must make some reasonable assumptions and self-defined rules by which the simulation evaluation can be finished effectively.

7. Conclusion

In this paper we propose an extended hierarchical finite state automata EHS-FSA and its two subalgorithms (SCEA- and SCEA-) to monitor the consistency states changes of and in SODSA. Based on theoretical and macroscopic perspective, EHS-FSA can formally portray the dynamic impact mechanism of service inconsistency behaviors and attributes in terms of reusability, composition, message exchange, service encapsulation, and so on. The presented SCEA aims to achieve a quantitative analysis of the inconsistency factors in service evolution for compositional SODSA, by running the EHS-FSA automata.

This study represents our preliminary attempt to introduce a novel analysis method of inconsistency factors which is completely different from previous ones. Our quantitative evaluation experiments show that EHS-FSA and SCEA are feasible, effective, advanced, and superior to traditional ones. The research achievements can offer theoretical and technical guidance for reducing service inconsistency states and improving the correctness of simulation services. In addition, our methods also can be applied to other domains such as the analysis and design of distributed-cooperative command posts that are deployed in future battlefields, complex distributed information systems based on network-centric warfare, embedded real-time systems.

Some future researches are as follows: (1) more inconsistency factors should be focused. (2) Some in-depth analysis of the disturbance mechanism among factors should be done. (3) The probability of event set should be considered more carefully. (4) Related maintenance technologies of service consistency can be developed based on our experiment results.

Conflict of Interests

The authors declare that there is no conflict of interests regarding the publication of this article.

Authors’ Contribution

Linjun Fan and Jun Tang contributed equally to this work.

Acknowledgment

This research is partially supported by the National Natural Science Foundation of China (no. 61272336).