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

Received on Sunday, 4 April 2004 14:12:21 UTC