Smart Computing Review, vol. 5, no. 5, October 2015
469
Smart Computing Review
Run Time Fault Detection System for Web Service Composition and Execution K.Jayashree and Sheila Anand Rajalakshmi Engineering College Anna University / Chennai, India/
[email protected] Rajalakshmi Engineering College Anna University / Chennai, India/
[email protected] * Corresponding Author: K.Jayashree Received July 30, 2015; Revised August 30, 2015; Accepted October 18, 2015; Published October 31, 2015
Abstract: Composite web services are a group of web services which together offer service functionality. Faults can occur during composition or execution of any of the services that make up the composite services. Run-time monitoring of web service execution enables real-time detection of faults concurrent with the service execution. This paper extends our previous work on fault detection of single web services to detect faults in composite web services. Fault handler has been proposed to detect faults during composition of web services for static, semi dynamic and dynamic compositions. Policies have been used to denote the intended run-time behavior of web services. Web service execution has been monitored against these policies to detect run-time faults. The proposed work has been tested using a sample web service application and the results are presented Keywords: Web Service Composition Fault, Fault Detection, WS-Policy, Static composition Fault Detection, Semi Dynamic composition Fault Detection, Dynamic composition Fault Detection.
Introduction
W
eb services are distributed and programmatically accessible over standard Internet protocols and interoperate independently of the programming languages, operating system and hardware platforms used to implement them [Yu et al, 2007]. Web services are based on eXtensible Markup Language (XML) standards and are supported by standard protocols like Simple Object Access Protocol (SOAP) [Mitra et al, 2007] for message exchange, Web Services Description DOI: 10.6029/smartcr.2015.05.009
470
Jayashree et a.l.: Run Time Fault Detection System for Web Service Composition and Execution
Language (WSDL) [Christensen et al, 2001] for interface description and Universal Description Discovery and Integration (UDDI) [Clement, 2004] for service discovery [Curbera et al, 2002]. Web service technology is being increasingly deployed for many commercial applications such as like online reservation, auction, stock trading and banking [Jayaprakash & Vimal Raja, 2010]. Run-time monitoring and fault management are required to ensure that services are continuously available for business use. In this paper, we focus on run-time fault detection of composite web services. Web services can be classified as simple and composite web service. A simple web service also known as basic or atomic web service is a single stand-alone web service that implements the interaction between the service provider and service user. A composite web service is a group of web services that jointly offer web service functionality. Composite web services are used to extend the capabilities offered by single web services in order to realize the full potential of web services. Web service composition facilitates creation of new web services from a set of available service [Zein & Kermarrec, 2006]. Web service composition can also be defined as the orchestration of atomic web services into a composite service. Web Service Business Process Execution Language (WS-BPEL) [D‟Mello et al, 2011 & Alves et al 2004] is commonly used to compose different services into a single structured process. It is an XML-based language that provides the user with variables, conditionals, loops, asynchronous messages, process correlation and facilities for transaction and exception handling [Bratanis et al, 2010]. WS-BPEL is commonly used for static and semi dynamic composition. OWL-S [Srinivasan et al, 2006, Martin et al 2004] is a Web Services Ontology that provides a conceptual framework for describing semantic web services and is widely used for dynamic composition. The context of composite web services is very dynamic and several kinds of changes and faults may occur during and after deploying a composite service. For example, one of the composite services may have been updated but the corresponding web service description (WSDL) may not have been updated. There could be policy changes in the execution of web services. When such situations happen, the composite web service would not function correctly and runtime faults would occur. The user may not know the exact problem and would be unable to handle the faults correctly. Several issues have to be addressed in order to enable effective execution and interoperability of these composite web services. Among the several issues, the ability to detect and isolate faults during service execution is of prime importance [Alam, 2009]. Monitoring web services and particularly composite web services is more difficult than monitoring a centralized application. This paper focuses on monitoring composite web services and fault detection during composition and execution of web service. Fault handling in static, semi dynamic and dynamic composition has been presented. The rest of the paper is organized as follows. Section 2 presents the related work. Section 3, presents the proposed work with respect to run-time fault detection in composition and execution of composite web service. Section 4, presents implementation and testing of the proposed work with a sample application. Section 5 concludes the paper.
Related work Schroder et al 2009 have described monitoring as a verification technique to detect run-time errors. Run-time monitoring of business processes can be treated as a dynamic analysis of run-time events. Such events can be analyzed online and as they occur during the execution of the application or offline that occur after the execution has been terminated [Shne et al, 2009]. Verification is an off-line technique, done to guarantee that the deployed services satisfy a set of requirements and temporal properties. On-line techniques provide a real-time detection capability that is performed concurrently with service execution. [Chan et al 2007] have proposed fault taxonomy related to Composite web services. They have explained the causes and consequences of various faults and have proposed run-time monitoring and reactive strategies to ensure that composition is correct. This paper does not consider the failures and its impact on recovery and also does not cover dynamic composition. Mahbub and Spanoudakis [2005] have developed a framework to support the run-time verification of requirements for service based systems whose composition process is specified in BPEL. The requirements to be monitored are specified using event calculus. Event logs are recorded during the execution of the service and these are then checked against the specifications. However, event calculus is difficult to understand and implement. Alodib and Bordbar [2009] have presented a model based approach for fault diagnosis in Service oriented Architecture. The presented approach extends Discrete Event Systems techniques to automate the creation of Diagnoser Services to monitor the interaction between the services. Various methods for implementing the Diagnoser services, such as BPEL or a dedicated Java class deployed with the web services have been studied. However, this approach does not discuss how dynamic composition is done. Moser et al [2008] have proposed an extension of BPEL environment that allows run-time monitoring of web services. They have presented VieDAME (Vienna Dynamic Composition and Monitoring Extension), wherein selectors have been used to replace existing partner services with other services that are syntactically or semantically equivalent. The weakness of this approach lies in its lack of detection failure. Self-healing deals with recovery from failure in dynamic composition of web services. The objective of self-healing is to minimize the number or duration of outages in order to maintain the availability of the composite service [Chan & Bishop 2008]. Some of the work relating to self healing of web services has been discussed.
Smart Computing Review, vol. 5, no. 5, October 2015
471
Poonguzhali et al [2011] have proposed architecture for self-healing in dynamic composition of web services. The web service response time is monitored and alternate web services are proposed to maintain the Quality of Service (QoS). Dynamic composition may have several faults that include incorrect order, service incompatibility and service unavailability. Failure detection has not been dealt with in detail. Halima et al [2008] have proposed a framework for monitoring and analysis of QoS failures. QoS parameters considered include response time, throughput, and availability. They have proposed an algorithm to discriminate between network and processing deficiencies. The authors have presented an approach to monitor and detect QoS degradation. However, this paper does not deal with execution failures and recovery from such failures. Boumhamdi and Jarir et al [2012] in their work have discussed about different types of failures in web service composition and the strategies to recover from such failures. The approach they presented focuses mainly on using a BPEL verifier to monitor a BPEL process to detect failures such as time out. BPEL adapter has been proposed to substitute an unavailable partner service with an alternate service. The failure detection process has not been discussed in detail and the actual failures detected by their proposed solution have not been discussed.
Run-Time Fault Detection of Composite Web Service In a composite web service, one or more web services combine together to offer a specific functionality. Each of the individual web services are known as participants and each of these participant web services can in turn be a simple or composite web service. The process of developing a composite web service is referred to as a web service composition [Charfi et al 2009]. Web services are typically composed using three methods, namely, Static, Dynamic and Semi Dynamic method. Static web service composition is carried out at design time and the web services are executed as per the defined composition. In semi dynamic method, web services composition is partially defined at design time, with the service providers being identified; but the discovery and binding is carried out during run-time execution. In dynamic web service composition, web services requirements are defined at design time but the discovery of the web services is carried out at run-time. The web service properties are matched and resolved based upon criteria established at design time. Run-time monitoring and fault detection has been presented for all the three types of composition, namely, static, semi dynamic and dynamic composition. Our earlier work on fault detection for single web services [jayashree & Sheila, 2013] has been extended to detect faults in composite web services. Policies have been used to describe the correct behavior and constraints in the execution of web services. WS-Policy has been used to describe the specifications of the individual web services. The capabilities and constraints are expressed using XML syntax. The participants in a composite web service could be web services that are offered by different service providers. The process flow indicates in which order the services should be invoked and from which service provider. BPEL has been used to define the process flow for static and semi dynamic composition of web services. OWL-S has been used to define process flow for dynamic web service composition. The web service execution process begins when the service user invokes the composite web service with input parameters as defined in WSDL. These inputs are used to execute the first partner service. The output of the first partner service is given as input to the next service and so on. The pseudo code for Composite Web Service Fault Handler (CSFH) is given in Table 1. The inputs received from the service user are first verified by CSFH using policy information retrieved from Fault Diagnoser. Policy information is maintained separately for each of the individual participating services. If error is detected in the inputs provided by the service user, then Fault Information is sent to user. Next the service is invoked with the inputs given by the user. If invocation is not successful, that is, the service is not available, Fault information is returned to the user. Otherwise, the service is executed and the response from the service is once again verified with the policy by CSFH. Again if faults are present in the response, appropriate fault information is sent to user. Else the output of the first service is used as input to execute the next service. Service execution proceeds as per the process flow defined in BPEL and the inputs and outputs for each partner service are verified individually by CSFH. For example, if there was an error in the inputs specified by the user in invoking the web service, the error message to the user would indicate the input parameter where the error has occurred and also provides details as to the exact fault. For instance, the user could have given a text input when a numeric input is expected. Likewise, the outputs are also verified. The user can correct the error and reuse the service. Errors could also occur while trying to invoke the service for execution. For example, the service name could be incorrect or the service provider may have discontinued or renamed the service. Such errors would also be trapped and appropriate error message would be sent to the user. The user has the option to cancel the service and invoke some other service. The fault detection is repeated for each of the component web services till the composite web service successfully executes.
472
Jayashree et a.l.: Run Time Fault Detection System for Web Service Composition and Execution Table 1. Pseudo code for Diagnostic Fault Handler Initialize Serviceindex = 1 Receive ClientRequest (ClientInput) ClientInput Input Until Serviceindex < NumberofServices { S= service[Serviceindex] If (CSFH( Input) InputError ) Redirect Client Else { Invoke service(S, Receive) Output If Service is Available If (CSFH(Output) OutputError ) ReplyClientResponse( faultInformation ) Else Ouput Input Else Redirect Client } Serviceindex ++ } Reply ClientResponse( Ouput )
■ Faults in web services composition Faults can occur in individual services and as well as in composing the constituent web services at run-time. Faults that occur in the individual component web services would also prevent the composite web services from executing successfully. All such faults need to be detected and handled appropriately. The users can be provided with meaningful error messages to enable them to correct the error or look for replacement of failed services with other equivalent web services in order to complete their task successfully. The Faults that occur during composition and execution that are detected by the proposed work is given in Table 2. Table 2. Fault class and code Fault Class
Composition
Fault Code
600
Fault ID
Description
601
Service unavailable
602
Incorrect service
603
Time Out
604
Transaction fault
605
Synchronization fault
606
Parameter incompatibility fault
607
Execution Fault
Service Unavailable indicates that there is a failure in the service being executed and this could occur for a number of reasons. The service may have been updated by the service provider but not reflected correctly in the service registry. The service may not exist or the server may be down. Incorrect Service would occur due to service discovery faults. For example, Service-Not-Listed fault will occur when the service being looked-up is not available in the registry. Incorrect search criteria may have been applied by the user to look for the service. Time Out errors would occur due to slow network or server failures. Transaction fault would occur due to errors in completing the transaction for which the composite web service is being used. For example, the database updates may not have been correctly completed leading to a transaction fault. Synchronization faults can occur because of mismatch in the service execution flow between the service provider and service client. Execution fault occurs when the web service does not execute correctly. One of the reasons could be due to incorrect parameter or wrong number of input parameters. For example, an error would occur when a string value is given
Smart Computing Review, vol. 5, no. 5, October 2015
473
as input parameter when an integer value is expected. Likewise, if there are errors in the execution, the results obtained would be incorrect. Execution fault could also occur due to errors in the SOAP message exchanged between the user and service provider.
■ Fault detection in Static Composition Static composition of web services has been done by using BPEL which allows the manipulation of services as activities and processes. The web service composition is defined at designed time. The interface of the composite service is described as a collection of WSDL PortTypes. All the participant services in BPEL process are modeled as partners. The WSDL files of such partners are used to create the BPEL process and the sequencing of process activities is done using BPEL Process flow. The architecture for run-time fault handling in static composition of web services in given in Figure 1.
Figure 1. Architecture for Run-time Fault Handling in Static Composition of Web Services The web service composition and execution request is handled by the BPEL Validator component. The BPEL partner links are used to invoke the partner services from the service providers in the defined order of processing. The partner services could be invoked from different service providers as defined in the BPEL code. The Composite Service Fault Handler (CSFH) has been integrated with the BPEL validator component of the BPEL program to detect faults in composition and run-time execution of these composite services. When a fault occurs, the execution is transferred to the BPEL Validator and from there to CSFH. The fault is interpreted and appropriate error message is reported to the user. CSFH verifies and handles faults with respect to service invocation and also the inputs and outputs used to invoke each of the individual partner services. The policy information is obtained from Fault Diagnoser by CSFH.
■ Semi dynamic composition BPEL has been used for specifying semi dynamic composition. The target namespace, WSDL URL, port type and operation name used for invoking the service is obtained as an XML file from the service registry using the service key and business key. The obtained XML file is then parsed to get the above mentioned details to invoke the web service. The architecture for run-time fault handling in semi dynamic composition of web services in given in Figure 2. The web service execution request, as in static composition, is handled by the BPEL Validator component. When a fault occurs, the execution is transferred to the BPEL Validator and from there to CSFH. The fault is interpreted and appropriate error message is reported to the user. Errors could also occur while trying to obtain the URL for service invocation. For example, there could be a mismatch between the business key and service key specified; because of which it would not be possible to obtain the service URL. CSFH for semi dynamic composition verifies and handles faults with respect to service
474
Jayashree et a.l.: Run Time Fault Detection System for Web Service Composition and Execution
discovery and invocation. The inputs and outputs used to invoke each of the individual participating services are also verified and faults, if any, are detected.
Figure 2. Architecture for Run-time Fault Handling in Semi Dynamic Composition of Web Services
■ Dynamic composition Web services have been dynamically composed using OWL-S. OWL-S combines semantic web technologies such as RDF (Resource Description Framework) and OWL (Web Ontology Language) with WDSL. OWL-S is an OWL ontology with three interrelated sub ontologies; Service Profile, Process Model and Grounding. The Profile is used to specify “what the service does”, the Process Model describes “how it works” and Grounding specifies “how to access” the service. The Profile is used for advertising, constructing service requests, and matchmaking. The Process Model is used to enable invocation, composition, monitoring and recovery. OWL-S provides a construct known as the atomic process, which is characterized primarily in terms of its inputs, outputs, preconditions, and effects (IOPEs). The constructs of the process model are mapped onto concrete message formats expressed in WSDL. The architecture for run-time fault handling in dynamic composition of web services in given in Figure 3. OWL-S Matchmaker is integrated in the service registry to handle dynamic composition. Service client will send an XML file to service registry with Business key, service key, and IOPE parameters. In the service registry, OWL-S Matchmaker will search and choose the specific services by using the functional parameters. In dynamic composition, when a single service cannot satisfy the query, OWL-S Matchmaker will find a sequence of services where the output of one service is the input to another service, and the set of services are matched to the given query. Matchmaker will rank higher those services that are a closer match to the given input and output. The client application will invoke the highest ranked service using the grounding details. CSFH is used to monitor the run-time execution of web services. In case of errors, appropriate and meaningful error messages are sent to the user. This will enable the user to identify in which service the fault has occurred and take appropriate corrective action.
Smart Computing Review, vol. 5, no. 5, October 2015
475
Figure 3. Architecture for Run-time Fault Handling in Dynamic Composition of Web Services
Implementation and Results IBM Rational Application Developer IDE has been used for the implementation of run-time Fault Detection system. jUDDI (Java Universal Description Discovery and Integration) has been used to configure the web service registry. The web services are published in the jUDDI registry which is implemented using MySQL database. SOAP handlers have been configured using JAX-RPC to detect faults in the execution of web services. The policies have been generated using WSPolicy standard. Web services have been composed using BPEL for static composition and semi dynamic composition and OWL-S has been used for dynamic composition. A sample web service application for car sales has been used for implementing for testing the composition faults in the web services. Services providers have been implemented as; Car Dealer, Insurance Agent, Registration Authority and Bank have been developed. The description of the web services is shown in Table 3.
Faults have been simulated in the Composite service. Faults simulated include: Failure of the first service in the composite web service. For example, car booking service consists of two services; order processing and advance payment. Failure has been simulated in order processing. Likewise, failures have been simulated in the other composite services that have been used.
Failure in the second service of the composite service. For example, insurance processing is successful, but insurance payment does not go through due to lack of funds or other reasons.
Failure of the last service in the composite service. For example, failure in Road tax payment in the Car Purchase web service.
Jayashree et a.l.: Run Time Fault Detection System for Web Service Composition and Execution
476
Table 3. List of Web Services for Car Sales Application S.No.
Web Services
Description Car Booking service has two composite services Order Processing and Advance Payment Car is booked with a Car Dealer. The user decides on which car to purchase and books the order for the car with the dealer. Advance Payment for the car is paid to the dealer. Payment is routed through Bank.
Car Booking 1
Car Booking Advance Payment
Insurance Booking 2
Insurance Processing Insurance Payment
Car Delivery 3
Car Payment Registration Road tax Payment
Insurance Booking is a composite service which covers Insurance Processing and Insurance Payment. Insurance is arranged for the car with the insurance agent. The Insurance Agent is paid the Insurance Amount and the payment is processed through Bank.
Car Delivery is a composite service which covers Car payment, Registration and Road tax payment. Payments are routed through Bank The Car Dealer is paid the Purchase Amount after subtracting the advance payment. The payment is processed through Bank. The car is registered in the name of the owner The tax payment for the car is paid through Bank
Faults have also been simulated in inputs provided to the web service and also in the results returned by the web service to test for run-time fault detection in each of the web services that form the composite service. BPEL defines activities as the basic components of a process definition. A sample code snippet for static composition of Car Booking web service is given in Table 4. The partner roles of the Car Booking service are Order Processing and Advance Payment. Table 4. Sample code for Static Composition
For semi dynamic composition, the service is specified using service key and business key. Sample code snippet for Insurance Booking web service is given in Table 5.
Smart Computing Review, vol. 5, no. 5, October 2015
477
Table 5. Sample code for Semi Dynamic Composition
The sample OWL_S process flow for dynamic composition for Car Sales application is given in Figure 4.
Figure 4. OWL-S Process flow for Car Purchase Various input and outputs faults have been introduced and execution fault handling has also been tested. A sample policy which expresses constraints in User Name; in which name the car is registered is given in Table 6. The policy indicates that the user name cannot exceed 50 characters. The minimum length is specified as 5 characters. The name can contain alphabets a-z, A-Z. Numbers and special characters are not allowed in the name.
478
Jayashree et a.l.: Run Time Fault Detection System for Web Service Composition and Execution Table 6. Sample Policy giving Constraints for User Name
The insurance processing web service will return the insurance number as output of the web service. A sample policy which expresses constraints in the format of Insurance Number is given in Table 7. The policy specifies that the first character is an alphabet in the range A-Z, the second character is an alphabet in the range a-z, positions 3 -8 are numbers in the range 0-9 and the number ends with three characters in the range a-z. Table 7. Sample Policy giving Constraints for Insurance Number
■ Experimental Results Faults were injected in the web services to test the proposed architecture. IBM Functional Tester tool was used to analyze the efficiency and performance of the proposed model. The implementation detail is given in Table 8. Response time is the elapsed time between invoking of the composite web service by the user to obtaining the results after execution of all the component web services. The response times for web services without errors has been given in Figure 5 with and without the use of CSFH. The response time has been plotted for static, semi dynamic and dynamic composition and execution of the web services. As there is an overhead associated with CSFH processing, the response time shows an increase for all the three types of composition when CSFH is used.
Smart Computing Review, vol. 5, no. 5, October 2015
479
Table 8. Implementation details Number of Web services
20
Number of service providers
10
Number of service clients
10
Number of web service execution instances
100
Number of composition and run-time faults
60
Response time is the elapsed time between invoking of the composite web service by the user to obtaining the results after execution of all the component web services. The response times for web services without errors has been given in Figure 5 with and without the use of CSFH. The response time has been plotted for static, semi dynamic and dynamic composition and execution of the web services. As there is an overhead associated with CSFH processing, the response time shows an increase for all the three types of composition when CSFH is used.
Response Time(milliseconds)
4000 3500
Static Composition Without CSFH
3000
Static Composition With CSFH
2500 2000
Semi Dynamic Composition Without CSFH
1500
Semi Dynamic Composition With CSFH
1000
Dynamic Composition Without CSFH
500 0 1
8
15
22
29
36
43
50
Dynamic Composition With CSFH
Web Service Instances
Figure 5. Response time of Web services without Faults using all three methods
Response Time(milliseconds)
3500 3000 2500 2000
Fault Processing Time With CSFH
1500
Error Reporting time without CSFH
1000 500 0 1
8
15
22
29
36
43
50
Web Service Instances
Figure 6a. Fault Processing Time of Web services with Faults using static composition The processing time for handling faults in the web services has been compared with and without CSFH for all the three types of composition. The results obtained are given in Figure 6a, 6b and 6c for static, semi dynamic and dynamic composition. In the absence of CSFH, the default fault handler shows peaks in the response time when faults occur in the
480
Jayashree et a.l.: Run Time Fault Detection System for Web Service Composition and Execution
web services. CSFH not only detects the faults but also send meaning full messages to the user. The user can either correct the errors and resubmit the service request or decide to use another service which matches their functional requirements.
Response Time(milliseconds)
3500 3000 2500 2000
Fault Processing Time With CSFH
1500
Error Reporting time without CSFH
1000 500 0 1
8
15
22
29
36
43
50
Web Service Instances
Figure 6b. Fault Processing Time of Web services with Faults using semi dynamic composition
Response Time(milliseconds)
4500 4000
Static Composition Without CSFH
3500
Static Composition With CSFH
3000 2500
Semi Dynamic Composition without CSFH
2000
Semi Dynamic Composition With CSFH
1500 1000
Dynamic Composition Without CSFH
500 0 1
8
15
22
29
36
43
50
Dynamic Composition With CSFH
Web Service Instances
Figure 6c. Fault Processing Time of Web services with Faults using dynamic composition The overall response time was then calculated for all web services (with and without faults) for all the three types of composition. The graphs obtained are shown in Figure 7. The response time of the default fault handler without CSFH shows sudden increases in processing time when faults are detected. With CSFH, the processing time is more or less consistent for web services with and without faults.
Conclusion This paper presents the application of run-time monitoring to detect faults during composition and execution of composite web services. Fault handling for all three types of composition; static, semi dynamic and dynamic have been explained in detail. BPEL has been used to implement and test static and semi dynamic web services. OWL-S has been used to implement and test dynamic web services. Execution faults that occur in the input used to invoke the web service and in the output obtained from the web service for any of the partner services of the composite web service have also been implemented and tested. The meaningful error message would enable the user to understand where the fault has occurred and the reason for the fault. The user can make the necessary changes and resubmit the service request or decide to use another composite service which match their functional requirements.
Smart Computing Review, vol. 5, no. 5, October 2015
481
References [1] Alam, S, ‟Fault management of Web Services,” Thesis. 2009. [2] Alves,A, Arkin,A, Askary,S, Barreto,C,Bloch,B, Curbera,F,Ford, Goland,Y, Guízar,A, Kartha,A, Liu, CK,Khalaf,R, König, D, Marin,M, Mehta, V, Thatte,S, Rijn,V, Yendluri,P and Yiu,A, 2006, OASIS. Web Service Business Process Execution Language 2.0, URL: http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=wsbpe. [3] Alodib, M and Bordbar,B, A model-based approach to Fault diagnosis in Service oriented Architectures Seventh IEEE European Conference on Web Services. 2009. [4] Bratanis, K, Dranidis,D and Simons, A, 2010, An extensible Architecture for run-time monitoring of conversational web services, proceedings of the 3rd international workshop on monitoring, Adaptation and Beyond. Article (CrossRef Link) [5] Boumhamdi,M and Jarir, Z, 2012 An Approach to Support Monitoring and Recovery of BPEL Processes at Runtime International Journal of Computer Applications (0975 -8887) Volume 43– No.2. [6] Chan,KSM, Bishop,J, Steyn,J, Baresi L and Sam Guinea, 2007, A Fault Taxonomy for Web Service Composition,Service-Oriented Computing Workshops Pages 363-375. [7] Chan KSM and Judith Bishop, 2008, A Self-healing Composition Cycle for Web Services, World Wide Web Internet And Web Information Systems. [8] Charfi,A, Dinkelakery, T and Mezini,M, 2009 Plug-in Architecture for Self-Adaptive Web Service Compositions, IEEE International Conference on Web Services. Article (CrossRef Link) [9] Christensen, E, Cubera, F, Meredith, G and Weerawarana, S, 2001, World Wide Web Consortium (W3C). Web Services Description Language (WSDL), Version 1.1. March, 2001, available at http://www.w3.org/TR/wsdl. [10] Clement,L, Hately, A, von Riegen, C and Rogers, T, 2004, http://www.uddi.org/pubs/uddi_v3.htm. [11] Curbera, F. Duftler, M. Khalaf, R. Nagy, W. Mukhi, N. and Weerawarana,S, 2002, Unraveling the Web Services Web: An Introduction to SOAP, WSDL, and UDDI, IEEE Internet computing, vol. 6, pp. 86-93. Article (CrossRef Link) [12] D‟Mello,D,A, V.S.Ananthanarayana and Salian,S, 2011 A review of dynamic web service composition techniques.In:CCSIT 2011,part III,CCIS 133,85-97. [13] Halima,RB, Guennoun, K, Drira, K and Jmaiel,M, 2008 Non-intrusive QoS Monitoring and Analysis for SelfHealing Web Services The First IEEE International Conference on the Applications of Digital Information and Web Technologies, Ostrava : Czech Republic [14] Jayaprakash,R and Vimal Raja,R, 2010 Evaluating Web Service Composition methods with the help of a Business Application, International Journal of Engineering Science and Technology Vol. 2(7), 2931-2935. [15] Jayashree,K Sheila Anand, 2012, Policy Based Distributed Run Time Fault Diagnoser Model for Web Services, Proceeding of the second international conference on Advances in Computer Science and Information Technology pp 9-16 LNICST. [16] Mahbub,K and Spanoudakis,G, 2005, Run-time Monitoring of Requirements for Systems Composed of WebServices: Initial Implementation and Evaluation Experience, in Proceedings of International Conference on Web Services (ICWS‟05), pp. 257–265. [17] Martin, D , Burstein, M, Hobbs, J, Lassila, O, McDermott, D, McIlraith, S, Narayanan, S, Paolucci, P, Parsia, B, Payne, T, Sirin, E, Srinivasan, N ,Sycara, K, 2004 OWL-S Semantic Markup for Web Services”, W3C submission 2004, http://www.w3.org/Submission/OWL-S [18] Mitra, N, and Lafon,Y, 2007, World Wide Web Consortium (W3C), Simple Object Access Protocol, Version 1.2, available at http://www.w3.org/TR/soap12. [19] Moser,O, Rosenberg, F and Dustdar, S, 2008 Non-Intrusive Monitoring and Service Adaptation for WS-BPEL WWW 2008. [20] Poonguzhali,S, Sunitha,R and Aghila, G, 2011, Self-Healing in Dynamic Web Service Composition International Journal on Computer Science and Engineering(IJCSE) Vol. 3 No.5. [21] Schroeder,B, 1995 Online Monitoring : a Tutorial , Computing practices IEEE. Computing. Article (CrossRef Link) [22] Shne,A,A, Fuhrer,P and Pasquier,J,K, 2009 Web Services Orchestration and Composition Case Study of Web services Composition. [23] Srinivasan,N, Paolucci,M and Sycara, K, 2006, Semantic Web Service Discovery in the OWL-S IDE Proceedings of the 39th Annual Hawaii International Conference on System Sciences - Volume 06 Page 109.2.
482
Jayashree et a.l.: Run Time Fault Detection System for Web Service Composition and Execution
[24] Yu, X, Liu,X, Bouguettaya, A & Medjahed, B, 2007 Deploying and managing Web services: issues, solutions, and directions, The VLDB. [25] Zein O, K, and Kermarrec,Y, 2006, Static/Semi-Dynamic and Dynamic composition of Services in Distributed Systems Proceedings of the Advanced International Conference on Telecommunications and International Conference on Internet and Web Applications and Services.
