Hi,

  Have you find any solution on this topic?

  We are using message style. The problems we found are:

  1. AXIS parses the message inside of the soap body element but not validate it. Only useful of this is replay ability of SAX events.
      We want to validate our XML messages, do you know anyway to validate such message without reinitializing another SAX parser?

  2. If we use the following two message style signatures:
        public Element [] method(Element [] bodies);
        public SOAPBodyElement [] method (SOAPBodyElement [] bodies);

   In order to using SAX parser validates the XML message, the service provider
   has to use the toString method to convert the array of elements into string, then feeds it
   into InputSource. The "toString" method seems doubled memory usage, is it true? We are worried
   that we will be running into memory problems. Plus by initiating the new sax parser to put already 
   started AXIS sax parser obsolete. It seems very inefficient.

 Please advice.

Thanks,
Emily






At 07:27 AM 10/23/2003 -0700, Sharmin Choksey [comcast] wrote:
This is a followup to the thread posted at http://www.mail-archive.com/[EMAIL PROTECTED]/msg09663.html,. Subject : "Accessing the XML in the SOAP message body" posted Feb-03.
 
In reference to the message posted, I am specifically interested in knowing if there has been any development done in addressing the issue around parsing of the XML payload sent in the SOAP body by the AXIS runtime.  I see a design issue here with respect to performance since parsing of the xml payload in a doc-lit style service does not add any value/functionality in performing AXIS related tasks.  I see that the Message object has the ability to store different formats of the SOAP body element, inputstream, string, bytes etc.  Why isn't the content of the SOAP body element left alone instead of parsing it.
 
Doc-lit services fail to scale beyond 5 concurrent users with payloads of 150K with poor response times in contrast to sending the xml payload within CDATA where the parser will ignore such contents, scaling exponentially with response times in sub seconds.
 
Is there an alternative other than using attachments ? where the payload will not be parsed ? Please advise.
 
-Sharmin.

Reply via email to