The page describes the performance work in JBossESB with regard to the extraction of security credentials from transport and message protocols.

WSSecurityInfoExtractor

This class is responsible for extracting the data from the Username and Password elements defined in a UsernameToken SOAP security header.

As this class implements SecurityInfoExtractor<String> its extractsSecurityInfo metod takes a String which will be the SOAP message.

What the tests do

The tests perform the following steps:

1. Warm up of 50000 calls to extractSecurityInfo
2. 1.000.000 calls to extractSecurityInfo

Example of test method:

    @Test
    public void performanceExtractUserPassSecurityInfo() throws Exception
    {
        WSSecurityInfoExtractor extractor = new WSSecurityInfoExtractor();
        String soap = createUserPassSoapString("soap-userpass-example.xml");
        
        AuthenticationRequest authRequest = null;
        for (int i = 0 ; i < 50000; i++)
        {
            authRequest = extractor.extractSecurityInfo(soap);
        }
        
        int iterations = 1000000;
        long start = System.nanoTime();
        for (int i = 0; i < iterations; i++)
        {
            authRequest = extractor.extractSecurityInfo(soap);
        }
        long duration = System.nanoTime() - start;
        long average = duration/iterations;
        System.out.println("Duration : " + NANOSECONDS.toMillis(duration) + "ms, Average : " + NANOSECONDS.toNanos(average) + "ns");
        
        assertNotNull(authRequest);
        assertEquals( "Clark", authRequest.getPrincipal().getName());
    }

SOAP Message used in testing

<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"  
            xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
            xmlns:xsd="http://www.w3.org/2001/XMLSchema">
  <soap:Header>     
    <wsse:Security xmlns:wsse="http://schemas.xmlsoap.org/ws/2002/04/secext">
      <wsse:UsernameToken>
        <wsse:Username>Clark</wsse:Username>
        <wsse:Password>griswald</wsse:Password>
      </wsse:UsernameToken>
    </wsse:Security>
  </soap:Header>
  <soap:Body>
  </soap:Body>
</soap:Envelope>

Test Results

Smooks remarks

Regarding the performance of Smooks in this case the main hotsport reported was in org.xml.sax.helpers.XMLReaderFactory.createXMLReader which is called from org.milyn.delivery.AbstractParser. This will create a new XMLReader for every invocation made. By default this will use the current environments default XMLReader which is decided through the following steps:

1. If the system property 'org.xml.sax.driver' has been set that class will be used
2. JAR Services API will be used and will look for a classname in META-INF/services/org.xml.sax.driver.
3. Distro-specific fallback

A minor performace gain can be achieved by settning the reader to be used explicitely in the smooks configuration xml:

<reader class="org.apache.xerces.parsers.SAXParser" />

Regarding the actual creation of the XMLReader re-using XMLReader instance might be an option in Smooks. According to the XMLReader javadocs once a parse is complete, an  application may reuse the same XMLReader object. I'll get some feedback from Tom about this get his opinion. But this will probably have little impact on the overall performance which the Raw SAX tested above showed. That test simply created a new XMLReader and parsed the message and was created to see how long it took to use SAX without going through Smooks.

WS-Security versions support

In the current code base the security extractors can handle different version of ws-security. This is done by supporting different namespaces. This seemed to be a flexible solution but does impact performance. But perhaps this is not a realistic use case, I'm thinking that a service will probably support a specific version and might only require one or the other version and not both. We can support both but this can be a choice of the user and not the default.

Moving forward I think a better approach is to have the security namespace a configurable option. So users would be able to set this in the configuration and this would be passed to the MessageComposer.