You are viewing a plain text version of this content. The canonical link for it is here.
Posted to java-user@axis.apache.org by Aleksander Slominski <as...@cs.indiana.edu> on 2004/04/04 20:10:45 UTC
SOAP message processing model / performance [Re: Why use a container?]
Jim Murphy wrote:
> 2.2.1: Not sure what you mean by start and stop. Not knowing anything
> else I'd put my money on the perf bottleneck being at inter-app
> communication. In a servlet container (esp. Tomcat) things can run
> inprocess. So there is not extra parameter marshaling that has to
> happeen. Just gather the XML from the front end socket, parse it and
> dispatch to a java method to start generating a response. No process
> boundaries to cross, no other synchronization necessary.
hi,
i would like to clarify here one point that may be confusing about
"dispatch to a java method to start generating a response":
* when receiving SOAP 1.1/1.2 it is possible to overlap socket reading,
parsing, and processing (dispatching) as data can be pulled out when
needed and processing CAN be started with incomplete data (under
condition that you extra careful to have two phase processing: first
SOAP headers then SOAP body)
* when sending SOAP 1.1/1.2 message it is NOT possible to overlap
producing content of SOAP:Body and sending UNLESS you can guarantee that
no fault will happen because SOAP:Fault must be first immediate child of
SOAP:Body so if you have put any content in SOAP:Body (partial response)
that prohibits you from sending fault ...
let me know if i missed something?
thanks,
alek
ps. i believe the solution to it would be similar to any protocols i.e.
to have SOAP:Footer alas it is too late for it (or as a hack to allow
SOAP:Fault to be immediate child of SOAP:Body but on any position ...)
--
The best way to predict the future is to invent it - Alan Kay