Paper-1 Service Orchestration Based On QoS and Transactional Properties Using Mixed Integer Programming Model

International Journal of Computational Intelligence and Information Security, September 2013 Vol. 4, No.
7 ISSN: 1837-7823
Service Orchestration based on QoS and Transactional Properties using Mixed Integer Programming Model T.Alexander1 and E.Kirubakaran2 1 Research Scholar, School of Computer Science, Engineering and Applications, Bharathidasan University, Tiruchirappalli, Tamilnadu, India.
2
Additional General Manager, SSTP (Systems), Bharat Heavy Electricals Ltd, Tiruchirappalli, India. Abstract
Efficient and appropriate selection of web services has become mandatory in the current information age. This paper presents an efficient methodology for selection of web services and incorporation of a transaction processing system in the selection of web services. The initial process performs the service ranking using pairwise comparison and user assigned values. These provide weights for the web services. Mixed integer programming is used to obtain the best available service with minimum cost. Transaction processing system is used to enable transactional and QoS aware web services. CWS are often long-running, loosely coupled, and cross organizational applications. In this context, we are interested in transactional behavior of the resulting WS composition. The transactional properties of a CWS highly depend on the transactional properties of its component WSs and on the structure of the workflow. Keywords: Web service selection; composition of web services; QoS bases service selection; Transaction aware processing 1. Introduction Web service is a series of platform-independent operations for cooperative design over a network. As services proliferate on the Web, several services may provide similar functionalities while hosted in different sites [1,2]. It is necessary to select the best Web service from available candidates. On the other hand, Web services are overloaded, and it is increasingly difficult for the users to locate the right Web service at the right time. Therefore, Web service recommendation system has emerged to help user select suitable Web services. Quality of Service (QoS) encompasses important functional and nonfunctional characteristics of Web service [3]. By combining QoS attributes with preferences and needs of users, recommender systems will more effectively provide the user with intelligent and proactive Web services. The Web service composition can be viewed as a three step process: 1) composite Web service specification, 2) selection of the component Web services, and 3) execution of the composite Web services. At the first step, the user submits the goal he/she wants the composite service achieves, along with some constraints and preferences that need to be satisfied [4]. Workflows can be used to model the composite Web service specification. During the second step, component Web services fulfilling the users goal are selected among a set of available services. This WS selection could be done by hand (in this case, steps specification and
4
International Journal of Computational Intelligence and Information Security, September 2013 Vol. 4, No. 7 ISSN: 1837-7823
selection are integrated) or could be automatically decided by the system. When component WSs are selected at design time, the third step of the composition process consists in executing the selected component WS. At runtime, selection and execution of component WS are integrated and the selection is described as dynamic. While many works have been done for Web service selection, designing a composite Web service to ensure not only correct and reliable execution but also optimal QoS remains an important challenge [5]. Indeed, WSs composition based on transactional properties ensures a reliable execution, however, an optimal QoS composite Web service is not guaranteed. Moreover, composing optimal QoS Web services does not guarantee a reliable execution of the resulting composite Web service. Thus, QoS-aware and transactional-aware should be integrated. However, the problem is generally addressed from the QoS side or from the transactional side separately. The conventional QoS aware composition approaches [6], [7], [8], [9], [10] do not consider the transactional constraints during the composition process, likewise transactionalaware ones [11], [12], [13], [14], [15] do not consider QoS. As far as we know, only Liu et al. [5] propose a composition model in design time, which captures both aspects in order to evaluate the QoS of a composite WS with various transactional requirements. However, the authors do not consider the automatic selection step and only analyze the impact of the transactional requirements on the QoS of the composite WS. Our research objective is to propose a design-time selection algorithm for automatic WS composition, where transactional and QoS requirements are both integrated in the selection process. It is evident that such an integration could only be done by considering first the transactional requirements. The analytic hierarchy process (AHP) is a structured technique for organizing and analyzing complex decisions. It has particular application in group decision making[20], and is used around the world in a wide variety of decision situations, in fields such as government, business, industry, healthcare, and education. Rather than prescribing a "correct" decision, the AHP [21] helps decision makers find one that best suits their goal and their understanding of the problem. It provides a comprehensive and rational framework for structuring a decision problem, for representing and quantifying its elements, for relating those elements to overall goals, and for evaluating alternative solutions. Users of the AHP first decompose their decision problem into a hierarchy of more easily comprehended sub-problems, each of which can be analyzed independently. The elements of the hierarchy can relate to any aspect of the decision problemtangible or intangible, carefully measured or roughly estimated, well- or poorly-understoodanything at all that applies to the decision at hand. Once the hierarchy is built, the decision makers systematically evaluate its various elements by comparing them to one another two at a time, with respect to their impact on an element above them in the hierarchy. In making the comparisons, the decision makers can use concrete data about the elements, but they typically use their judgments about the elements' relative meaning and importance. It is the essence of the AHP that human judgments, and not just the underlying information, can be used in performing the evaluations.
5
The AHP converts these evaluations to numerical values that can be processed and compared over the entire range of the problem. A numerical weight or priority is derived for each element of the hierarchy, allowing diverse and often incommensurable elements to be compared to one another in a rational and consistent way. This capability distinguishes the AHP from other decision making techniques. In the final step of the process, numerical priorities are calculated for each of the decision alternatives. These numbers represent the alternatives' relative ability to achieve the decision goal, so they allow a straightforward consideration of the various courses of action. The remainder of this paper is structured as follows; section II provides a complete system architecture, section III provides a complete description of the working system, section IV provides the results and discussion and section V concludes the study. 2. System architecture The current process is performed in two phases. The initial web service selection phase fetches the appropriate services from the repository, while the service ranking phase analyzes the properties of the web service and accordingly ranks them for the user perusal.
Figure 1: Transaction aware QoS Web Service Orchestration and Ranking Figure 1 provides a complete process of web service selection and ranking. During the service ranking, user is allowed to provide weights, and if the user is indeterminate about the weights, then, pair wise comparison is performed. Hence each attribute is provided with its corresponding rank. Mixed Integer Programming is used to filter out the web services that provide the appropriate functionalities with minimum cost. Finally, transaction awareness is incorporated to provide a reliable system.
6
3. Our approach The current approach is performed in two phases. The initial service selection uses various QoS parameters [19] that define the selection of the system. The various QoS parameters that are being used are performance, scalability, reliability, robustness, capacity, exception handling, accuracy, integrity, accessibility, availability, interoperability, security, regulatory and network related QoS. These properties functions as the base in selecting a service for usage in the current workflow. 3.1. Service Orchestration
This process performs the short-listing of services from the main service repository. All the appropriate services are taken from the repository and are passed to the next phase for performing the ranking process. It performs automated arrangement, coordination, and management of complex services.
Table 1: QoS Parameter Description
Exception Handling Performance Integrity Security Scalability Regulatory Network related QoS
Exception handling is the process of responding to the occurrence, during computation, of exceptions anomalous or exceptional events requiring special processing often changing the normal flow of program execution. It is provided by specialized programming language constructs or computer hardware mechanisms. Performance is the quality aspect of Web service, which is measured in terms of throughput and latency. Higher throughput and lower latency values represent good performance of a Web service. Throughput represents the number of Web service requests served at a given time period. Latency is the round-trip time between sending a request and receiving the response. Integrity is the quality aspect of how the Web service maintains the correctness of the interaction in respect to the source. Proper execution of Web service transactions will provide the correctness of interaction. A transaction refers to a sequence of activities to be treated as a single unit of work. All the activities have to be completed to make the transaction successful. When a transaction does not complete, all the changes made are rolled back. Security is the quality aspect of the Web service of providing confidentiality and nonrepudiation by authenticating the parties involved, encrypting messages, and providing access control. Security has added importance because Web service invocation occurs over the public Internet. The service provider can have different approaches and levels of providing security depending on the service requestor. Scalability is the ability of a web service to handle a growing amount of work in a capable manner or its ability to be enlarged to accommodate that growth. Regulatory is the quality aspect of the Web service in conformance with the rules, the law, compliance with standards, and the established service level agreement. Web services use a lot of standards such as SOAP, UDDI, and WSDL. Strict adherence to correct versions of standards by service providers is necessary for proper invocation of Web services by service requestors. To achieve desired QoS for web services, the QoS mechanisms operating at the web service application level must operate together with the QoS mechanisms operating in the transport network (e.g., RSVP, DiffServ, MPLS, etc.) which are rather independent of the application. In particular, application level QoS parameters should be mapped appropriately to corresponding network level QoS parameters. Basic network level QoS parameters include network delay, delay variation, and packet loss
Accessibility Availability Reliability Accuracy Robustness Capacity Interoperability
Accessibility is the quality aspect of a service that represents the degree it is capable of serving a Web service request. It may be expressed as a probability measure denoting the success rate or chance of a successful service instantiation at a point in time. There could be situations when a Web service is available but not accessible. High accessibility of Web services can be achieved by building highly scalable systems. Scalability refers to the ability to consistently serve the requests despite variations in the volume of requests. Availability is the quality aspect of whether the Web service is present or ready for immediate use. Availability represents the probability that a service is available. Larger values represent that the service is always ready to use while smaller values indicate unpredictability of whether the service will be available at a particular time. Also associated with availability is time-to-repair (TTR). TTR represents the time it takes to repair a service that has failed. Ideally smaller values of TTR are desirable. Reliability is the quality aspect of a Web service that represents the degree of being capable of maintaining the service and service quality. The number of failures per month or year represents a measure of reliability of a Web service. In another sense, reliability refers to the assured and ordered delivery for messages being sent and received by service requestors and service providers. Web services should be provided with high accuracy. Accuracy here is defined as the error rate generated by the web service. The number of errors that the service generates over a time interval should be minimized. Web services should be provided with high robustness. Robustness here represents the degree to which a web service can function correctly even in the presence of invalid, incomplete or conflicting inputs. Web services should still work even if incomplete parameters are provided to the service request invocation. Web services should be provided with the required capacity. Capacity is the limit of the number of simultaneous requests which should be provided with guaranteed performance. Web services should support the required number of simultaneous connections. Web services should be interoperable between the different development environments used to implement services so that developers using those services do not have to think about which programming language or operating system the services are hosted on.
3.2.
Service Ranking
Service rankings are performed using the weighted sum model of relevant measures. By default, the weights of categories, attributes and measures are set to be equal. Consumers can alter those weights based on their preferences. The consumers can either use pairwise comparison method proposed by Saaty [16,17] or direct arbitrary weight. Analytic Hierarchy Processing is used for performing the comparison process. 3.2.1. Pairwise Comparison
The pairwise comparisons are made depending on a 9 point scale. In the pairwise comparison matrix, the score of suv represents the relative importance of the component on row (u) over the component on column (v), i.e., suv = wu=wv. The reciprocal value of the expression (1=suv) is used when the component v is more important than the component u. The comparison matrix S is defined as
w1 / w1 w / w s= 2 1 M wn / w1
w1 / w2 K w2 / w2 L M O wn / w2 L
w1 / wn 1 s12 w2 / wn = s21 1 M M M wn / wn S n1 sn 2
L L O L
s1n s2 n M 1
(1)
Then, a local priority vector (eigenvector) w is computed as an estimate of the relative importance accompanied by the elements being compared by solving the following equation:
sw = max w,
where max is the largest eigen value of matrix S.
(2)
3.2.2. User Assigned Weights The consumer can assign weights in their own scale rather than using the pairwise comparison. For this case, the weights are normalized. Let uwc denote the user assigned weight for category c, then category weights wc is calculated as follows: wc = wwc , c c wwc
(3)
10
Let uwca denote the user assigned weight for attribute a and uwam denote the user assigned weight for measures m. Let wa and wam, denote the normalized attribute and measure weight respectively. C P S Category Web service Comparison matrix Largest eigun value of S Attribute for webservice p Cost of service No of services required to complete the workflow Score of category c for a webservice p Sum of rank category scores Atomicity variable Comparsable variable Retriable variable Transactional behaviour definer Ranking total score Minimum required ranking score for an attribute Minimum required ranking sccore for a webservice Minimum required total ranking score Weight for m measure Weight for attribute a No of service provided Binary decision variable Table 2: List of Notations used 3.3. Service Ranking Calculation Let spa denote the ranking attribute score of an attribute a for a web service p and spam denote the measure score of a measure m belong to attribute a. The attribute score spa for every attribute type is calculated as follows:
aip cip did spc spa ta tc tr tt tsp ua uc
max
uts wan wca xip yip
s pa = wam s pam, p, a
m
(4)
Subject to
11
w
m
am
= 1, a
(5)
Let spac denote the score of the category c for the web service p. The category score Spac is calculated using weighted sum approach of relevant ranking attributes score Spa and measures m. The ranking category Score Spc for every category type is defined as follows:
s pc = wca s pa , p, c
a
(6)
Subject to
w
a
ca
= 1, c
(7)
Let tsp denote the total ranking score for a service provider p. Total ranking score tsp is calculated by using weighted sum approach of all rank category scores spac. The ranking total score for every web service p is defined as follows.
ts p = wc s pc , p
c
(8)
Subject to
w
c
=1
(9)
3.4. Mixed Integer Programming In this section, the mixed integer programming is presented as the core formulation. Minimize:
12
z = c ip xip
i p
(10)
Subject to
x
p
ip
di , i
(11) (12) (13) (14) (15) (16) (17) (18) (19) (20) (21) (22) (23)
x
i
p
ip
aip , p
n, p, x p { 0,1}
y jp uy jp , j , p s pc uc ,p, c s pa ua ,p, a ts p uts ,p xip 0 , i, p
1if provider p has compliance with property j y jp = { 0 otherwise
if all component ta = {1 0 otherwise
ws ' s complete sucessfully
If all the webservices are comparsable tc = {1 0 otherwise If all the webservices are retriable tr = {1 0 otherwise If all the webservices ex aibit transactional behaviour tt = {1 0 otherwise
13
The general form of MIP is formulated above. The goal of objective function (10) is to minimize the total deployment cost. The decision variable x ip denotes the number of services provisioned and cip denotes the cost of services. The constraint in (11) maintains that the consumers demand for a service i is satisfied. In (12), the constraint states that the allocation for a web service must not exceed the maximum resources capacity offered. Constraint (13) indicates that the number of web services is to be limited for deployment according to the consumer specification and application requirements. Constraint in (14) ensures that the providers compliance with constraints. Constraints in (15) and (16) ensure that the web services having ranking category and attribute score greater than or equal to the consumer requirement. In (17), the constraint implies that the web service having a total ranking score greater than or equal to the consumer specified score is considered for usage. Constraint (18) indicates that variables accept the values from a set of nonnegative integers. 3.5. Transaction Aware Web Services
Atomic CWS:A CWS is atomic if once all its component WSs complete successfully, their effect remains forever and cannot be semantically undone. On the other hand, if one component WS does not complete successfully, then all previously successful component WSs have to be compensated. In the following, is used to indicate an atomic CWS while is used to indicate a non atomic one. Compensatable CWS: A CWS is compensatable (c) if all its component WSs are compensatable. Retriable CWS: An atomic or a compensatable CWS is retriable (r) if all its components are retriable. Transactional CWS: A Transactional Composite Web Service (TCWS) is a CWS whose transactional behavioral property is in { , r,c, cr} A TCWS[18] takes advantage of component service behavioral properties to specify mechanisms for failure handling and recovery. It can be composed of elementary WSs, whose properties are in {p, pr, c, cr}, and/or can be composed of CWSs, whose properties are in { , r,c, cr} This section shows the process of assigning a WS to each activity in a workflow, in order to obtain a TCWS. For simplicity, we suppose a workflow containing only two activities. We first consider the assignation of two WSs to the activities of a sequential pattern. Proposition 1: In a sequential pattern, if the WS assigned to the first activity of the pattern is pivot (p), pivot retriable (pr), atomic ( ), or atomic retriable ( r), then, to obtain a TCWS, the WS assigned to the second activity should be pivot retriable (pr), atomic retriable ( r), or compensatable retriable
14
(cr). The Transactional Property (TP) of the resulting TCWS is atomic ( ) and is moreover atomic retriable ( r) if all its components are retriable. Proof. If the WS assigned to the first activity of the pattern is p, pr, , or r, then, its effects cannot be semantically undone, thus the execution of the second WS should guarantee a successfully termination. The only condition to guarantee a successfully termination is the retriable property. Therefore, the WS assigned to the second activity should be pr, r, or cr. Proposition 2: In a sequential pattern, if the WS assigned to the first activity of the pattern is compensatable (c) or compensatable retriable (cr), then the resulting CWS is always transactional (TCWS) whatever the TP of the WS assigned to the second activity is. The TP of the resulting TCWS is atomic ( ) if the WS assigned to the second activity is either pivot (p), pivot retriable (pr), atomic ( ), or atomic retriable ( r). The TCWS TP is compensatable (c) if the WS assigned to the second activity is either compensatable (c) or compensatable retriable (cr). Moreover, when both component WSs are retriable, the resulting TCWS is retriable. Proof. When service WS1 assigned to the first activity of the pattern is c or cr, the resulting CWS is at least because if the WS assigned to the second activity fails, then WS1 can be compensated. Moreover, the resulting CWS is c when the WS assigned to the second activity is c or cr.
4. Results and discussion The 14 QoS properties are considered for evaluation. 4 web services corresponding to a single process are taken into account. Each webservice is imposed with various criterion and weighted according to the QoS parameters. The criteria vales assigned for the QoS parameters defines the importance of the parameter. This is carried out as a pairwise comparison process.
15
Figure 2: Criterion weight ratio Figure 2 shows the criterion weight ratio in a 100% scale. According to our scenario, we can see that accuracy has the maximum importance, while network related QoS has the minimum importance.
Figure 3:Consolidated Ranking

16
Figure 3 shows the consolidated ranking of various QoS parameters with respect to the services providing them.
Figure 4: Service Comparison Figure 4 shows the comparison of services with respect to the QoS parameters.
Figure 5(a): Evaluation in context of: Exception Handling
17
Figure 5(b): Evaluation in context of: Performance
Figure 5(c): Evaluation in context of: Integerity
18
Figure 5(d): Evaluation in context of: Security
Figure 5(e): Evaluation in context of: Scalability
19
Figure 5(f): Evaluation in context of: Regulatory
Figure 5(g): Evaluation in context of: Network related QoS
20
Figure 5(h): Evaluation in context of: Accessibility
Figure 5(i): Evaluation in context of: Availability
21
Figure 5(j): Evaluation in context of: Reliability
Figure 5(k): Evaluation in context of: Accuracy
22
Figure 5(l): Evaluation in context of: Robustness
Figure 5(m): Evaluation in context of: Capacity
23
Figure 5(n): Evaluation in context of: Interoperability
Figures 5 (a) to (n) shows the evaluation of services in the context of each QoS parameter. It also ranks these services accordingly in the graphs. 5. Conclusion Many services exist in the service marts for performing a single process. Selection of the efficient and the most appropriate web service is one of the most important process that improves the efficiency of any system. The quality aware selection made by the current proposal takes into consideration various parameters defined by the W3C and IBM as the most important quality attributes that should be provided by a web service. Every web service is evaluated with these properties in consideration, and are ranked accordingly. Finally the service with appropriate properties and least cost is considered for usage. The current proposal also incorporates a transaction based service. Since web services only form a part of the workflow, maintenance of ACID properties becomes a necessity. Further improvisation can be provided by providing provisions for web service reuse. Increase in service selection can be performed by caching the top k dominating queries. Dynamic service composition can be performed for efficient functioning. References [1] [2] [3] [4] Malik Z., Rater BA., (2009), Credibility assessment in web services interactions,WorldWideWebInternetWebInfSyst12(1):325. Wu Z., Deng S., Li Y., Wu J., (2009), Computing compatibility in dynamic service compositio, KnowlInfSyst(KAIS)19(1):107129. Zeng L., Benatallah B., Ngu AH., Dumas M., Kalagnanam J., Chang H., (2004), QoSaware middleware for web services composition,IEEETransSoftwEng30(1):311327. Yu Q., Liu X., Athman B., and Medjahed B., (2008), Deploying and Managing Web Services: Issues, Solutions, and Directions, TheVLDBJ., vol. 17, no. 3, pp. 537-572.
24
[5]
Liu A., Huang L., and Li Q., (2006), QoS-Aware Web Services Composition Using Transactional Composition Operator, Proc.SeventhIntlConf.AdvancesinWeb-Age InformationManagement(WAIM06), pp. 217-228. [6] Jaeger MC., Roec-Goldmann G., and Muehl G., (2004), QoS Aggregation for Web Service Composition Using Workflow Patterns, Proc. Eighth IEEE Intl Enterprise DistributedObjectComputingConf.(EDOC04), pp. 149-159. [7] Menasce D., (2004), Composing Web Services: AQoS View, IEEE Internet Computing, vol. 6, no. 8, pp. 88-90. [8] Wu B., Chi CH., and Xu S., (2007), Service Selection Model Based on QoS Reference Vector, Proc.IEEECongressServices(Services07), pp. 270-277. [9] Zeng L., Benatallah ANB., Dumas M., Kalagnanam J., and Chang H., (2004), QoSAware Middleware for Web Services Composition,IEEETrans.SoftwareEng., vol. 30, no. 5, pp. 311-327. [10] Zhang W., Yang Y., Tang S., and Fang L., (2007), QoS-Driven Service Selection Optimization Model and Algorithms for Composite Web Services, Proc. 31st Ann. Intl Proc. Advanced Intl Conf. Telecomm. and Intl Conf. Internet and Web Applications and Services (AICT ICIW), p. 145, 2006.Computer Software and Applications Conf. (COMPSAC 07), vol. 2, pp. 425-431. [11] Bhiri S.,Perrin O., and Godart C., (2005), Ensuring Required Failure Atomicity of Composite Web Services, Proc.14thIntlConf.WorldWideWeb(WWW), pp. 138-147. [12] Bhiri S., Perrin O., and Godart C., Extending Workflow Patterns with Transactional Dependencies to Define Reliable Composite Web Services, [13] Li L., Liu C., and Wang J., (2007), Deriving Transactional Properties of Composite Web Services, Proc.IEEEIntlConf.WebServices(ICWS07), pp. 631-638. [14] Montagut F., Molva R., and Golega ST., (2008), Automating the Composition of Transactional Web Services, IntlJ.WebServicesResearch, vol. 5, no. 1, pp. 24-41. [15] Portilla A., Vargas-Solar G., Collet C., Zechinelli-Martini JL., and Garca-Ban uelos L., (2007), Contract Based Behavior Model for Services Coordination, Proc.ThirdIntl Conf.WebInformationSystemsandTechnologies(WEBIST07), pp. 109-123. [16] Saaty, TL., (1980), The analytic hierarchy process: planning, priority setting, resources allocation. McGraw-Hill. [17] Saaty TL., (2005), Theory and applications of the analytic network process: decision making with bene_ts, opportunities, costs, and risks. RWSpublications. [18] Zaiwen Feng & Rong Peng & Raymond K., Wong & Keqing He & Jian Wang & Songlin Hu & Bing Li, (2013), QoS-aware and multi-granularity service composition , InfSyst Front15:553567,DOI10.1007/s10796-012-9378-5. [19] David Cavalcanti JM., Fbio Souza N., Nelson Rosa S., (2013), Adaptive and Dynamic Quality-Aware Service Selection, 21st Euromicro International Conference on Parallel, Distributed, and Network-Based Processing, 1066-6192/12 $26.00 2012 IEEE, DOI 10.1109/PDP.2013.60. [20] Saaty, Thomas L.; Peniwati, Kirti (2008). Group Decision Making: Drawing out and Reconciling Differences. Pittsburgh, Pennsylvania: RWS Publications.ISBN978-1888603-08-8. [21] Saaty, Thomas L., (2008-06). "Relative Measurement and its Generalization in Decision Making: Why Pairwise Comparisons are Central in Mathematics for the Measurement of
25
Intangible Factors The Analytic Hierarchy/Network Process". Review of the Royal Academy of Exact, Physical and Natural Sciences, Series A: Mathematics (RACSAM)102(2): 251318. Retrieved 2008-12-22.
26

Paper-1 Service Orchestration Based On QoS and Transactional Properties Using Mixed Integer Programming Model

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Paper-1 Service Orchestration Based On QoS and Transactional Properties Using Mixed Integer Programming Model

Uploaded by

Copyright:

Available Formats

International Journal of Computational Intelligence and Information Security, September 2013 Vol. 4, No.

Table 1: QoS Parameter Description

Accessibility Availability Reliability Accuracy Robustness Capacity Interoperability

aip cip did spc spa ta tc tr tt tsp ua uc

uts wan wca xip yip

y jp uy jp , j , p s pc uc ,p, c s pa ua ,p, a ts p uts ,p xip 0 , i, p

1if provider p has compliance with property j y jp = { 0 otherwise

if all component ta = {1 0 otherwise

ws ' s complete sucessfully

Figure 3:Consolidated Ranking

Figure 5(a): Evaluation in context of: Exception Handling

Figure 5(b): Evaluation in context of: Performance

Figure 5(c): Evaluation in context of: Integerity

Figure 5(d): Evaluation in context of: Security

Figure 5(e): Evaluation in context of: Scalability

Figure 5(f): Evaluation in context of: Regulatory

Figure 5(g): Evaluation in context of: Network related QoS

Figure 5(h): Evaluation in context of: Accessibility

Figure 5(i): Evaluation in context of: Availability

Figure 5(j): Evaluation in context of: Reliability

Figure 5(k): Evaluation in context of: Accuracy

Figure 5(l): Evaluation in context of: Robustness

Figure 5(m): Evaluation in context of: Capacity

Figure 5(n): Evaluation in context of: Interoperability

You might also like