Just as a followup, I've already tried installing the latest Xerces parser to see if that might help. No luck.
Can you share your SOAP message sizes: average size vs large size? Also what platform you are running JBOSS on? I am interested in the performance impact of JBOSS.NET on large soap messages.
I think you may be correct in that the parsing is not scaling well on the larger messages.
I'm assuming you are using the RPC style message format which is the default when you follow the JBOSS example for exposing an EJB as a webservice. In this case, org.apache.axis.providers.java.RPCProvider is what is used to deserialize the SOAP request message to the ejb and serialize the ejb to the SOAP response message.
You can deploy a simple webservice in JBOSS and handle the soap message yourself. http://ws.apache.org/axis/java/user-guide.html "Message Services" section talks about how to do this. (http://www.csd.abdn.ac.uk/~bscharla/teaching/mtp_software/jboss/jboss-net-HelloWorld.shtml talks about how to tweak it to work with JBOSS.NET.)
In this instance the service handler is org.apache.axis.providers.java.MsgProvider. Rather than deserializing the soap request to an ejb, it deserializes the soap request based on the method signature you implemented. For example implementing public void method(SOAPEnvelope req, SOAPEnvelope resp);
MsgProvider will deserialize the SOAP request to, and serialize the response from: org.apache.axis.message.SOAPEnvelope. This way you can deal with the xml parsing yourself (most of it anyway, there is minimal parsing done by MsgProvider to deserialize into SoapEnvelope). This method also allows you access to the SOAPHeaders.
There are third party tools available such as xmlbooster (www.xmlbooster.com) which generate xml parsers which claim to be faster than geneneric xml parsers like Xerces. This is because it generates an xml parser specific to the xml message you want to process.
Of course if the xml is fairly simple and rarely changes you can just extract out what you need in the SOAP request and build the response message yourself. There are several apis to do so, sun SAAJ is the one I use.
Look at "Discover SOAP encoding's impact on Web service performance"
which not only explains the performance impact of different encoding styles: rpc/encoded, rpc/literal, document/literal but also offers free test suite to test on your system. Their results? rpc/encoded takes a major performance hit with large soap messages.
I've been busy for a while, so I haven't had time to come back to this till now. Thanks for the pointers. I'll check them out. As for the platform, this running under Java1.4.2 on a Solaris box. I think it's an 880, but I'm not sure (not in charge of the infrastructure stuff). When I get in tomorrow I'll post some performance measures of what is normal, big and how long the web service spends on each.