Version 12


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



    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:

        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");
            assertEquals( "Clark", authRequest.getPrincipal().getName());


    SOAP Message used in testing


    <soap:Envelope xmlns:soap=""  
        <wsse:Security xmlns:wsse="">



    Test Results

    Framework/ToolNr of invocations
    Total TimeMessage size
    Stax1.000.00093760ms514  bytes
    Smooks1.000.0001181690ms514  bytes
    Raw SAX1.000.000818964ms514  bytes


    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 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.