Performance of different types of endpoints.

[mskendrick]

Has anyone done any tests to see which type of endpoint performs the best? I would expect that the Marshalling endpoints would be a little slower.

Shannon Kendrick

[Arjen Poutsma]

It also depends what marshaller you use, of course. You can get an overview at https://bindmark.dev.java.net/. Note, however, that Jibx - which is fastest, cannot be used in combination with DOM trees (which is what SAAJ uses). It only unmarshals from I/O streams.

[mskendrick]

If I remember correctly, one of XFire's "selling points" is its speedy pipeline based on the Stax parser. I seem to remember that DOM is slower than SAX, and that Stax seems to be the fastest (I could be wrong about that). How does the Spring WS pipeline work? Is the request converted to DOM first and passed as a DOM tree through the pipeline? Can any of the speed advantages of XFire or Axis 2 be taken advantage of in Spring WS?
Shannon Kendrick

[Arjen Poutsma]

Yes they can, because there are multiple implementations of the SoapMessage interface. One of them (SaajSoapMessage) is based on DOM, but another one is based on Axiom, the StAX-based SOAP API from Axis2. Changing from one implementation to another is a matter of changing one line of config (you change the SaajSoapMessageContextFactory to an AxiomSoapContextFactory.

That said, the true benefits of streaming only become clear when you use streaming endpoints such as the SaxPayloadEndpoint of one of the StreamingPayloadEndpoints. You cannot use WS-Security, since that requires a DOM, nor XPath queries.

[GregThoen]

Hi,

You (Arjen) said that you only get the benefit of Stax if you use a streaming endpoint.

Do you know, if you use org.springframework.ws.soap.axiom.AxiomSoapMessage Factory for the context factory but use JAXB for the mapping, will it use Stax underneath the scenes and not keep the incoming XML in memory? It seems that from a high level (which is all I know of the Spring-WS and JAXB implementations) it should work that way, but I don't know enough detail to know if it actually does.

Thanks,
Greg

[Arjen Poutsma]

Hi,

You (Arjen) said that you only get the benefit of Stax if you use a streaming endpoint.

Do you know, if you use org.springframework.ws.soap.axiom.AxiomSoapMessage Factory for the context factory but use JAXB for the mapping, will it use Stax underneath the scenes and not keep the incoming XML in memory? It seems that from a high level (which is all I know of the Spring-WS and JAXB implementations) it should work that way, but I don't know enough detail to know if it actually does.

Thanks,
Greg

It does. :)

[GregThoen]

Thank you for the quick reply - that's very helpful. :)

One last (I think) question on this topic of endpoint performance. In order to use a Stax-based approach and not have the XML sitting around in memory, as I believe it says in the reference documentation, you can only read the payload once, which makes perfect sense. This means, as far as I'm aware, the only endpoint mappings that you could use are the two SOAPAction based ones (i.e. SoapActionEndpointMapping and SoapActionAnnotationMethodEndpointMapping). However, those can't be used with SOAP 1.2. Is there any way to use Stax message processing without using the deprecated SOAPAction header? I know Axis2 has the ability to route incoming messages based upon the URL the message was posted on. I don't see this in Spring-WS, but am I just missing it somewhere?

If there isn't something that we can use that will allow the use of Stax without using the SOAPAction header, could that please be added to the roadmap?

If such an endpoint mapping doesn't already exist, any tips on how I would go about implementing a URL-based endpoint mapping myself?

Thanks again,
Greg

[Arjen Poutsma]

Thank you for the quick reply - that's very helpful. :)

One last (I think) question on this topic of endpoint performance. In order to use a Stax-based approach and not have the XML sitting around in memory, as I believe it says in the reference documentation, you can only read the payload once, which makes perfect sense. This means, as far as I'm aware, the only endpoint mappings that you could use are the two SOAPAction based ones (i.e. SoapActionEndpointMapping and SoapActionAnnotationMethodEndpointMapping). However, those can't be used with SOAP 1.2. Is there any way to use Stax message processing without using the deprecated SOAPAction header? I know Axis2 has the ability to route incoming messages based upon the URL the message was posted on. I don't see this in Spring-WS, but am I just missing it somewhere?

If there isn't something that we can use that will allow the use of Stax without using the SOAPAction header, could that please be added to the roadmap?

If such an endpoint mapping doesn't already exist, any tips on how I would go about implementing a URL-based endpoint mapping myself?

Thanks again,
Greg

URL-based routing is an interesting feature. It does make the mapping transport-dependent, and that's the reason I haven't implemented it so far.

However, I've created SWS-277 (http://jira.springframework.org/browse/SWS-277), which will be there soon.