Java Web service: The big cost of ws-security

Based on existing cryptography and XML encryption and signature industry standards, Ws-security provides a comprehensive set of security features for WEB service applications that you can use Ws-policy and Ws-securitypolicy to specify which features are available to a particular application. This allows the service client to configure itself to access the service. Wide support for these standards across multiple platforms and WEB service frameworks enables excellent interoperability (and continuous improvement).

Despite all the benefits, there are some drawbacks to ws-security. In the first two articles of this series, you already know that the configuration of ws-security is sometimes very complex and sometimes adds many blocks (bulk) to the exchanged messages. So what is the value of the benefits of ws-security? In this article, we'll delve into the runtime costs of ws-security and associated ws-secureconversation (in terms of processing overhead and adding blocks) and extend to the topic of how ws-security can benefit the application.

Observe performance

To measure the performance of applications under different configurations, this article will determine when the client and server run on the same system in the execution time of a particular request sequence. There are some drawbacks to this approach-most notably, it combines client and server processing overhead so that it cannot be measured separately-but it produces more consistent results than running tests on the network. You can also easily try these tests on your own hardware and JVM, and the relevant implementation code is shown in the downloads.

Performance Test Application

The application used for testing is a seismic data retrieval service. It is based on an earthquake database that contains the actual data of more than 93,000 earthquakes occurring around the world over a period of time. Requests for services will specify the range of longitude, latitude, date, or magnitude, and the service will be grouped by region and time to return all matching earthquakes. The entire database is kept in memory by index so that requests can be processed quickly so that almost all processing time for each request is spent on the actual Web service processing code (including data-binding code that will be converted to XML or converted from XML).

Listing 1 shows an example request for a service, followed by a response that adjusts the format to fit the page width:

Listing 1. Sample requests and Responses

<soapenv:envelope xmlns:soapenv= "http://schemas.xmlsoap.org/soap/envelope/" >


<soapenv:Body>


<ns1:matchquakes xmlns:ns1= "Http://ws.sosnoski.com/seismic/types" >


<ns1:min-date>2001-08-08T16:31:05.752+00:00</ns1:min-date>


<ns1:max-date>2001-08-14T23:51:31.499+00:00</ns1:max-date>


<ns1:min-long>160.4685</ns1:min-long>


<ns1:max-long>178.19693</ns1:max-long>


<ns1:min-lat>-42.423557</ns1:min-lat>


<ns1:max-lat>-30.44976</ns1:max-lat>


</ns1:matchQuakes>


</soapenv:Body>


</soapenv:Envelope>





<soapenv:envelope xmlns:soapenv= "http://schemas.xmlsoap.org/soap/envelope/" >


<soapenv:Body>


<ns1:results xmlns:ns1= "Http://ws.sosnoski.com/seismic/types" count= "9" >


<ns1:result-set>


<ns1:area-name>new Zealand region</ns1:area-name>


<ns1:regions count= "0" >


<ns1:region ident= "rgn159" index= "159" >north ISLAND,


NEW zealand</ns1:region>


<ns1:region ident= "rgn160" index= "160" >off E. COAST of N. ISLAND,


n.z.</ns1:region>


</ns1:regions>


<ns1:quakes count= "9" >


<ns1:quake time= "2001-08-11t09:52:54.000+00:00" millis= "1000"


latitude= " -37.6499" longitude= "177.74" depth= "83.0" magnitude= "4.4"


method= "ML" region= "rgn160"/>


<ns1:quake time= "2001-08-11t09:52:55.000+00:00" millis= "0"


Latitude= " -37.71" longitude= "177.77" depth= "70.0" magnitude= "4.5"


method= "ML" region= "rgn160"/>


<ns1:quake time= "2001-08-11t15:02:47.000+00:00" millis= "5600"


latitude= " -38.0429" longitude= "175.632" depth= "299.8" magnitude= "4.6"


method= "ML" region= "rgn159"/>


<ns1:quake time= "2001-08-12t07:42:41.000+00:00" millis= "7000"


latitude= " -37.97" longitude= "175.97" depth= "289.0" magnitude= "4.3"


method= "MB" region= "rgn159"/>


<ns1:quake time= "2001-08-12t22:37:58.000+00:00" millis= "5600"


latitude= " -38.3839" longitude= "176.121" depth= "163.2" magnitude= "4.0"


method= "ML" region= "rgn159"/>


<ns1:quake time= "2001-08-12t23:25:09.000+00:00" millis= "6700"


Latitude= " -39.9559" longitude= "176.115" depth= "76.0" magnitude= "4.0"


method= "ML" region= "rgn159"/>


<ns1:quake time= "2001-08-13t05:10:07.000+00:00" millis= "4300"


latitude= " -37.5859" longitude= "176.651" depth= "189.0" magnitude= "4.3"


method= "ML" region= "rgn159"/>


<ns1:quake time= "2001-08-14t02:43:18.000+00:00" millis= "2900"


latitude= " -38.3699" longitude= "175.902" depth= "193.4" magnitude= "4.5"


method= "ML" region= "rgn159"/>


<ns1:quake time= "2001-08-14t18:02:35.000+00:00" millis= "5400"


latitude= " -37.8159" longitude= "176.375" depth= "193.3" magnitude= "4.5"


method= "ML" region= "rgn159"/>


</ns1:quakes>


</ns1:result-set>


</ns1:results>


</soapenv:Body>


</soapenv:Envelope>

In the test, the client adjusts the scope of the query to a part of the overall seismic dataset and generates a series of pseudo random requests. The sequence of requests that are generated each time the client runs with the same input parameter is the same, allowing us to test different WEB service configurations. You can easily test different result message sizes by changing the client's input parameters (the scope of the query used to change the request).