Article history:Received 17 February 2012Received in revised form 17 June 2013Accepted 26 June 2013Available online 16 July 2013
Keywords:Web service faultsFault diagnoserFault diagnosis modelWeb service policySOAP handler
Reliability is an important criterion to facilitate extensive deployment of web service technology for commer-cial business applications. Run-time monitoring and fault management of web services are essential to ensureuninterrupted and continuous availability of web services. This paper presents WISDOM (Web ServiceDiagnoser Model) a generic architecture for detecting faults during execution of web services. Policies havebeen proposed to describe the intended behavior of web services and faulty behavior would be detected asdeviations or inconsistencies with respect to the specified behavior. The model proposes the use of monitor-ing components in service registries and service providers to detect run-time faults during publishing,discovery, binding and execution of web services. An independent fault diagnoser is proposed to coordinatethe individual monitoring components and also act as a repository for the specified web service policies. Theproposed model has been tested with a sample web service application and the results obtained arepresented.
Web services are self describing, self contained and looselycoupled mechanism for program to program interaction over theInternet [1]. Web service technology is being increasingly used inmany commercial applications like online reservation, auction,stock trading and banking. Web services are based on eXtensibleMarkup Language (XML) standards and are supported by standardprotocols like Simple Object Access Protocol (SOAP) for messageexchange, Web Services Description Language (WSDL) for interfacedescription and Universal Description Discovery and Integration(UDDI) for service discovery [2,3]. It facilitates the delivery of busi-ness applications as web services are accessible to anyone, anytime,at any location and using any platform.
Web Service Management System (WSMS) is a comprehensiveframework for managing web service lifecycle which covers the de-velopment, deployment, publishing, discovery, composition, moni-toring and optimizing access to web services [4]. As web servicesare being extensively deployed for business applications, the reli-ability of the services provided becomes an important criterion toenable the usage of such services. Continuous monitoring and faultmanagement of web services are essential to ensure uninterruptedand continuous availability of web services. Traditional fault man-agement tools cannot automatically monitor, analyze, and resolvefaults in web services. As web services are distributed in nature, it
is hard to trace the flow of transactions when a large number ofservices, supplier and technologies collaborate together to performan activity [5]. Thus monitoring of web services becomes more diffi-cult when compared to monitoring a centralized application. Tools,methodologies and techniques need to be specially developed tosupport and automate the fault management efforts [6].
This paper describes WISDOM (Web Service Diagnoser Model) ageneric architecture for monitoring and detecting faults duringrun-time execution of web services. The rest of the paper is organizedas follows. Section 2 discusses the related work and Section 3 pre-sents WISDOM, the proposed architecture for web services run-timefault detection. In Section 4, the implementation and experimentalresults for a sample web service application are discussed. Section 5presents the conclusion and future work.
2. Related work
Monitoring is used as a verification technique to detect run-timeerrors. Run-time monitoring has been extensively studied in differentareas of computer science, such as distributed systems, requirementengineering, programming languages, and aspect oriented develop-ment [7,8]. Beth A. Schroeder et al. [9] have stated that monitoringcan increase application dependability. They have described monitor-ing systems as external observers that gather information about thefunctioning of the applications. Such information can then be usedfor correctness checking, performance enhancement, security anddependability.
On-line monitoring systems not only gather information duringexecution of the application but also process the information to respond
in a timely manner to application events to provide increased robust-ness, adaptability and fault tolerance. Delgado et al. [10] have presenteda taxonomy of run-time software fault-monitoring approaches. Faulthas been described as an incorrect state during the execution of thesoftware that can lead to a software failure. It has been described as adeviation from the required or intended behavior of the system. Thetaxonomy presents the classification of elements in a monitoring sys-tem; a specification language to define the monitoring properties, anevent handler to capture and communicate monitoring results and themonitoring mechanism to handle the faults and oversee the program-ming execution. The issues addressed have been taken into consider-ation while designing the proposed model for run-time monitoring ofthe behavior of web services during execution.
There has been considerable work related to development and de-ployment ofweb services.Management ofweb services and particularlyfault management is not yet a well-defined area and require consider-able research focus. Fault management includes fault detection, faultisolation and fault repair. Robinson [11] has proposed the integrationof software requirements analysis with execution monitoring to ad-dress web service monitoring. He has proposed the use of individualmonitor servers at each site to trackweb service traffic. A global integra-tivemonitor is to be used to control the individualmonitors and processthe received information to provide real-time alerts. Requirements areexpressed using Knowledge Acquisition in autOmated Specification(KAOS) which does not provide enough information on monitoringand the transformation from specification to monitoring code has notbeen clearly addressed.
Benharref et al. [12] have presented architecture for detectingfaults in web services based on passive testing. They have proposedthe use of observers at service providers, clients and third parties in-terested in the observation. They have proposed that observers bedesigned and published as web services. The observers can be in-voked by the client or third parties with information like the locationof the service to be observed, its specification and when and what toobserve. The model was used for the detection of only input/outputfaults in web services.
Zheng Li et al. [13] have developed a framework for monitoringthe run-time interactions of web services. The run-time behavior ismonitored and validated against pre-defined interaction constraintsexpressed using Finite state automata. The framework involves inter-ception of service messages and conformance checking with theservice constraints.
Farzaneh Mahdian et al. [14] have presented an approach to detectfaults at the architecture level of service oriented systems and have ex-tended the formal SOA coremeta-model to support fault tolerance. Newcomponents, namely, “policy”, “selector”, “monitor” and “compositor”have been introduced to monitor faults in the different parts of the ar-chitecture. The Selector component chooses a suitable service in thegiven service category and if the requested service is not found thenthe Compositor component composites two ormore services to providethe required service to the user. The Monitor component was designedto detect only three types of faults namely TimeOut, NoServiceFoundand BindingDenied.
QiangxiangWang et al. [15] have introduced an online monitoringapproach for web services requirements. The proposed approach in-cludes a pattern based specification of service constraints that corre-spond to service requirements, and a monitoring model that coversfive kinds of system events relevant to client request, service request,service response, application and resource and management.
It can be summarized from the above discussions that the earlierwork has primarily been with respect to detecting errors in inputand output of web services. In the proposed approach, fault detectionpertaining to publishing, discovery, binding and execution of web ser-vices have been considered. Execution fault detection covers errors inthe request given to web services and also errors in the reply from theweb services. In addition, different types of SOAP processing errors
have also been included in the fault detection process. The proposedmodel uses policies to express the intended behavior of web services.Policies provide a flexible approach to enforce and communicate var-ious types of rules and requirements of the web services.
3. Proposed architecture for web service fault diagnoser
Service-Oriented Architecture (SOA) consists of the three keycomponents, namely, Service Consumer (SC), Service Registry (SR),and Service Provider (SP) which interact with each other to publish,discover and execute web services. Service providers create and de-ploy their web services. Service providers publish their web servicein service registries which act as repository of web services. Serviceusers look up these directories to obtain details of available web ser-vices. The users then bind and execute their selected web servicedeployed by the service provider.
Web services are loosely coupled and dynamic in nature. Web ser-vices need to connect different servers and clients systems that runon different hardware and software platforms. To ensure availabilityand reliability of these web services, it is necessary to ensure thatthese services behave correctly at run-time. Faults can occur duringall or any of the interactions between the key players [16]. Monitoringthe web service interactions at run-time would enable faults to be de-tected and handled appropriately to avoid system failures. WISDOMhas been proposed as a generic architecture for run-time monitoringof web service interactions and handling fault detection. An extendedversion of WISDOM (Web Service Diagnoser Model) [6], the proposedmonitoring architecture is given in Fig. 1.
A key aspect of web service monitoring is the interception of mes-sages exchanged between the key players, namely, service providers,service registries and service users. Different methods are available tointercept such messages, namely, wrappers, network proxies andhandlers [17].
Software wrappers are used to encapsulate the monitored serviceand such wrappers can be used for a variety of purposes. For on-linemonitoring, the wrappers are primarily used to intercept the mes-sages sent to the actual service. The wrapper is used to process theservice request–replies and monitor for errors. To be transparent tothe user, the wrapper interface has to match the interface of the ser-vice being monitored and a separate wrapper has to be designed forevery service being monitored. In proxy based interception, networknodes are designated as proxies to handle the message exchanges.The transport protocol has to support the interception of the mes-sages and the proxy server is used to process and monitor therequest–replies.
In the proposed monitoring architecture, handlers have been usedto intercept the message exchanges. SOAP protocol is widely used asthe messaging framework for web service interchanges and SOAPprovides support for the use of handlers to intercept the web servicemessage exchanges. Handlers have been implemented to capture therequest and replies between the user and web services. The handlershave been designed to delegate the validation of such messages to in-dependent Monitoring Components (MCs) located in the service reg-istries and service providers.
Faulty behavior can be defined as deviations or inconsistencies withrespect to the specified behavior of web services [18]. Policies are pro-posed to describe the intended behavior of web services. Policies sup-port standard assertions and provide a simple method to express thecapabilities, requirements and characteristics of web services. Web ser-vices are frequently modified to suit the changing needs of the users.Policies make it easy to make necessary changes in the specificationsof web services and facilitate its dynamic update. The interaction con-straints would need to be specified by the service provider for the cor-rect execution of their web services. Policies can also be used to defineinteraction constraints with respect to publishing and discovery ofweb services. WS-Policy [19], a web service standard, is proposed for
Policy database Service usage
Log
Faults Log
Service Client
Faults, Usage data
Policy information
Monitoring Component (MC)
Web Service Execution Environment
Faults, Usage data
Publish
Service URL
Policy Information
Policy Cache
Bind
Faultmessage
Results
Faultmessage
Service enquiry
Policy Request
Policy Response / Not Found
Policy Response/ Not Found
Policy Request
Policy Cache
Fault Diagnoser (FD)Monitoring
Component (MC)
Registry ProcessorSERVICEREGISTRY
SERVICEPROVIDER
Fig. 1. WISDOM — Web Service Diagnoser Model for fault detection.
156 K. Jayashree, S. Anand / Computer Standards & Interfaces 36 (2013) 154–164
expressing the specifications of the web services. WS-Policy is a W3Crecommendation that provides a general purpose model to describeand communicate the policies of web services. The capabilities and con-straints are expressed as a set of specifications using XML syntax.
MCs are the individual components that monitor the local web ser-vice interactions. An MC is implemented in each service registry thatprovides the directory for listing the web services of service providers.MCs are also located in each service provider where the web servicesare deployed. Fault Diagnoser (FD) is the common independent exter-nal entity that is used to coordinate the individual monitoring compo-nents. FD acts as the repository of web service policies and providesan interface for service providers to create and maintain their web ser-vice policies. Changes in web services would require modifications intheir corresponding policies. FD provides a common interface for easyupdate of the policy changes. Service provider may choose to list theirweb service with multiple service registries. However, the policyneeds to be defined only once for a web service and can be accessedby multiple MCs located in these service registries.
The MCs in service registry and service providers do not maintainthese policies but access FD to obtain the policy of the web servicesbeing monitored. This would enable them to always access the latestupdated or current policies. MCs would use the policy information toverify if the service run-time interactions are in conformance to theconstraints specified in the policies. MCs located in the service regis-tries analyze the web service publishing requests of service providersfor faulty behavior. It also manages fault handling of web servicesearch and discovery requests of users. MC located in each serviceprovider would obtain the policy information from FD to detect errorsthat occur during binding and execution of the web services.
A local cache has been proposed to maintain details of web servicepolicies recently accessed by the MCs. MC would first check the local
cache for the policy information. If the information is available then itwould proceed with verification and fault detection. Otherwise, itwould send a request to the FD giving the web service details. FDwould retrieve the policy details from the stored policy databaseand return the relevant policy information. The interaction betweenthe monitoring components and the fault diagnoser is depicted as asequence diagram is given in Fig. 2.
As seen from Fig. 2, MCs also communicate the usage and fault de-tails of web services to FD, which maintains these statistics in sepa-rate databases. If a web service policy has changed, FD would alertthe MCs which maintain the policy in their local cache, to requestfor the current policy information. As future work, it is proposed todevelop an analyzer component which would use the fault and webservice usage data to evaluate the performance and reliability of theweb services.
3.1. Faults detection
Web services are described using WSDL files which contain thefunctional specifications of the services. Web services are discoveredusing UDDI. SOAP is used as the communication protocol for messageexchanges. Faults that occur during publishing, discovery, bindingand execution of web services can be detected by the proposedarchitecture.
Services are published to make the service description available inthe service registry. The service users would be then able to searchand find the services that match their requirements. Faults occur dur-ing publishing because the service description given is incorrect or isincomplete. The service description includes a description of the ser-vice business function, information about the provider and technicaldetails for invoking and executing the web service. The web service
Monitoring Component
Fault Diagnoser
1. Check local cache for Policy details
2. Request Policy information
3. Retrieve from Policy database
4. Send Policy information
5. Verify web service behavior
6.Send detected faults
7. Send usage of web services
8. Stores faults and usage of web services
Fig. 2. Sequence diagram of interactions between monitoring components and fault diagnoser.
information is stored in the form of white, yellow and green pages inthe registry. To publish a service in the service registry, the providerprovides details that include publisher name, service name, businessname and URL of the web service WSDL. Faults that can occur includeformat error and content error. Format error occurs if the service de-scription details are incomplete or in incorrect order and contentfaults occur due to errors in the given service details. Publishingerror can also occur due to network or server error. The faults detect-ed by the proposed architecture are given in Fig. 3.
Service discovery is the process to query the registry to obtain in-formation about available services. Faults can occur during the searchprocess or when the service details are returned to the service client.The faults that are detected during the discovery process are given inFig. 4.
Service Not Listed fault will occur when the relevant service is notavailable in the registry. Incorrect Search Criteria occur when theuser specifies the incorrect service name or other details. FaultyLookup Service error occurs when the details given does not matchthe specifications of the web service. Timed Out error occurs due toserver or network error.
Service binding is to contact and invoke the service based on theservice description information obtained during the discovery pro-cess. The faults that are detected during the binding process aregiven in Fig. 5.
To bind to a particular service, the user has to specify the portnumber, target namespace, discovery URL, operation name, porttype, and service name. Authentication Failure error occurs whenthe user cannot be properly identified. Authorization Denial occursif the user is not permitted to use the service. Error can also occur ifthe service details are given incorrectly. For instance, the port number
Publishing Fault Content Fault
Timed Out
Format Fault
Fig. 3. Publishing faults detected.
could be specified wrongly or the service name could be incorrect.Timed Out error occurs due to server or network failure.
Execution fault occurs when the service does not execute correctly.Execution errors occur due to errors in input or processing error andthe results sent to the user would be incorrect. The constraints in spec-ifying the inputs and outputs to/from theweb services are given as XMLtags in the policy. These constraints would have to be specified by theservice providers of the individual web services. Standard tags havebeen defined for specifying constraints in the input and output param-eters used to invoke the web services as shown in Fig. 6.
Some of the constraints for numeric, alphanumeric and date usedin the input and output parameters are given in Table 1.
Patterns can be used to check for permitted combination of values.For example, a pattern “[1][0–5][0–9]”, would indicate that the nu-meric value should start with 1, the next number should be in therange of 0–5, and the last number should be within 0–9. Pattern“[a–zA–Z][a–zA–Z][a–zA–Z]” would indicate that the alphanumericvalue should accept three characters in the range A–Z or a–z. Pattern
Authorization Denial
Timed Out
Faulty Service details
Authentication Failure
Binding Fault
Fig. 5. Binding faults detected.
Execution Faults
Input Constraints
Numeric constraintAlphanumeric Constraint
Date ConstraintPattern Value Constraint
Output Constraints
Numeric constraintAlphanumeric constraint
Date constraintPattern Value Constraints
SQL ExceptionClass Not Found Exception
Illegal Access Exception
Timed Out
Fig. 6. Execution faults: Input and output errors.
Table 2Fault class and codes.
Fault class Fault code Fault ID Description
158 K. Jayashree, S. Anand / Computer Standards & Interfaces 36 (2013) 154–164
“[a–zA–Z0–9]{8}” indicates that the length is 8 and each of the char-acters can be in the range of A–Z or a–z or 0–9.
The constraints can be easily extended to include other types ofparameters like Email ID, URL etc. The policy can also be extendedto also cover other aspects of web service specifications andrun-time errors. In addition to the above, SOAP processing errorshave also been detected as explained in the next section.
3.2. Fault classification and coding
Faults have been classified under major classes and individualfaults are classified under each major class. The faults are classifiedunder the four major classes of publishing, discovery, binding and ex-ecution. Under each major class, each individual fault is given aunique fault code or ID. The list of fault and their codes are given inTable 2.
Additionally SOAP processing errors that relate to invalid XMLdocument, missing tags, duplicate tags and other syntax errors havealso been detected. A sample of these errors is given in Table 3.
3.3. Fault logs and service usage logs
The service usage and fault details are maintained by the FD alongwith date and time stamp. The data can be analyzed to design suitablerecovery actions. The Quality of Service (QoS) rendered; availabilityand reliability of web services can be determined by analyzing theusage and fault details. Other QoS parameters like security can alsobe determined by analyzing the data in these logs.
4. Implementation and results
A sample web application from the Travel agency domain has beenused for implementing and testing of the fault detection process. An air-line reservation application has been implemented with web servicesfor enquiry, reservation and cancellation of flight tickets. Web serviceswere developed for Flight Enquiry, Ticket Availability, Ticket Reserva-tion, Reservation Status Enquiry and Ticket Cancellation.
Table 1Numeric, alphanumeric and date constraints.
Numeric constraints Alphanumeric constraints Date constraints
IBM Rational Application Developer IDE has been used to developthe web services. jUDDI (JAVA Universal Description Discovery andIntegration) was used to configure the web service registry. All ser-vice communication has been implemented using SOAP protocol.SOAP handlers have been used for intercepting SOAP messages andpassing the details to the MCs for fault detection.
FD is the core component that manages and provides web serviceinformation to the MCs. FD was developed using JAVA. WS-Policystandard is used for creating the policies maintained in XML formatat FD. A web service of a service provider could be listed in many ser-vice registries and MCs access the FD to retrieve the policy informa-tion and check for faults as deviations from the intended behavior.FD maintains the service usage details and data about faults thathave occurred during execution of the web services. Whenever afault is detected, a fault message is sent to FD by MC giving detailssuch as web service name, service provider name, date and timestamp and fault details like code and ID. If the web service action issuccessful, then usage details like service name, service providername, service client details, action (publishing, discovery, binding,execution) etc. are sent to FD. The fault details are stored in a fault da-tabase and service usage details are stored in a separate service usagedatabase created using MySQL.
4.1. Policy generation tool
A tool has been developed using JAVA for capturing the policy infor-mation and generating the policy in the prescribed format. The tool canbe used to generate policy tags for monitoring SOA faults in publishing,discovery and binding using WSDL and service details published in thejUDDI registry. Option has been provided to accept the constraints inthe execution of web services and generate the policy; such constraintswould need to be specified by the web service provider. Policies are
Publishing 100 101 Format Fault102 Content Fault103 Timed Out
Discovery 200 201 Service Not Listed202 Incorrect Search Criteria203 Timed Out204 Faulty Lookup Service
Execution 400 401 Incorrect Input402 Incorrect Output403 Timed Out
has Input Fault ()
handle Request ()
Init
handle Response ()
Service Provider
No
Yes
Fig. 8. Input fault processing.
Table 3SOAP processing errors.
SOAP processing errors(fault code 500)
XML document is invalidCode includes a misplaced tagThe code includes an invalid tagCode is missing an ending tagCode is missing an opening tagCode includes an incorrect tagCode includes a starting or endingtag that is missing the closing angle bracketThe code includes an attribute with openingquotes but no closing quotes
generated separately for each web service. The generated policies werestored in the FD. Some sample screen snapshots of the tool are given inFig. 7.
The tool provides theflexibility to copy and duplicate policies forwebservices. For example, if a service provider offers similar policies for webservice offerings, then the policy can be generated once; and duplicatedandmodified for other services. As the service offerings generally changefrequently, the tool makes it easy to carry out the modifications.
4.2. Monitoring component
SOAP handlers have been developed using JAX-RPC. TheMonitoringcomponent is implemented using the SOAP handler methods Init(),handleRequest() and handleResponse().
a) WISDOM Policy Generation Tool : Menu Form
c) WISDOM Policy Generation Tool : Input Constraints Form d
4.2.1. Input faults monitoringThe block diagram of the processing is given in Fig. 8.In the Init() method the SOAP message is parsed to obtain the ser-
vice name, business name and the WSDL URL. The FD is accessed byMCwith theWSDL details to obtain the policy information. The policyinformation is stored in the policy cache. The SOAP message input pa-rameters are parsed in the handleRequest() method. The processingsteps for comparing the input parameters with the policy informationare given as a flowchart in Fig. 9.
) WISDOM Policy Generation Tool: Output Constraints Form
) WISDOM Policy Generation Tool : Web Service Details Form
Web service details form. c: WISDOM policy generation tool: Input constraints form.
Not Violated
No
Yes
Violated
Parse Request SOAP message
Parse WSDL File: Get parameterGet Policy URL
Check constraints with input value Generate Fault
handle Response ()
Extract the input from SOAP Body
Retrieve policy information from FD
Extract the constraints for each input
Next input value
Client Request
Fig. 9. Processing steps in handleRequest() method.
160 K. Jayashree, S. Anand / Computer Standards & Interfaces 36 (2013) 154–164
When a fault is detected in the client request(), a SOAP fault iscreated with the appropriate meaningful error message and sent tothe client through the handleResponse() method.
4.2.2. Output faults monitoringThe block diagram of the processing is given in Fig. 10.The output after execution of the web service is received by the
handleResponse() method. The SOAP message is parsed to obtain theresults of the web service. The policy information is retrieved from thepolicy cache and compared with the results obtained. The processingsteps at the handleResponse() are given as a flowchart in Fig. 11.
4.2.3. Publishing fault handlingPublishing faults are detected when a service provider tries to pub-
lish a service giving details like publisher name, publisher ID, servicename and business name. A sample policy conforming to UDDI 2.0 ver-sion for expressing constraints in publisher name is given in Fig. 12.
As an example, let the service provider try to publish a service withthe publisher name given as “@hariharan”. A SOAP request message
handle Response ()
has Input Fault ()
Generate SOAP Fault and sent to the Client
No
Yes
Fig. 10. Output fau
would be generated and the SOAP handler would intercept thismessage and pass the details to the MC in the service registry. Theintercepted data is compared with the publisher name pattern givenas [a–zA–Z0–9]* in the policy. Fault would be detected as the given pub-lisher name contains@,which violates the pattern. In the absence of theFD and MC, a generic error that the service cannot be published wouldbe returned and the user would not get information on the exact errorin the given input. This is an example of content fault. Similarly theother types of faults given in Table 2 can be detected.
4.2.4. Discovery fault handlingWhen a service client or user wishes to search for a web service,
the search criteria is sent to the service registry. To discover a service,the user has to provide the details of business name and service namein the given order. The SOAP message is intercepted by the SOAP han-dler and passed to MC in the service registry for fault handling. Forexample, the user wants to book a plane ticket and tries to check ifthe service exists by giving the query as “FlightReservation”. Thiswould be reported as a fault by MC as business name has not been
has Output Fault ()
Result sent to Client
Yes
No
lt processing.
Violated
Processing error
Parse WSDL File: Get parameters, Get Policy URL
No
Retrieve policy information from FD
Extract the constraints for each output
Check constraints with output values
Next value
Yes
Send response to client
No
Generate Fault
WS execution output
No
Yes
Parse SOAP Message
Not Violated
Fig. 11. Processing steps of handleResponse() method.
specified. If the query is formed correctly, the enquiry would be sentto the UDDI Registry for processing. However, if the service“FlightReservation” does not exist, then the error sent by the registryis processed by MC and the error “Invalid Service Name” would bereturned to the user. In the absence of FD and MC, a generic error ofIncorrect Search Criteria or service cannot be found, would havebeen returned to the user.
4.2.5. Binding fault handlingTo execute a service, the user tries to bind with the web service at
the service provider using the service details obtained during the dis-covery process from the service registry. If binding is successful, theuser tries to execute the web service by providing the input data.For some of the services, authentication may be mandatory and thiswould be indicated by the service provider in the binding policy of
Fig. 13. Sample policy giving constraints for authentication parameter.
162 K. Jayashree, S. Anand / Computer Standards & Interfaces 36 (2013) 154–164
the particular service. A sample policy generated for expressing theconstraints of user name and password used for authenticationduring binding of the service “Reservation” is shown in Fig. 13.
As per the sample policy, the user has to specify the details such asuser name and password for authentication during the binding pro-cess. The user name and password are appended to the requestheaders and the binding handler invokes Web Services Security(WSS) Agent for authentication. The message returned by WSS isprocessed at MC. If the authentication details are not present, anerror would be generated to the user indicating that such details aremandatory. The handler would send Authentication Failure messageto the user to indicate that there was an error either in the givenuser name, password or both. In the absence of the proposed handler,error message, such as, “http response code is 403” would bereturned, which may the user perplexed.
4.2.6. Application fault handlingFault detection in the input and outputs to web service is
explained. A sample policy generated for expressing constraints inthe input parameter “flight number” is given in Fig. 14.
Flight number is to be given as input for booking tickets in a par-ticular flight for a given date and time. For example, the user givesthe flight number as “abc444” and the SOAP handler intercepts thedata and passes the details to the MC in the service provider. Theintercepted data is compared with the policy information of flightnumber. Fault is detected because as per policy, the third characterhas to be a number and not an alphabet.
If the execution does not happen correctly, then there could be er-rors in the results returned by the service. The errors in executioncould be due to various reasons, such as, database connectivity
Fig. 14. Sample policy giving constraints for flight number.
error, SQL exceptions, and error in output data returned. The erroris trapped by the handler and meaningful message is sent to theuser. For instance, booking for a particular flight is permitted only30 days in advance of the flight date. Hence, if the user tries to booka ticket before the 30 day period, there would be no correspondingentry in the database and SQL exception error would be thrown.With the handler, it is possible to trap the error and give a meaningfulmessage to the user that advance booking is not permitted, due to theconstraint of 30 days with respect to the scheduled date of flight.
To give another example, if “KF4564S001” reference is returned bythe Reservation service, then MC would be able to detect an error inthe execution as the reference number does not match the pattern[[A–Z][A–Z][0–9][0–9][0–9][0–9] [0–9][0–9][0–9][0–9]] given in thepolicy. The presence of “S” in the output is an error as a digit in therange of (0–9) should have been present.
4.2.7. SOAP Processing ErrorsSOAPFaultException error is raised for errors in the SOAP message
received at the service provider or service registry. Such faults couldoccur for a number of reasons such as version mismatch and errorin the SOAP protocol software. MC would trap such errors and sendmeaningful messages to help the user to correctly identify the actualerror.
4.3. Experimental results
Faults were injected in the web services to test the proposedarchitecture. The implementation details are given in Table 4.
IBM Functional Tester tool was used to analyze the efficiency andperformance of the proposed model. The response time for web
Table 4Implementation details.
Number of web services 20Number of service providers 5Number of service clients 10Number of web service execution instances 100Number of publishing faults 12Number of discovery faults 10Number of binding faults 6Number of execution faults 22SOAP errors 8
0
500
1000
1500
2000
2500
3000
1 8 15 22 29 36 43 50
Web Services Instances
Web
Ser
vice
s R
espo
nse
Tim
e (m
illis
econ
ds)
Without FD
With FD
With FD & Policy Cache
Fig. 15. Response time of web services without faults.
services was plotted for correct web services, that are services with-out faults and the results are shown in Fig. 15.
It can be seen from the chart that the response time rightly increaseswith the introduction of FD as there is an overhead associated with theprocessing at MCs and FD. It can also be noted that the introduction oflocal policy cache greatly reduces the response delay. It was assumedthat 50% of the required policies were available in cache and theremaining policies were retrieved from FD.
The processing time for handling faults in the web services by theimplemented fault handler is given in Fig. 16.
This has been compared with the time taken for processing errorsby the default fault handling mechanism of SOAP. It can be observedthat the time taken for handling faults by the proposed FD comparesfavorably with the default fault handler. Additionally, the proposedmodel would send meaningful messages identifying the exact causeof errors. The user would find it easy to correct the errors andre-submit.
Fig. 17 shows the total elapsed time from query submission to userreceiving the response for all web services; correct and faulty services.
It can be seen from the chart that the response time without FDshows sharp increase in processing time when errors are present.The response time curve with FD is more or less flat showing a steadyprocessing time. It can be further observed, that there is marked im-provement in performance when policy cache is introduced. It wasonce again assumed that 50% of the required policies were availablein cache and the remaining policies were retrieved from FD.
4.3.1. Comparison and discussionA comparison of the proposed work with some of the key related
work is presented in this section. Run-time monitoring approach has
0
500
1000
1500
2000
2500
1 8 15 22 29 36 43 50
Web Services Instances
Web
Ser
vice
s R
espo
nse
Tim
e (m
illis
econ
ds)
Fault Processing Time
With FD
Error Reporting time
without FD
Fig. 16. Fault processing time of web services with faults.
been adopted in the proposed work to detect faults in web services, asit has been conclusively established that monitoring increases the de-pendability and reliability of applications.
Fault management includes fault detection, fault isolation andfault repair. The proposed work is focused on fault detection. The re-quired behavior of web services has been expressed using policies asthey offer a flexible and easy method to express the intended behav-ior of web services. Policies enable dynamic changes in the requiredspecifications to cater to the changing needs of web services. Thewell known and universally accepted WS-Policy standard has beenused to express the constraints in the web services.
Benharref et al. have presented a web service based architectureusing observers for detecting faults in web services. Their proposedmodel was tested using the FSM model. Results were presented onlywith respect to input and output faults. The proposed model perfor-mance was been compared with the fault detection architecture ofBenharref et al. Benharref architecture was implemented by extendingthe standard WSDL to introduce tags giving the expected input andoutput data in terms of data types and formats.
The proposed work, as explained, uses policies to indicate theintended behavior of web services interactions between the threekey components. The proposed system was able to effectively detectthe injected faults in publishing, discovery, binding and execution ofweb services. The breakup of faults is shown in Fig. 18.
Delgado et al. have developed taxonomy for run-time softwarefault-monitoring. They have analyzed run-time monitoring but havenot dealt with the implementation issues. Farzaneh Mahdian et al.in their work have listed the different types of faults in SOA, butonce again, have not implemented their idea.
Zheng Li et al. have presented a framework for monitoring run-time interaction of web services. Their work aims at expressing the
0
5
10
15
20
25
Publ
ishin
g fa
ults
Discov
ery fa
ults
Bindi
ng fa
ults
SOAP
Mes
sage
Erro
r
Execu
tion fa
ults
No
of f
ault
s Id
enti
fied
Proposed Architecture
Benharref Architecture
Fig. 18. Faults identified.
164 K. Jayashree, S. Anand / Computer Standards & Interfaces 36 (2013) 154–164
behavior that services can provide. OWL-S has been used to specifythe semantic behavior of individual services with run-time validationof behavioral properties of the web services. In the proposed ap-proach, instead of trying to express the full behavior of the services,policies have been used to express the required behavior of servicesusing constraints, and faults have been detected as deviations fromthe intended behavior.
Mahbub and Spanoudakis [20] have used BPEL and Event Calculusto develop their monitoring framework for composite web services,but have not considered individual web services.
5. Conclusion and future work
Faultmanagement is one of the crucial areas ofweb servicemanage-ment. This paper presents a generic architecture for run-time servicemonitoring and validation to detect faults as violations in the intendedbehavior of web services. Policies have been used to express therun-time constraints for proper execution ofweb services. A policy gen-eration tool has been developed to create policies in the web servicestandard WS-Policy. The requirements and constraints are expressedas a set of policy assertions using XML syntax. Monitoring componentsare deployed on the web service entities: service registry and serviceprovider; to monitor the message exchanges. SOAP handlers havebeen used to intercept the SOAPmessageswhich are analyzed for faultybehavior using the stored policy information. The proposed model hasbeen tested using a sample web service application with multiple ser-vice providers and service clients. The results show that the fault detec-tion process was able to successfully detect the faults injected inpublishing, discovery, binding and execution of the web services. As fu-ture work, it is planned to extend the diagnoser model to detect othertypes of web service faults such as composition faults.
References
[1] M.P. Papazoglou, Web Services: Principles and Technology, Prentice Hall, 2007.[2] Michael P. Papazoglou, Willem-Jan van den Heuvel, Web services management: a
survey, IEEE Internet Computing 9 (6) (2005) 58–64.[3] Ramesh Nagappan, Robert Skoczylas, Rima Patel Sriganesh, Developing Java Web
web services: issues, solutions, and directions, The VLDB Journal 17 (2008) 537–572.[5] Sazedul Alam, Fault Management of Web Services, (Thesis), August 2009.[6] K. Jayashree, Sheila Anand, Policy Based Distributed Run Time Fault Diagnoser
Model for Web Services, LNICST, 2012. 9–16.[7] H.Madeiera, D. Costa,M.Vieira, On the emulation of software faults by software fault
injection, Proceedings of the International Conference on Dependable Systems andNetworks, IEEE, June 2000, pp. 417–426.
[8] Andrew Dingwall-smith, Anthony Finkelstein, From requirements to monitors by wayof aspects. (Available online at) http://eprints.ucl.ac.uk/842/1/4.7_aosd2002.pdf.
[9] Beth A. Schroeder, Online monitoring: a tutorial, Computing practices IEEE 29(6) (1995) 72–78.
[10] Nelly Delgado, Ann Q. Gates, Steve Roach, A taxonomy and catalog of run-time soft-ware fault monitoring tools, IEEE Transactions on Software Engineering 30 (12)(2003) 859–872, (TSE-0209-1203).
[11] William N. Robinson, Monitoring web service requirements, Proceedings of the11th IEEE International Requirements Engineering Conference 1090-705X/2003,2003.
[12] A. Benharref, R. clitho, R. Dssouli, A web service based architecture for detectingfaults in web services, IEEE 0-7803-9088-I/05, 2005.
[13] Zheng Li, Yan Ji, Jun Han, A run time monitoring and validation framework forweb service, ASWEC'06, Australian Software Engineering Conference, 2006,pp. 70–79.
[14] Farzaneh Mahdian, Vahid Rafe, Reza Rafeh, M.R. Zand Miralvand, Consideringfaults in service oriented architecture: a graph transformation based approach,IEEE, icctd, 2009 International Conference on Computer Technology and Develop-ment, vol. 1, 2009, pp. 179–183.
[15] Qianxiang Wang, Jin Shaw, Fang Deng, Yonggang Liu, Min Li, Jun Han, Hong Mei,An online monitoring approach for web services requirements, IEEE Transactionson Services Computing vol. 2 (4) (October-December 2009).
[16] Stefan Bruning, Stephan Weibleder, Miroslaw Malek, A fault taxonomy forservice-oriented architecture, High Assurance Systems Engineering Symposium10th IEEE 2007, 2007.
[17] Konstantinos Bratanis, Dimitris Dranidis, Anthony J.H Simons, An extensible ar-chitecture for run-time monitoring of conversational web services, MONO10,Proceedings of the 3rd International workshop on Monitoring, Adaptation anBeyond pages 9-16 ACM, New York, USA, 2010.
[18] Algirdas Avizienis, Jean-Claude Laprie, Brian Randell, Carl Landwehr, Basicconcepts and taxonomy of dependable and secure computing, IEEE Transac-tions on Dependable and Secure Computing vol. 1 (1) (January-March2004).
[19] Asir S. Vedamuthu, David Orchard,MaryannHondo, Toufic Boubez, Prasad Yendluri,Web Services Policy 1.5—FrameworkW3CWorking Draft 31 July 2006, http://www.w3.org/TR/2006/WD-ws-policy-20060731.
[20] Khaled Mahbub, George Spanousdakis, Run time monitoring of requirements forsystems composed of web services: initial implementation and evaluation expe-rience, ICWS2005, Proceedings International conference on web services, vol. 1,11-15 july 2005, pp. 257–265.
Dr. Sheila Anand is a Senior Member of IEEE and mem-ber of ACM. She is an Engineer by qualification, havingdone her Doctorate in the area of Information securityfromAnna University, Chennai and Masters in ComputerScience Engineering and Bachelors in Electronics &Communication Engineering from Madras University.She holds many professional qualification and certificationsincluding CISA, CSQA and CISM. She is presently the Deanof (Research) Computer Studies at Rajalakshmi EngineeringCollege, affiliated to Anna University Chennai. Her researchinterests include information security, sensor networks andpervasive computing.
Ms. K. Jayashree is a Research Scholar in Anna University.She has completed her Masters in Embedded SystemTechnologies from Anna University and Bachelors inComputer Science and Engineering from Madras University.Her areas of interest include computer networks and distrib-uted computing. She is a member of ACM.
