Loading ...
Sorry, an error occurred while loading the content.

Using a parser other than XML::Parser or XML::Parser::Lite

Expand Messages
  • teden
    Folks, I ve got a pretty complex xsd/wsdl definition for my web service which is running SOAP::Transport::HTTP::Daemon. The input schema defines several layers
    Message 1 of 9 , May 13 12:22 PM
    • 0 Attachment
      Folks,

      I've got a pretty complex xsd/wsdl definition for my web service
      which is running SOAP::Transport::HTTP::Daemon. The input schema
      defines several layers of nesting arrays (arrays of arrays of
      arrays). On the server side I am parsing it using SOAP::SOM using a
      variety of $som->dataof() calls nested inside of each other. I have
      optimized the code as best I can and server response time is still in
      the 6+ second range.

      From majordojo (http://www.majordojo.com/soaplite/), I see a comment
      that changing the XML parser can have a significant performance yield
      (see article http://www.majordojo.com/archives/000150.php#000150).
      OK, I'll bite... How do you change the behavior of SOAP::Lite to use
      a parser different from XML::Parser or XML::Parser::Lite? Given that
      XML::LibXML seems to be the fastest, I'd like to use it, bu don't
      know where to begin to do that.

      Thanks in advance,

      Thom Eden
    • Maurice McCabe
      You can get around the whole XML parser issue if you generate the raw XML using string manipulation. I use this approach for sending Microsoft DataSets from a
      Message 2 of 9 , May 14 11:17 AM
      • 0 Attachment
        Message
        You can get around the whole XML parser issue if you generate the raw XML using string manipulation. I use this approach for sending Microsoft DataSets from a Perl server to a .Net or Axis (Java) client (In my case .NET does the parsing automatically on the client side, once it knows it is a DataSet which it gets from the WSDL).
         
        You can send the raw XML using something like:
         
                SOAP::Data->name('GetComplexStructResult' => SOAP::Data->type('xml' => $yourRawXML));
         
        You should not need to change your client for this to work.
         
        Hope this helps!
         
        Maurice
         
        -----Original Message-----
        From: teden [mailto:thom@...]
        Sent: Thursday, May 13, 2004 12:23 PM
        To: soaplite@yahoogroups.com
        Subject: [soaplite] Using a parser other than XML::Parser or XML::Parser::Lite

        Folks,

        I've got a pretty complex xsd/wsdl definition for my web service
        which is running SOAP::Transport::HTTP::Daemon. The input schema
        defines several layers of nesting arrays (arrays of arrays of
        arrays). On the server side I am parsing it using SOAP::SOM using a
        variety of $som->dataof() calls nested inside of each other. I have
        optimized the code as best I can and server response time is still in
        the 6+ second range.

        >From majordojo (http://www.majordojo.com/soaplite/), I see a comment
        that changing the XML parser can have a significant performance yield
        (see article http://www.majordojo.com/archives/000150.php#000150).
        OK, I'll bite... How do you change the behavior of SOAP::Lite to use
        a parser different from XML::Parser or XML::Parser::Lite? Given that
        XML::LibXML seems to be the fastest, I'd like to use it, bu don't
        know where to begin to do that.

        Thanks in advance,

        Thom Eden

      • Duncan Cameron
        ... I don t think that you can (easily) change the parser used by SOAP::Lite. What I think is being referred to is extracting the XML content of the message
        Message 3 of 9 , May 14 12:12 PM
        • 0 Attachment
          On 13-05-2004 at 19:22:47 teden <thom@...> wrote:

          >Folks,
          >
          >I've got a pretty complex xsd/wsdl definition for my web service
          >which is running SOAP::Transport::HTTP::Daemon. The input schema
          >defines several layers of nesting arrays (arrays of arrays of
          >arrays). On the server side I am parsing it using SOAP::SOM using a
          >variety of $som->dataof() calls nested inside of each other. I have
          >optimized the code as best I can and server response time is still in
          >the 6+ second range.
          >
          >From majordojo (http://www.majordojo.com/soaplite/), I see a comment
          >that changing the XML parser can have a significant performance yield
          >(see article http://www.majordojo.com/archives/000150.php#000150).
          >OK, I'll bite... How do you change the behavior of SOAP::Lite to use
          >a parser different from XML::Parser or XML::Parser::Lite? Given that
          >XML::LibXML seems to be the fastest, I'd like to use it, bu don't
          >know where to begin to do that.

          I don't think that you can (easily) change the parser used by SOAP::Lite.
          What I think is being referred to is extracting the XML content of the message and then using a different parser to parse and process it.
          On the article you refer to, the benchmark figures were posted by myself, not by Randy Ray. I cannot find the code at present but I am sure that the approach was as I mention above.

          Regards
          Duncan
        • YU Fan
          You can use outputxml() to get raw xml in your client. Then you can do anything with it. $soap = SOAP::Lite - serivce ( ... ) - outputxml(1); $xml =
          Message 4 of 9 , May 14 12:22 PM
          • 0 Attachment
            You can use outputxml() to get raw xml in your client.
            Then you can do anything with it.

            $soap = SOAP::Lite
            -> serivce ("...")
            -> outputxml(1);

            $xml = $soap->method();


            --Yu


            --- teden <thom@...> wrote:
            > Folks,
            >
            > I've got a pretty complex xsd/wsdl definition for my
            > web service
            > which is running SOAP::Transport::HTTP::Daemon. The
            > input schema
            > defines several layers of nesting arrays (arrays of
            > arrays of
            > arrays). On the server side I am parsing it using
            > SOAP::SOM using a
            > variety of $som->dataof() calls nested inside of
            > each other. I have
            > optimized the code as best I can and server response
            > time is still in
            > the 6+ second range.
            >
            > From majordojo (http://www.majordojo.com/soaplite/),
            > I see a comment
            > that changing the XML parser can have a significant
            > performance yield
            > (see article
            >
            http://www.majordojo.com/archives/000150.php#000150).
            >
            > OK, I'll bite... How do you change the behavior of
            > SOAP::Lite to use
            > a parser different from XML::Parser or
            > XML::Parser::Lite? Given that
            > XML::LibXML seems to be the fastest, I'd like to use
            > it, bu don't
            > know where to begin to do that.
            >
            > Thanks in advance,
            >
            > Thom Eden
            >
            >





            __________________________________
            Do you Yahoo!?
            SBC Yahoo! - Internet access at a great low price.
            http://promo.yahoo.com/sbc/
          • Paul Kulchenko
            ... It should be easy, shouldn t it? As far as I remember, $soap- deserializer- parser gives you a current one and
            Message 5 of 9 , May 14 12:59 PM
            • 0 Attachment
              > I don't think that you can (easily) change the parser used by
              > SOAP::Lite.

              It should be easy, shouldn't it? As far as I remember,

              $soap->deserializer->parser

              gives you a current one and

              $soap->deserializer->parser(MySuperFastParser->new)

              replaces it with a new one.

              Unfortunately, MySuperFastParser has to support Expat callback
              interface (and LibXML does SAX), which may not be a problem given
              available SAX to Expat modules.

              It's unlike though that the parser is your bottleneck; probably it's
              a combination of SOAP::SOM and the code you're using. You may get a
              better result by converting the result of parsing into a suitable
              Perl data structure and using it rather than a series of SOAP::SOM
              calls.

              Best wishes, Paul.

              --- Duncan Cameron <duncan_cameron2002@...> wrote:
              > On 13-05-2004 at 19:22:47 teden <thom@...> wrote:
              >
              > >Folks,
              > >
              > >I've got a pretty complex xsd/wsdl definition for my web service
              > >which is running SOAP::Transport::HTTP::Daemon. The input schema
              > >defines several layers of nesting arrays (arrays of arrays of
              > >arrays). On the server side I am parsing it using SOAP::SOM using
              > a
              > >variety of $som->dataof() calls nested inside of each other. I
              > have
              > >optimized the code as best I can and server response time is still
              > in
              > >the 6+ second range.
              > >
              > >From majordojo (http://www.majordojo.com/soaplite/), I see a
              > comment
              > >that changing the XML parser can have a significant performance
              > yield
              > >(see article http://www.majordojo.com/archives/000150.php#000150).
              >
              > >OK, I'll bite... How do you change the behavior of SOAP::Lite to
              > use
              > >a parser different from XML::Parser or XML::Parser::Lite? Given
              > that
              > >XML::LibXML seems to be the fastest, I'd like to use it, bu don't
              > >know where to begin to do that.
              >
              > I don't think that you can (easily) change the parser used by
              > SOAP::Lite.
              > What I think is being referred to is extracting the XML content of
              > the message and then using a different parser to parse and process
              > it.
              > On the article you refer to, the benchmark figures were posted by
              > myself, not by Randy Ray. I cannot find the code at present but I
              > am sure that the approach was as I mention above.
              >
              > Regards
              > Duncan
              >
              >
              >
              >
              > ------------------------ Yahoo! Groups Sponsor
              >
              >
              > Yahoo! Groups Links
              >
              >
              >
              >
              >
            • thom@dbflow.com
              Yes, I know about - outputxml()... But I need it in the server. My problem is the service trying to extract all of the data from the envelope. It d be great if
              Message 6 of 9 , May 14 1:11 PM
              • 0 Attachment
                Yes, I know about ->outputxml()... But I need it in the server. My problem is
                the service trying to extract all of the data from the envelope. It'd be great
                if you could set some parm when starting the service that inside the method
                call you want the raw xml.
                ______________________________________
                This E-Mail was sent with Fronthost Web/Mail.
                Use www.fronthost.com for all your hosting and development needs.
              • Mark Wilkinson
                If you control both the client and the service, you could base64 encode the content, then it wont be parsed... This works surprisingly well!! ... if you are in
                Message 7 of 9 , May 14 2:33 PM
                • 0 Attachment
                  If you control both the client and the service, you could base64 encode
                  the content, then it wont be parsed...

                  This works surprisingly well!! ... if you are in total control at both
                  ends...

                  Mark


                  On Fri, 2004-05-14 at 13:11, thom@... wrote:
                  > Yes, I know about ->outputxml()... But I need it in the server. My
                  > problem is
                  > the service trying to extract all of the data from the envelope. It'd
                  > be great
                  > if you could set some parm when starting the service that inside the
                  > method
                  > call you want the raw xml.
                  > ______________________________________
                  > This E-Mail was sent with Fronthost Web/Mail.
                  > Use www.fronthost.com for all your hosting and development needs.
                  >
                  >
                  >
                  >
                  > Yahoo! Groups Sponsor
                  > ADVERTISEMENT
                  > click here
                  >
                  >
                  > ______________________________________________________________________
                  > Yahoo! Groups Links
                  > * To visit your group on the web, go to:
                  > http://groups.yahoo.com/group/soaplite/
                  >
                  > * To unsubscribe from this group, send an email to:
                  > soaplite-unsubscribe@yahoogroups.com
                  >
                  > * Your use of Yahoo! Groups is subject to the Yahoo! Terms of
                  > Service.
                  * --
                  Mark Wilkinson (mwilkinson@...)
                  University of British Columbia iCAPTURE Centre
                • Duncan Cameron
                  ... That s what I really meant. It is the accessing of the parsed data tree that may be the bottleneck , and using a different parser would give a structure
                  Message 8 of 9 , May 15 12:32 AM
                  • 0 Attachment
                    On 14-05-2004 at 19:59:45 Paul Kulchenko <paulclinger@...> wrote:

                    >> I don't think that you can (easily) change the parser used by
                    >> SOAP::Lite.
                    >
                    >It should be easy, shouldn't it? As far as I remember,
                    >
                    >$soap->deserializer->parser
                    >
                    >gives you a current one and
                    >
                    >$soap->deserializer->parser(MySuperFastParser->new)
                    >
                    >replaces it with a new one.
                    >
                    >Unfortunately, MySuperFastParser has to support Expat callback
                    >interface (and LibXML does SAX), which may not be a problem given
                    >available SAX to Expat modules.
                    >
                    >It's unlike though that the parser is your bottleneck; probably it's
                    >a combination of SOAP::SOM and the code you're using.
                    That's what I really meant. It is the accessing of the parsed data tree that may be the bottleneck , and using a different parser would give a structure that could be accessed more easily/quickly ...

                    Regards
                    Duncan
                  • Duncan Cameron
                    ... I think that there may be (at least) two areas to look at Firstly, using, say, SAX2 callbacks would allow any SAX2 parser to be used. This I would guess
                    Message 9 of 9 , May 15 12:41 AM
                    • 0 Attachment
                      On 14-05-2004 at 18:14:21 Tod Harter <tharter@...> wrote:

                      >I have to say it would REALLY make things nicer if we could use
                      >XML::LibXML (in particular) as a parsing engine, its something on the
                      >order of 50 to 100 times faster, and the API is definitely quite a lot
                      >more standards-compliant and featureful. I'm wondering how hard it would
                      >be to abstract out an interface to allow SOAP::Lite internals to handle
                      >different parsers. Probably not easy, but on the last project I
                      >completed using SOAP::Lite parsing consumes on the order of 60% of all
                      >CPU cycles, eek!
                      >
                      I think that there may be (at least) two areas to look at
                      Firstly, using, say, SAX2 callbacks would allow any SAX2 parser to be used. This I would guess is straightforward based on Paul's comment to my previous posting.
                      Secondly, building a result tree that can be accessed using full XPath notation, rather than or as well as the current SOM approach. This looks to be a bit more difficult.

                      Regards
                      Duncan
                    Your message has been successfully submitted and would be delivered to recipients shortly.