Web Services Test

A web service is a collection of open protocols and standards used for exchanging data between applications or systems. Software applications written in various programming languages and running on various platforms can use web services to exchange data over computer networks like the Internet in a manner similar to inter-process communication on a single computer. A complete web service is, therefore, any service that:

Is available over the Internet or private (intranet) networks
Uses a standardized XML messaging system
Is not tied to any one operating system or programming language
Is self-describing via a common XML grammar
Is discoverable via a simple find mechanism

The basic web services platform is XML + HTTP. All the standard web services work using the following components:

SOAP (Simple Object Access Protocol)
UDDI (Universal Description, Discovery and Integration)
WSDL (Web Services Description Language)

A web service enables communication among various applications by using open standards such as HTML, XML, WSDL, and SOAP. A web service takes the help of the following:

XML to tag the data
SOAP to transfer a message
WSDL to describe the availability of service.

The following are the major uses of the Web Services:

Reusable application-components: Often applications need repeated access to application-components like currency conversion, weather reports, or even language translation. In such cases, the web services can be used to offer the application-components as services with ease.
Connect existing software: Web services can help to solve the interoperability problem by giving different applications a way to link their data. With Web services you can exchange data between different applications and different platforms. Any application can have a Web Service component. Web Services can be created regardless of programming language.

In certain environments, administrators are required to keep an eye on the web services that offer repeated access to the application-components i.e., operations so that the work load on the users using those applicaiton components can be minimized. If for some reason the web service takes too long to respond or is unavailable to cater to the needs of the users, then the users will be deprived of access to the application-components involved in that particular web service. To avoid such inconvenience caused to the users, administrators are required to continuously monitor the web services. The Web Service test helps administrators to perform this task perfectly. By continuosly monitoring each operation i.e., application component of a web service that is offered, using the SOAP commands, this test helps administrators identify the availability, response time and response code of the web service and quickly figure out discrepancies if any web service is deemed unavailable. This way, the web services can be kept available round the clock thus helping the users perform their tasks without any difficulty.

Target of the test : A Tomcat Server

Agent deploying the test : An internal agent

Outputs of the test : One set of results for each WebService:Operation i.e., application-component performed on the target server that is being monitored.

Configurable parameters for the test
Parameter	Description
Test Period	How often should the test be executed.
Host	The IP address of the host for which this test is to be configured.
Port	Refers to the port at which the specified host listens to.
WSDL URL	This test emulates a user accessing a specific web service(s) on the target server to determine the availability and responsiveness of the server. to enable this emulation, you need to configure the test with the url of the web service that it should access. specify this url against the WSDL URL parameter. if required, you can even configure multiple WSDL URLs - one each for every web service that the test should attempt to access. if each WSDL URL configured requires special permissions for logging in, then, you need to configure the test with separate credentials for logging into every WSDL URL. likewise, you need to provide instructions to the test on how to validate the content returned by every WSDL URL, and also set an encoding format for each wsdl url. to enable administrators to easily configure the above per WSDL URL, eg enterprise provides a special interface. to access this interface, click on the encircled ‘+’ button alongside the url text box in the test configuration page. alternatively, you can even click on the encircled ‘+’ button adjacent to the WSDL URL parameter in the test configuration page. to know how to use this special interface, refer to section Configuring Multiple WSDL URLs for Monitoring .
Operation	Each Web Service that is monitored could be supporting multiple operations. Using this parameter, you can configure the test to perform a few/all of the operations a Web Service supports and validate the response of these operations, so that the effectiveness and overall performance of the Web Service can be evaluated right. To achieve this, follow the steps detailed in Configuring Multiple Web Service Operations For Monitoring.
Timeout	Specify the duration (in seconds) for which this test should wait for a response from the server. If there is no response from the server beyond the configured duration, the test will timeout. By default, this is set to 30 seconds.
Detailed Diagnosis	To make diagnosis more efficient and accurate, the eG Enterprise embeds an optional detailed diagnostic capability. With this capability, the eG agents can be configured to run detailed, more elaborate tests as and when specific problems are detected. To enable the detailed diagnosis capability of this test for a particular server, choose the On option. To disable the capability, click on the Off option. The option to selectively enable/disable the detailed diagnosis capability will be available only if the following conditions are fulfilled: The eG manager license should allow the detailed diagnosis capability Both the normal and abnormal frequencies configured for the detailed diagnosis measures should not be 0.

Measurements made by the test

Measurement

Description

Measurement Unit

Interpretation

WSDL url availability

Indicates whether the web service was able to respond successfully to the query made by the test.

Percent

Availability failures could be caused by several factors such as the web service process(es) being down, the web service being misconfigured, a network failure, etc. Temporary unavailability may also occur if the web service is overloaded. Availability is determined based on the response code returned by the service. A response code between 200 to 300 indicates that the service is available.

WSDL response time

Indicates the time taken by the eG agent to get the configured web service.

Secs

Response time being high denotes a problem. Poor response times may be due to the service being overloaded or misconfigured. If the URL accessed involves the generation of dynamic content by the service, backend problems (e.g., an overload at the application server or a database failure) can also result in an increase in response time.

Port status

Indicates whether/not the port of the web server is reachable.

The values reported by this measure and the corresponding numeric equivalents are listed in the table below:

Measure Values	Numeric Values
Yes	1
No	0

Note:

By default, this measure reports the above-mentioned Measure Values to indicate whether the server has been rebooted or not. In the graph of this measure however, the Measure Values are represented using the numeric equivalents only.

TCP connection availability

Indicates whether the test managed to establish a TCP connection to the server.

Percent

Failure to establish a TCP connection may imply that either the web server process is not up, or that the process is not operating correctly. In some cases of extreme overload, the failure to establish a TCP connection may be a transient condition. As the load subsides, the server may start functioning properly again.

TCP connect time

This measure quantifies the time for establishing a TCP connection to the web server host.

Secs

Typically, the TCP connection establishment must be very small (of the order of a few milliseconds). Since TCP connection establishment is handled at the OS-level, rather than by the application, an increase in this value signifies a system-level bottleneck on the host that supports the web server.

Server response time

Indicates the time period between when the connection was established and when the web server sent back a response header to the client.

Secs

While the total response time may depend on several factors, this measure is typically, a very good indicator of a server bottleneck (e.g., because all the available server threads or processes are in use).

Response code

The response code returned by the web server for the simulated request.

Number

A value between 200 and 300 indicates a good response. A 4xx value indicates a problem with the requested content (eg., page not found). A 5xx value indicates a server error.

Service availability

Indicates whether/not the web service is available.

Percent

A value of 100 indicates that the web service is available and a value of 0 indicates that the web service is not available.

Operation status

Indicates whether/not the configured operation is present in the web service.

This measure will not report metrics if the OPERATION parameter in the test configuration page is none in the test configuration page.

Operation Content length

Indicates the response code returned by the server for the simulated request.

Number

A value between 200 and 300 indicates a good response. A 4xx value indicates a problem with the requested content (e.g., page not found). A 5xx value indicates a server error.

This measure will not report metrics if the OPERATION parameter in the test configuration page is none or if an invalid Value is specified or if the Value is not specified in the HTML View tab while configuring the operation for monitoring in the test configuration page.

Operation Content validity

This measure validates whether the operation was successful in executing the request made to it.

Percent

A value of 100% indicates that the content returned by the test is valid. A value of 0% indicates that the content may not be valid. This capability for content validation is especially important for multi-tier web applications. For example, a user may not be able to login to the web site but the server may reply back with a valid HTML page where in the error message, say, “Invalid Login” is reported. In this case, the availability will be 100 % (since we got a valid HTML response). If the test is configured such that the content parameter should exclude the string “Invalid Login”, in the above scenario content validity would have a value 0.

Operation execution time

Indicates the time taken to invoke the configured operation in the web service.

Secs

Configuring Multiple WSDL URLs for Monitoring

In order to enable the eG agent to connect to multiple WSDL URLs and pull out the required metrics from them, the eG administrative interface provides a special page using which different WSDL URLs and their corresponding operations that need to be monitored can be specified. To configure the WSDL URLs, do the following:

Figure 1 : Configuring the WebService test

Click on the encircled ‘+’ button alongside the WSDL URL text box. Figure 2 will then appear.

Figure 2 : The WebService URL Configuration page
Specify the following in Figure 2:
- Name: Specify a unique name by which the WSDL URL you will be specifiying shortly will be referred to across the eG user interface. This is the name that will appear as the descriptor of this test.
- URL: Enter the WSDL URL of the web service that this test should access.
- Username and Password: These parameters are to be set only if a specific user name / password has to be specified to login to the web service (i.e., WSDL URL ) that you have configured for monitoring. In this case, provide valid login credentials using the Username and Password text boxes. If the server on which WebService test executes supports ‘Anonymous user access’, then these parameters will take either of the following values:
  - none in both the Username and Password text boxes of the configured WSDL URL, if no user authorization is required
  - Some servers however, support NTLM (Integrated Windows) authentication, where valid login credentials are mandatory. In other words, a none specification will not be supported by such servers. Therefore, in this case, against each configured WSDL URL, you will have to provide a valid Username in the format: domainname\username, followed by a valid Password.
  - Please be sure to check if your web service requires HTTP authentication while configuring this parameter. HTTP authentication typically involves a separate pop-up window when you try to access the page. Many services use HTTP POST for obtaining the user name and password and validating the user login. In such cases, the username and password have to be provided as part of the POST information and NOT as part of the Credentials specification for the WebService test.
- Content: The Content parameter has to be configured with an instruction:value pair that will be used to validate the content being returned by the test. If the Content value is None, no validation is performed. On the other hand, if you pick the Include option from the Content list, it indicates to the test that for the content returned by the web server to be valid, the content must include the specified value (a simple string search is done in this case). This value should be specified in the adjacent text box. Similarly, if the Exclude option is chosen from the Content drop-down, it indicates to the test that the server's output is valid if it does not contain the value specified in the adjacent text box. The Include or Exclude value you specify in the text box can include wildcard characters. For example, an Include instruction can be *Home page*.
- Encoding: Sometimes the eG agent has to parse the WSDL URL content with specific encoding other than the default (ISO-8859-1) encoding. In such a case, specify the type of encoding using which the eG agent can parse the WSDL URL content in the Encoding text box. By default, this value is none.
Similarly, you can add multiple URL specifications by clicking the Add More button. To remove a WSDL URL specification, click on the encircled ‘-’ button corresponding to it. To clear all WSDL URL specifications, click the Clear button. To update all the changes you made, click the Update button.
Once Update is clicked, you will return to the test configuration page as shown in Figure 1. The WSDL URL text box in the test configuration page will display just the Names - i.e., the unique display names - that you may have configured for the multiple WSDL URLs, as a comma-separated list. To view the complete WSDL URL specification, click the encircled ‘+’ button alongside the WSDL URL text box, once again.

Configuring Multiple Web Service Operations For Monitoring

The Web Services test enables you to not only monitor multiple web services running on a Tomcat server, but also specific operations that one can perform using each web service. For this test to run, you first need to configure which web services and operations you want to monitor. To know how to configure the web services, refer to Configuring Multiple WSDL URLs for Monitoring . For configuring the operations on the other hand, do the following:

In the Web Services test configuration page, after you configure the WSDL URLs you want monitored, proceed to configure the operations that you want to monitor per URL. For that, first click on the encircled '+' button corresponding to he Operations parameter (see Figure 3).

Figure 3 : Clicking on the encircled '+' button against the Operations parameter
Figure 4 will then appear. From the WSDL URL drop-down, pick the URL for which you want to configure operations.

Figure 4 : Viewing the operations associated with a chosen Web Service
The web services supported by the chosen WSDL URL will then automatically populate the Services drop-down. From this drop-down, select the service for which you want to configure operations.
The operations supported by the chosen service will then be listed in the DEFINED OPERATIONs list box. Select the operations you want to monitor from the Defined Operations list box and click on the < button to transfer the selection to the MONITORED OPERATIONS list box (see Figure 5).

Figure 5 : Selecting the operations to be monitored
Once the operations that require monitoring are identified, you can now proceed to configure / simulate requests to each operation, so that the Web Services test can validate and measure their response. For that, select an operation from the MONITORED OPERATIONS list box and click the Configure button (see Figure 5). A SOAP request message template option will then appear (see Figure 6).

Figure 6 : Choosing a SOAP request message template
Using the SOAP request message template option, you can select the template using which the test should emulate requests to the chosen operation. If you choose the Pre-defined option, then you can emulate the request using a template that pre-exists. For instance, say, the operation you have chosen to monitor converts a Fahrenheit temperature value to Celsius. Assume that the request that you want the test to emulate accepts a Fahrenheit value, converts it into Celsius, and in the process, measures the validity and latency of the response. In some environments, the template for simulating such a request may pre-exist. In this case, use the Pre-defined option. A Pre-defined template can be in the XML format or in the HTML format.

Either way, the test automatically discovers the existing template (from the WSDL URL) and displays it in the XML View and/or HTML View tab pages, respectively. If you want to leverage the HTML template for the purpose of the emulation, then click on the HTML View tab page (see Figure 7). The pre-defined HTML template will now become visible. In our example, this template accepts a Fahrenheit value for conversion. Provide such a value and click the Send Request button.

Figure 7 : Using a pre-defined HTML template for emulating a request for an operation
Alternatively, you can use a custom template for emulating the request. Such a template can only be defined in the XML format. In this case therefore, first set the SOAP request message template flag to Custom, and then click on the XML View tab page (see Figure 8).

Figure 8 : Configuring a custom XML template for emulating a request for an operation
In the SOAP Request Message text area (see Figure 8), configure the XML code for emulating the request and click the Send Request button.
This way, using steps 5-8, you can configure request templates for each operation you wish to monitor.