axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Steve Graham" <sggra...@us.ibm.com>
Subject Re: JDom
Date Mon, 05 Mar 2001 14:07:48 GMT
<snip>

>Sam Ruby wrote:
>My intuition is that in the cases where one or both of the headers and the
>body are likely to be large, the body is the one more likely to be large.
I think there will be all sorts of combinations.  Right now I don't see any
one preponderance of size in either direction.

>Similarly between requests and responses, I would think that it would be
>the response that would more likely tend to be large.  Anybody care to
>disagree?
Again, this depends.  I tend to think more along the lines of
document-centric
vs RPC.  RPC is the dominant form of examples we see at the moment, but
document-centric will be the biggest use for "serious" e-business IMO.  A
purchase
order request might constitute a large request body, and the response might
be a simple ACK.

>If the design point is that the entire response body must be in memory
>prior to the first byte being output, then all the streaming up to this
>point will result in only marginal benefits at the cost of a more complex
>code base.
We don't have much control on how the response is formed.  The web service
might
be a wrapper over a legacy application.  The architecture currently does
not mandate
that the response be formed in any particular way.

>Net: IMHO, if you want to scale, make sure that none of the core function
>or provided handlers require the bytes of either body to be in continguous
>memory at any point in the processing.
For digital signatures, I believe the entire message must be in memory to
be signed or verified.


++++++++
Steve Graham
sggraham@us.ibm.com
(919)254-0615 (T/L 444)
Web Services Architect
Emerging Internet Technologies
++++++++


Mime
View raw message