Skip to end of metadata
Go to start of metadata

The SOA ToolBox is a basic service and ESB test toolkit bundled with the UltraESB. It allows one to start a sample server instance hosting a set of pre-built RESTful web services, JAX-WS SOAP services, and raw HTTP echo servlets, Text and HTML servlets, and then issue sample requests to these services through the HTTP/S or JMS client modules. The HTTP/S client supports REST, POX, Text and binary payloads (such as Hessian) and supports the POST, GET, PUT, DELETE, HEAD, OPTIONS and TRACE methods in addition to many other features. The ToolBox ships with a built-in TCP dump module, able to report wire traffic as text or Hex formatted binary and additionally allows the message to be saved to a file for replay with a load test etc. Other modules of the ToolBox includes a JMS Client, raw socket level client usually used to test the ability of a service or an ESB to face invalid, malformed or malicious requests, and a high performance HTTP/S load test module.

Introduction

The AdroitLogic UltraESB is designed to help test and troubleshoot service and ESB test scenarios with ease. The ToolBox comprises of the following modules, and can be started with the "toolbox.sh" [Linux] or "toolbox.bat" [Windows] scripts.

The Jetty Server



The sample Jetty server comes with a RESTful Web Service sample at URL [http://localhost:9000/rest-services/customers]. The HTTP/S client preset "3" shows a sample request expected by this service. This service can be used to test the POST, GET, PUT, DELETE, HEAD, OPTIONS and TRACE methods. The Jetty server also contains an implementation of the SimpleStockQuoteService (copied with modifications from the Apache Synapse project). This service expects a slightly different message (HTTP/S client prefix "1") than the format expected by Synapse 1.2.x. (HTTP/S client prefix "2"). The EchoService is a high performance service which will echo back the request received. Thus it can be used to echo back various message sizes - say 1K, 5K, 10K etc for load and performance testing. Specifying an Echo service delay, causes the responses to be delayed by the specified number of milliseconds. This is useful to analyze how an ESB not using a Non-Blocking IO approach can easily block, when handling a large number of concurrent connections - which must be kept open until the delayed responses are received. The sample service also contains a servlet that will output a plain text response and an HTML response, to analyze how the UltraESB can handle these types of responses.

The HTTP/S Client

The HTTP/S client module provides a full RFC 2616 compliant HTTP/S client based on the Apache HttpComponents/HttpClient project. It can perform HTTP/S POST, GET, PUT, DELETE, HEAD, OPTIONS & TRACE and support 2-way SSL, or ignore SSL validation, and support basic or digest authentication. The preset payloads allows one to easily interact with the sample services hosted over the Jetty server, and experiment with the UltraESB samples. Payload could be typed into the text area or picked up from a file. However the correct content type should be selected as appropriate. It is even possible to use the HTTP/S client to test binary payloads - such as raw Hessian messages - which could easily be captured from the TCP dump module. The HTTP/S client supports both HTTP 1.0 and 1.1 versions, and can control the use of chunking, expectation control (i.e. waiting for a 100 continue reply before sending the body), keepalive and response compression control (i.e. accepting Gzipped responses). The socket timeout allows the client to specify the maxium delay for a response to arrive before the client times out. When sending SOAP requests, the SOAPAction maybe specified as well. Once a request is sent out, the response received is displayed on the text area below.

TCP Dump

The TCP Dump module allows one to easily monitor, and optionally capture the messages sent at the wire level for debugging, or capturing (e.g. for a subsequent load test) purposes. The messages can be captured as Text, or binary Hex. The Listen port accepts messages on the local machine where the ToolBox is executed, and forwards the message to the Forward Host over the Forward Port specified. To save the request being sent, specify a file with the full path in the Save request to file option

JavaBench Load Test client

The JavaBench load test client consists of all the features of the standard HTTP/S client, but can be used to load test services or an ESB. Please see the description of the standard HTTP/S client for the core capabilities of the JavaBench. In addition, the concurrency specifies the number of virtual users or number of requests made in parallel during a load test run. The Iterations specifiies how many times the selected operation is performed by one virtual user. Using the Verbosity, one can see the headers, or even the payload body over the wire - but use of this will adversely affect the performance capabilities.



A typical load test run reports the following information, which is very similar to the report format used by the Apache Bench load testing tool.

The Raw Socket Client

The raw socket allows the user to send invalid, malformed, corrupted or malicious payloads to the selected host over the selected port. This is useful to test the negative test scenarios which are otherwise difficult to identify, reproduce and fix. Some service hosting engines and ESB's may not be able to even accept malformed requests, even for logging purposes. Note that this is an advanced option and expects the user to be familiar with the HTTP RFC 2616 for operation. The most common mistake a novice user usually does is specifying a wrong content length - which should be the size of the payload in bytes. The payload must be separated from the header by a blank line.

A Simple end-to-end walkthrough

To start the AdroitLogic ToolBox, use the "toolbox.sh" or the "toolbox.bat" scripts found in the bin directory of your installation. Once started, the menu option will allow you to start one or more instances of the above modules. Thus it is possible to start Jetty server instances on ports 9000, 9001, 9002 etc for a load balancing test, or use two instances of the TCP Dump module to capture the traffic between the client and the ESB, and the ESB and the backend for example.
Simple Echo service request

First lets start the sample Jetty Server on the default port 9000 as shown above. Then open an instance of the HTTP/S client, and select the payload from Preset "1". Leaving all other options to the defaults, pressing the "Send" button will now display the response sent by the service at "http://localhost:9000/service/EchoService" for the request that we sent.
Using the ToolBox for RESTful experiments

If you now select Preset "3" from the HTTP/S client and use select the URL as "http://localhost:9000/rest-services/customers", you are able to create an instance of a Client in the RESTful web services example hosted by the Jetty server. You will receive a reply similar to the following:

Now, copy the result of the "Location" header from your response (in this case "http://localhost:9000/rest-services/customers/1 ") and paste it into the URL field. Ensure that you do not copy or paste any unwanted characters or space. Now select GET method, and issue request. You should now see the response as follows:

Reslect payload from Preset "3", modify any of the values and select the PUT method on the above URL. You will now receive a response as follows, indicating that the resource has been updated.

Now issue a GET on the same URL, and you will see the updated information. If you issue a DELETE on the above URL, the resource will be deleted. You may experiment with the other options available with the HTTP/S client and other HTTP methods such as HEAD, OPTIONS, TRACE etc.

Note: The RESTful web service hosted on the Jetty server does not like new lines in the request. We will soon investigate the cause of this and update the sample to avoid the issue. In the meantime, you can use a payload without new lines (as shown by Preset "3") for your experiments.
Starting the UltraESB

Now, lets start the UltraESB using the configuration file "samples/conf/ultra-sample-101.xml". This will start a REST proxy service at URL "http://localhost:8280/service/rest-proxy". You could attempt the same REST operations discussed above against this URL and see how the UltraESB will proxy REST calls - without any interference to the flow. Additionally you will notice that the UltraESB performs "Location" header translation so that its users will never need to know about the read REST service or its URL.

For example, issue a Preset "3" request to the URL "http://localhost:8280/service/rest-proxy/customers" and you will get a response as follows, with the Location header appropriately re-written.

Thus, you can now GET, PUT, DELETE etc on the Proxy service URL exposed by the UltraESB - "http://localhost:8280/service/rest-proxy/customers/2 " to deal with the REST resource.

  • No labels