Performance Evaluation of an Automatic Web service

Composition Architecture

Bruno Tardiole Kuehne1, Regina Helena Carlucci Santana

1, Volker Linnemann

2, Marcos José Santana

1

1University of São Paulo, SSC-ICMC and

2University of Lübeck, IFIS

São Carlos, Brazil and Lübeck, Germany

{btkuehne,rcs,mjs}@icmc.usp.br and linnemann@ifis.uni-luebeck.de

Abstract—Automatic Web service Composition (AWSC) is still a

big challenge in service oriented architecture (SOA), since there

is no platform where is possible to implement and test algorithms

for AWSC. This paper presents the Automatic Web service

composition Architecture (AWSCA), an architecture in which is

possible to implement and run the algorithms for AWSC in an

environment proposed for a fair comparison. To reach this

objective is proposed a prototype that is able to deploy and

execute Automated Composite Web services. This prototype

consists of a tool which receives as input a graph with the

description of the composite Web service flow, performs and

controls the execution and interaction between the services. This

approach makes possible to evaluate the performance and to

compare the algorithms for AWSC in order to identify which one

is a better choice for certain scenarios.

Keywords—Automatic Web service Compostion, Web service

Composition, Performance Evaluation, SOA

I. INTRODUCTION

SOA is an architecture that enable services, which were developed with different technologies, to be accessed or interact with another services in a direct way. One definition of SOA is a collection of service, which could be accessed through simple request or by the interaction of two or more services[1].

The Web service Composition is a promise technique to achieve one of the main goals from SOA, that is the easy interaction between services. The development of composite Web services is sometimes a complex task for developers, because the search for Web services which can be part of the Composite Web service is not trivial. In [2] an experiment using students to develop composite Web services is presented. This experiment indicates that the most difficult part of the creation of new composite services is the discovery of pertinent Web services to achieve the goal.

In order to solve this problem the use of semantic Web services was proposed. With semantic Web services it is possible to find services and their relation according to the semantic links between them. It enables the use of services in cooperation for a wider purpose. Semantic Web services enable the AWSC through algorithms that can find services and compound them, according to the users input and output, that are formatted according to semantic rules.

There are many available algorithms that propose how to automatically compose Web services, however there is no platform where it is possible to run real implemented Semantic Web services flow, and it is still impossible to make a performance evaluation in those algorithms to compare them and check how it could work in a real environment or which algorithm is the best option for specific cases.

This paper presents AWSCA (Automatic Web service Composition Architecture), an architecture in which is possible to implement algorithms for AWSC and to evaluate their performance.

Nowadays the main language for Web service composition is WS-BPEL. WS-BPEL provides a language for the specification of Executable and Abstract business processes. It extends the Web service interaction model and enables it to support business transactions[3]. WS-BPEL is indeed the pattern for Web service composition, it is a robust and powerful language to make interaction between Web services. To create a WS-BPEL composite service it is necessary to write the WS-BPEL source code, describe the partner services, compile the code and deploy it in a WS-BPEL engine application server. These tasks make complex the process of create a composite service automatically, since it was designed for manual composition. However, an AWSC algorithm does not make so complex flows and it does not need so robust and complex controls of execution as WS-BPEL provides.

For this issue, a lightweight engine that is capable to manage the Composite Web service execution is proposed. AWSC algorithms are restricted to connect the output from one service to the input of another one. The engine proposed in this paper can handle those kind of operations including parallel execution and synchronization.

The main goal of this paper is to present a suitable architecture for performance evaluation of algorithms for AWSC. Passing by all the steps of the AWSC, the first step is a request from a user for new Composite Service, then the algorithm selects the appropriate services to perform the composition, and finally performs the execution of all the services of the flow, to return the response to the requester of the composite service.

The rest of the paper is structured as follows: Section 2 discusses how the AWSC can be achieved, related automated

978-1-4799-0838-7/13/$31.00 ©2013 IEEE 123

Web service composition works are discussed, and performance evaluation of AWSC is presented. Section 3 presents the proposed architecture, AWSCA, describing its discrete modules and how they are integrated to achieve their purpose. Section 4 presents the Service Dispatcher, a lightweight tool proposed to achieve the execution of services obtained from a AWSC. Section 5 provides the performance evaluation of the Service Dispatcher. In Section 6 the conclusions and future work are discussed.

II. BASIC CONCEPTS AND RELATED WORK

The terms manual, automatic, static or dynamic composition is common terms in the related literature. According to the papers [4][5] the dynamic and static are classifications that can be applied in automatic and manual composition. Static composition refers to the association of each service implementation at design time; it means that the service to perform each function of the flow is selected by the programmer in design time. In dynamic composition the implementation of the services are selected at runtime, but the kind of service that composes the flow is selected at design time. Manual and Automatic composition are two major classifications: in manual composition a graph describing execution flow and logical reference to Web services is planned by a developer. The Automatic Web service Composition (AWSC) is the process of creation a new Composite Services according to the request of an user by a computational system without any intervention of humans.

In the AWSC, the request for a composite service needs to be made using semantic description of input and output, e.g., a user having the need to use a computational system that receives as input the semantic description represented by A, and as output a semantic description represented by C. There is no such service available on the Web services Repository. However it is possible to find two services named X and Y. X receives as input, the semantic description A and provides as output the semantic description B. The service Y receives as input the semantic description B and provides as output the semantic description C. In this example a computational system that does not use AWSC is not able to identify the possibility of combining the services A and B into a new one to solve the client need. In AWSC systems the combination between such services can be made in a way that the user would not need to have knowledge about the details of how many services are needed and how they interact between them to provide the requested result.

The process of AWSC can be divided in three main parts: the matchmaking of the services, services selection and services execution.

The matchmaking is responsible for the creation of semantic links between services. Using the same example, the semantic link would be made between the services X and Y by the semantic description B. The semantic link is the connection between services that occurs when one service has an output which is equivalent to the input of another service. One example of matchmaking algorithm is presented in [6], where it checks the full combination of all services available on the registry. The result is a graph with all possibilities of

connection between semantic Web services. It was one of early works in this topic and it has no good performance when there is a large amount of services. It is difficult to calculate all combinations every time the environment changes. To improve the matchmaking there are several new approaches proposed in the literature. Other papers also present other matchmaking approach such as in [7], where the author proposes the development of a hybrid Web service matchmaking. The paper [8] presents a matchmaking framework based on Description Logic for semantic Web service described by RDF4S model. In [9] the author presents the SAWSDL-iMatcher, a matchmaking that can be customized, thus the users can use their preferred strategies for matchmaking according to the application requirements.

After the matchmaking has created all the semantic links between the services, the algorithm for Web services selection is performed to find the most appropriate services to solve the user request. In [10] the matchmaking model for the service composition is made through a multilayer process which creates a plan graph structure within a matrix of semantic links. To make the selection an Immune-inspired algorithm is used. In [11] the matchmaking algorithm proposed by [6] is used to create the semantic links between the services. Then the Dijkstra algorithm is applied to find the best path for the service composition. In [12] the author uses OWL-S Web service semantic presentation to describe the composition problem as a planning problem described in a standardized way using PDDL, thus it is possible to use AI techniques to find the best services for the composition. Other approaches for service selection are also presented in [13][14][15].

Thus the full description of the composite service is defined by the matchmaking and the service selection algorithm; and the service execution step is performed: in this step the composite service is executed. However, there is still no formal tool to perform the execution of the services in a AWSC.

There is many research aiming at how to make AWSC. But there is a lack of how to make the comparison between the algorithms for matchmaking and service selection. in order to discover which algorithm would be the best approach for certain cases, since there is no environment for performance evaluation in AWSC.

There is no work concerned in how to evaluate or compare those algorithms in a real world scenario. The works found in the literature about performance evaluations of Web service composition are [16] and [17]. In [16] a tool for static composite Web service is presented, and the author also propose techniques for performance evaluation of flows. In [17] a tool to make formal description of composite Web services based on WS-BPEL is presented. With this tool is possible to have an environment close to the reality for performance evaluation of flows made by manual composition technique.

In [18][19][20] are also presented solutions of how to evaluate performance on AWSC. They use Petri Nets to describe the Web services composition in a simulated environment, in these work no execution of the composite Web services is considered.

124

All these papers have valuable contribution in composite Web service performance evaluation, but no one brings a discussion of how it could be made in Automatic Web service composition implemented systems.

Thus, in this paper an full architecture is proposed. By using this architecture together with these algorithms and performance evaluation approaches, the architecture makes possible to have the entire process of performance evaluation of AWSC. From the request of the user for a new composite service, to the final result achieved by the execution of the flow returned by the algorithm of AWSC.

III. AUTOMATIC WEB SERVICES COMPOSITION

ARCHITECTURE

The architecture AWSCA proposed in this paper contemplates all the steps of the service composition in different modules and makes the performance evaluation in a modular way. It is possible to combine different matchmaking algorithms with service selector algorithms to have a performance evaluation in a more detailed way. For this, the user of the architecture needs to implement a connector to make possible the communication between the Matchmaking algorithm and the Service Selector algorithm. It is also possible to deploy matchmaking and selection service algorithms combined in a single module.

Figure 1 shows a Diagram of the Architecture proposed, AWSCA. The modules composing the Architecture are described as follow:

Figure 1. AWSCA Diagram

AWSCA Service Provider: responsible to receive the semantic description request from the user containing the desired input and output. This module is responsible for coordinating the whole execution of the AWSC.

AWSC Matchmaking + AWSC Selection Algorithm: in this module the Matchmaking and service selection algorithms are located. They are responsible to find the candidate services and create the description of a flow of execution that is able to solve the requests of the users. The matchmaking access the Service Provider Repository to acquire information about the Semantic Services available.

Service Provider Repository: module which all the Web services Providers publish their semantic description. This module contains information from all the Web services providers; through this module is possible to find candidate services for the Web service composition.

XML Flow Writer: this module is responsible for converting the output format from the algorithm of service selection for a default XML format, as presented in Figure 2. After the conversion to this format, the Service Dispatcher is able to process it.

Service Dispatcher: this module makes the properly execution of the Web services. This module is not consider in the related research, since there is no official tool available to perform AWSC, which makes it still a lack in order to make performance evaluation of AWSC. In this paper a Service Dispatcher is proposed.

Web service Providers: this module represents the Web Server where the Web services implementation are located.

Each module of the architecture works in an independent way, making possible to implement the complete architecture just connecting the modules.

To analyze the performance evaluation of a Composite Web service, functional and non-functional properties needs to be considered. In [21] some of these properties are presented, as follows:

Availability: is an aspect from the Web service, that indicates how often it is ready to receive requests; this is frequently represented by a percentage.

Reliability: probability of a Web service to respond within the time slot expected and to perform its functionality correctly.

Cost: is the monetary amount that a Web service will charge the client.

Response Time: is the time of a request from the moment that it is started until the moment that the requester receives the response.

Reputation: is measured by the clients of the service evaluation. Can be collected from the user on the end of each access.

For performance evaluation of Web service composition, it is necessary to consider these properties in the selection of the services, in order to provide for the client the best option available. When the wrong approach is used, the user can have a bad experience and also paying more for it. For this reason it is important in the performance evaluation to consider these properties.

To have a full knowledge of the behavior of all those properties, the execution is also an important step of the AWSC to be considered. Only with a full environment it is possible to make a complete performance evaluation.

125

Currently in the development of the proposed Architecture, a prototype of the Service Dispatcher was implemented. This prototype comprises an important contribution to the area because although there is already a lot of algorithms for AWSC there is no tool to perform the automatic execution of Composite Services available. Therefore the proposal of this work is to provide an architecture where it is possible to implement the algorithms for AWSC available on the literature, and thus being possible to make the performance evaluation and to analyze the behavior of those algorithms in a real environment.

IV. SERVICE DISPATCHER

WS-BPEL is a de facto pattern of language for Web service composition. WS-BPEL is a powerful language for the development of Web service composition but WS-BPEL was designed to develop Web service composition in a manual approach. Thus, to develop a manual Web service composition using WS-BPEL, it is needed to write the WS-BPEL code, describe the partner-links of the composition, compile the code and deploy the composite service. Even using the graphical IDE for developing WS-BPEL composite services it is a hard task, since it is needed to make the right configuration for each engine of the composition. Use WS-BPEL for AWSC makes the development more complex.

AWSC always results in direct connected graphs and there is no need to have such a complex language to describe the composite service. Therefore, in this architecture a lightweight Web service composition manager is proposed. The Service Dispatcher can manage the variables involved in the process, coordinate the sequence of the execution by controlling the splitting for parallel execution of services and also joining for the synchronization.

The Service Dispatcher receives as input a XML file which describes the Composite Service to be executed. In figure 2 an example of an XML file of a flow is presented. The flow is composed of four services. The XML file describes the order of the execution and also the output/input connections. Each service is represented by the XML tag <Service>. The tag <Service> has as sub tags:

<ID> identifier of the service in the flow.

<WSDL> containing the URL to access the WSDL of the service.

<OPERATION> indicates which operation of the service will be accessed.

<PARAMETER> contains a list of parameters to be submitted in the operation access

<OUTPUT> defines the variable name of the output from the service to be accessible later by other services.

The tag <FINAL_OUTPUT> describes which variable of the flow should be returned to the user as result of the

composition of the service. The tag <Connection> is used by the Service Dispatcher to build a data structure of a connected graph in the memory to handle the order of execution of the services. The sub tags of <Connection>, <ID1> represents the identifier of the service that needs to be executed before the execution of <ID2>.

In figure 2, an XML example file is presented. In this example, the service with ID 001 has the operation s01, the operation s01 receives as parameter the string “Hello!”, and as an identifier for the output of this operation the name o0001 is used. For the services with ID 002 and 003 the input parameter is o0001 that is the output of the service with ID 001, it means that booth services cannot start before the service 001 finishes the execution. The service with ID 004 has two input parameters, the inputs for this service are the output of services

002 and 003, this means that service 004 cannot start before both have finished the execution.

Figure 2. XML file describing a Composite Service

126

Figure 3. Graphical representation of a Composite Service

In Figure 3 there is the graphical representation of the flow described in Figure 2 by an XML file.

Using this methodology it is possible to keep the synchronization of the composite service, making it possible to run services in parallel and having a point of synchronization since the next service will be always waiting for the response of the previous one.

After reading the XML file, the Service Dispatcher creates one variable for the output of each service on the flow and one Thread of execution for each service of the Composite Service. All the Threads will start at sleeping mode and having one flag that will signalize if the service is ready to run. Just the first service will not start in the sleep mode. When the execution of the first service ends it will signalize that it has finished, set the flag of the next service to available mode and wake up all the Threads. The services that are able to start running will start the execution, the services that is still not able, will be kept in the sleep mode.

To perform the execution of the service, was used the AXIOM library included in Apache Axis. The AXIOM library makes it possible to perform the execution of services without the need of creation of stubs to it.

In the next section a performance evaluation of the tool is presented. In this performance evaluation the behavior of the Service Dispatcher is checked by using different sizes of the messages that are exchanged between the services, and also when the amount of clients that are using it at the same time increases.

V. SERVICE DISPATCHER PERFORMANCE EVALUATION

The performance evaluation presented in this paper, is based on the techniques proposed by [22].

As a prototype was implemented, measurement technique was chosen to evaluate it . For the performance evaluation of Service Dispatcher 3 factors were analyzed:

Number of Clients: number of clients that will request for a composite service execution at the same time. For this factor, 2 levels were chosen, 100 and 500 clients requesting the composite service at the same time.

Services per Flow: is the amount of services used to create a composite service. The 2 levels used in the experiment for this factor were 6 and 12 services. In figure 4 the 2 flows developed for the experiment are graphically represented

Size of Input: is the size of the message passed to the composite service as parameter. The levels used in this factor were 100 and 500 bytes message, in String data type.

Figure 4. Composite Web services used on the Experiments

The methodology chosen to make the experiments was the complete factorial, in which each execution of the experiments was repeated 30 times, having the confidence interval in the results with 95% of confidence. With 3 factors with 2 levels each, the number of experiments is 8. In table 1 the experiments are presented.

TABLE I. EXPERIMENTS TABLE

Experiment

A (Number

of Clients)

B (Services

per Flow)

C(Size of

Input)

1 100 6 100B

2 100 6 500B

3 100 12 100B

4 100 12 500B

5 500 6 100B

6 500 6 500B

7 500 12 100B

8 500 12 500B

127

The environment used in the experiments consists of 4 Intel quad-core computers, having 4GB RAM memory each, all of them using Linux Ubuntu 64 bits distribution. A gigabit network was used to connect the computers. 2 computers were used as service providers, using Apache Tomcat [23] as application server and Apache Axis2 [24] as Web service SOAP processor and 6 services were deployed on each machine. 1 computer was used as Service Dispatcher Manager, the tool Service Dispatcher was deployed as a Web service in an Apache Tomcat with Axis2. 1 computer was used to emulate the clients and in this machine scripts were made to create 100 and 500 requests at the same time for the Service Dispatcher.

The services developed for this performance evaluation, receives as input a String and return the same String, with exception of services S04 and S10, that receive 2 Strings, concatenate them and return it as result. The services were created in this way because in this performance evaluation the logic inside the services is not relevant.

The purpose of this performance evaluation was to check the ability of the Service Dispatcher to manage execution of composite flows. The reason of make all the services to receive inputs and return outputs, was to ensure that the Service Dispatcher always have messages to manage.

In figure 5 the results of the Experiments are presented according to the configuration shown in table 1. In Axis-Y is showed the average response time. In Axis-X is the number of the experiment, also presented in table 1. For each of the 8 experiments, it was performed thirty times to make statistics confirmation of the results, computed using Standard Deviation and Confidence Interval using the confidence level of 99,5%, showed with the error bar included in the result bar of all the experiments.

For the first 4 experiments it was submitted to the Service Dispatcher 100 clients at the same time. It is considered a moderate workload to the system. It had an average response time lower than 2 seconds for the Experiments 1 and 2, that had 6 services per flow. In the Experiments 3 and 4, the number of services per flow was 12, the Service Dispatcher had an average response time of 2 seconds. In this first scenario, having 100 clients accessing the system at the same time, and using as Service Dispatcher one machine, the system presented a good response time, always close to 2 seconds. Even in the cases which the composite service was composed of 12 services.

In the last 4 experiments 500 clients were submitted at the same time to the system; this is considered a heavy workload. In the flow composed of 6 services the average response time is lower than 6 seconds and in the flow composed of 12 services the average response time is a slightly over 7 seconds. In this scenario, the response time is not so good. However, in a case which the server is having a heavy workload, it is still acceptable for the client to wait for around 6 seconds.

To make a better understanding of the results, a Factor Influence was calculated. The techniques used are from the book [22]. With the Factor Influence it is possible to measure how large is the Influence of each factor. Also the influence of the combination of factors is possible to be measured with this technique.

Figure 5. Response time result

In figure 6 the Influence that each factor had on the experiments is presented. QA represents the factor Number of Clients, QB Services per Flow, QC Size of Input, QAB, QAC, QBC and QABC presents the influence considering the combination of the factors.

With the result of this analysis it is possible to notice that the factor that had the higher impact on the results was QA(Number of Clients). As the number of clients increases, the load in the system increases proportionally, since that for each new client the system needs to create a new session to respond to its needs.

The overload that comes with the increasing number of clients using the system at same time can be overcome by the use of an Architecture of Distributed Server to deploy the Service Dispatcher. Then the distributed Web Server is responsible for making the workload balance.

The factor QB(Services per Flow) does not have a considerable impact on this performance evaluation. The number of services that compose a flow made a small variation on the response time of the experiments, that indicates that flows composed of a large number of services, is not a problem for the tool.

The factor QC (Size of Input) had almost no influence on the results, even using input message with a big difference of size.

The only interaction between factors that was not null was the interaction QAB(Number of Clients x Services per Flow). But it represents a really small impact on the experiments, what makes hard to have any conclusion about it.

128

Figure 6. Influence of each Factor in the Experiment

VI. CONCLUSION AND FUTURE WORK

This paper has as its main goal to present an Architecture for performance evaluation of Automatic Web service Composition in a real environment. The main contributions presented in the paper are the Architecture where all the steps of the AWSC are considered, and the Service Dispatcher, that is an approach of how to manage the execution of the Composite Web services obtained by the Algorithms of Web service Composition.

The architecture is proposed in a modular way, that enables to locate monitors for measurements on all each module in order to check the behavior of each one in a separate way.

From the experiments it is possible to conclude that the Service Dispatcher can handle a large number of clients having acceptable response times, even when a workflow composed of 12 services is requested. It shows that this tool enables performance evaluation of AWSC in a complete way.

As future works several algorithms proposed in the literature will be implemented in order to compare them in an real environment.

Using a repository with a large number of services is also a challenge task. There is an open repository available in [25] with semantic description of services. In this repository is available 1083 services categorized in 9 different categories (education, medical care, food, travel, communication, economy, weapons, geography and simulation). This repository should be used in the next steps to make a performance evaluation using those services.

ACKNOWLEDGMENTS

The authors thank the financial support from FAPESP, DAAD, CAPES and CNPq, a Brazilian government entity dedicated to the Brazilian scientific and technological development.

REFERENCES

[1] Bih, J. "Service oriented architecture (SOA) a new paradigm to implement dynamic e-business solutions." ubiquity 2006.August (2006).

[2] Lu, J.; Yu, Y.; Roy, D. & Saha, D.: Web service Composition: A Reality Check. In: Benatallah, B.; Casati, F.; Georgakopoulos, D.; Bartolini, C.; Sadiq, W. & Godart, C. (Hrsg.): Springer Berlin Heidelberg. 4831 : Web Information Systems Engineering – WISE 2007., 2007, S. 523-532

[3] Jordan, D., Evdemon, J., Web services Business Process Execution Language Version 2.0, http://docs.oasis-open.org/wsbpel/2.0/OS/wsbpel -v2.0-OS.pdf, 2007

[4] Rao, J., Su, X.. A Survey of Automated Web service Composition Methods. First International Workshop on Semantic Web services and Web Process Composition, SWSWPC 2004.

[5] Dustdar, S., Schreiner, W., A survey on Web services composition. Int. J. Web Grid Serv. 1, 1, 1-30, 2005.

[6] Paolucci, M.; Kawamura, T.; Payne, T. & Sycara, K.: Semantic Matching of Web services Capabilities. In: Horrocks, I. & Hendler, J. (Hrsg.): Springer Berlin Heidelberg. 2342 : The Semantic Web ISWC 2002., 2002, S. 333-347

[7] Yang, Y.; Zheng, W.; Liu, S. & Li, X.: A Hybrid Matchmaking Algorithm for Semantic Web service. In:: . : Computer and Information Technology (CIT), 2012 IEEE 12th International Conference on., 2012, S. 147 -151

[8] Zhi-Hao, Z. & Shi, Y.: RDF4S Based Semantic Web service Matchmaking Framework. In:: IEEE Computer Society. : Proceedings of the IEEE International Workshop on Semantic Computing and Systems., 2008, S. 95--100

[9] Wei, D.; Wang, T.; Wang, J. & Bernstein, A.: SAWSDL-iMatcher: A customizable and effective Semantic Web service matchmaker. In: Web Semantics: Science, Services and Agents on the World Wide Web 9 (2011), Nr. 4, S. 402 - 417

[10] Pop, C.; Chifu, V.; Salomie, I. & Dinsoreanu, M.: Immune-Inspired Method for Selecting the Optimal Solution in Web service Composition. In: Lacroix, Z. (Hrsg.): Springer Berlin Heidelberg. 6162 : Resource Discovery., 2010, S. 1-17

[11] Prazeres, C. V. S.; Teixeira, C. A. C.; Pimentel,M. G. C. Semantic Web services discovery and composition: paths along workflows. In Proceedings of ECOWS' 09: 7th IEEE European Conference on Web services, 2009, S. 1-9.

[12] Hatzi, O.; Vrakas, D.; Nikolaidou, M.; Bassiliades, N.; Anagnostopoulos, D. & Vlahavas, I.: An Integrated Approach to Automated Semantic Web service Composition through Planning. In:: . 5, Nr. 3, 2012, S. 319 -332

[13]

[14] Li, W. & Guo, W.: Semantic-based Web service Matchmaking Algorithm in Biomedicine. In:: . 1 : BioMedical Engineering and Informatics, 2008. BMEI 2008. International Conference on., 2008, S. 648 -652

[15] Lin-Feng, S. & Yong, Q.: A Novel End-User Oriented Service Composition Model Based on Quotient Space Theory. In:: . : Service Sciences (ICSS), 2010 International Conference on., 2010, S. 180 -184

[16] Yu, H. Q. & Reiff-Marganiec, S.: A Backwards Composition Context Based Service Selection Approach for Service Composition. In:: . : Services Computing, 2009. SCC '09. IEEE International Conference on., 2009, S. 419 -426

[17] Chandrasekaran, S.; Miller, J.; Silver, G.; Arpinar, I. B. & Sheth, A. Composition, Performance Analysis and Simulation of Web services 2002

[18] He, Y.; Zhao, L.; Wu, Z. & Li, F.: Modeling Web services Composition with Transaction Extension for Performance Evaluation. In:: . : Asia-Pacific Services Computing Conference, 2008. APSCC '08. IEEE., 2008, S. 476 -481

[19] Fang, X.; Zhang, J. & Yin, Z.: A Study on the Dynamic Web service Composition Based on Stochastic Petri Net. In:: . 1 : Web Information Systems and Mining (WISM), 2010 International Conference on., 2010, S. 113 -117

[20] Wu, Z.; He, Y.; Liu, H.; Zhao, L. & Shen, H.: A Stochastic Performance Model Supporting Time and Non-time QoS Matrices for Web service

129

Composition. In:: . : Asia-Pacific Services Computing Conference, 2008. APSCC '08. IEEE., 2008, S. 999 -1004

[21] Zhang, Z.; Yang, Z. & Liu, Q.: Performance analysis of composite Web service. In:: . : Granular Computing, 2008. GrC 2008. IEEE International Conference on., 2008, S. 817 -821

[22] Kalepu, S.; Krishnaswamy, S.; Loke, S.W.; , "Verity: a QoS metric for selecting Web services and providers," Web Information Systems Engineering Workshops, 2003. Proceedings. Fourth International Conference on , vol., no., pp. 131- 139, 13 Dec. 2003

[23] Jain, R. The Art of Computer Systems Performance Analysis: Techniques for Experimental Design, Measurement, Simulation, and Modeling. John Wiley _& Sons, New York, 1991

[24] Moodie, M. Pro Apache Tomcat 6. New York: Apress, 2007. 325 p.

[25] Jayasinghe, D. Quickstart Apache Axis2: A practical guide to creating quality Web services . Birmingham: Packt Publishing, 2008. 186 p.

[26] Klusch, M.; Khalid, M., A.; Kapahnke, P.; Fries, B.; Vasileski, M. OWL-S Service Retrieval Test Collection, http://www.semwebcentral.org/projects/owls-tc/, 2010.

130