Re: SOAP message parsing redundancy with doc-lit services.

[Sharmin Choksey [comcast]]

Please see my comments ******     Have you find any solution on this topic?   ***** : The current solution points towards the usage of SOAP w/Attachments over MIME - since the message carried with the Attachment Part will not be parsed/processed in any way by the AXIS engine implementation.   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?   ***** : I'm afraid not, to the best of my knowledge, you will need to re-initialize the 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.    ***** : Its the DOM tree-like representation in memory that gets constructed as part of the AXIS engine implementation when handed off to the service endpoint api (Element []) that should be the cause of memory concerns.  Initializing the SAX parser to parse and validate the payload is not of significant impact to memory since the parser type is event based and the xml tree is not held in memory.   Good luck, - Sharmin. 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.