Announcement Announcement Module
Collapse
No announcement yet.
Performance of different types of endpoints. Page Title Module
Move Remove Collapse
X
Conversation Detail Module
Collapse
  • Filter
  • Time
  • Show
Clear All
new posts

  • Performance of different types of endpoints.

    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

  • #2
    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.

    Comment


    • #3
      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

      Comment


      • #4
        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.

        Comment


        • #5
          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

          Comment


          • #6
            Originally posted by GregThoen View Post
            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.

            Comment


            • #7
              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

              Comment


              • #8
                Originally posted by GregThoen View Post
                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, which will be there soon.
                Last edited by Arjen Poutsma; Feb 2nd, 2008, 08:54 PM.

                Comment

                Working...
                X