axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Aleksander Slominski <>
Subject SOAP streaming and faults, security everywhere and performance implications [Re: opinion Axis' future ... [Re: Using SAAJ-1.2 API to modify the soap header/body content
Date Tue, 08 Jun 2004 18:29:50 GMT
Sanjiva Weerawarana wrote:

>Hi Alek,
Hi Sanjiva,

much more comments inline.

>>but it seems that reality of current SOAP is not allowing any of 
>>those desirable features to be easily expressed ...
>I agree with your comment about streaming .. but I'm willing to
>"break" SOAP semantics for it.

>>now that we are stuffing more and into headers (such as binary
>>security tokens) there seems to be quite common case that size
>>of headers will well outweigh size of payload.
>I agree 100%. However, in the presence of such headers the 
>performance requirements change. For example, if RM is being
>used with a QoS of exactly once, ordered delivery, then the raw
>performance is not so critical in a business process that's
>probably driving it. Most likely the process is a long running
>business transaction (like a mortgage application) and then 
>there's not much point in focusing on whether a message takes
>10ms or 20ms when the whole process runs over a 3 month period.
i think security will soon be required for any message exchange and the 
same may be about WS-RM when we have more multi-hop services and 
messages that must pass multiple gateways (next gen firewalls).

>>also i think that MTOM (and attachment) can be referenced
>>both from headers and payloads so binary large data can be
>WSDL 2.0 does not support that; MTOM is for the payload only ..
>headers are not part of the fundamental description of a Web service;
>they come into existence due to the application of certain QoS
>(like RM or security). 
i will need to check this i thought MTOM can be applied to any base64 
content ...

>>easily added anywhere in SOAP envelope and we should make 
>>sure that all this can be efficiently processed ...
>Sure, but you can't have the cake and eat it. My believe today is
>that header processing is expensive and is going to be so. SOAP
>requires that all mustUnderstand headers be processed correctly ..
>that means you can't "stream" headers thru - the framework has to
>process everything. Furthermore, as more and more QoS characteristics
>(aka policies) are applied, header processing becomes even more
>complex. In particular, it is quite non-trivial to determine which
>order the various policy handlers can run .. in the case of transactions
>and reliable messaging and security you can convince yourself that the
>right order is security, then reliable messaging and then Tx. In the
>general case there is no algorithm to compute the order AFAIK.
yes we need policies about how to apply policies (and handlers) ...

>>still clearly the one case to keep in mind is how to handle very
>>large payloads as it may be very important case for some class of 
>>applications such as scientific computing.
>>i started with just considering generic XML messaging (and that
>>is how XSOAP4/XSUL is designed) so i did not feel like there is
>>a need to have a special separate treatment of header and body
>>(payload) which seems to be now validated by current "core"
>>WS-* specs (see below). 
>I'm confused by the last comment; which WS-* specs blur the ditinction
>between header and body?? (I couldn't see a clarification further
>below; sorry.)
for example: WS-RM has some special (infrastructure level) messages that 
has empty body and action is really part of header (but no payload ...)

>>if you describe everything as  XML infoset that it is very 
>>important to allow simple access to whole message XML infoset
>>(and make possible to use such tools like XPath or XQuery) - 
>>runtime XML infoset is just optimized to take hints (such as 
>>provided by MTOM) to make decisions about in-memory
>>materialization of XML content.
>Yep; I'm definitely +1 for an MTOM-aware Infoset model being the
>default, dynamically typed representation of arbitray XML content.
then why to make the distinction between XML elements <S:Header> and 
<S:Body> - isnt body like a special header targeted to ultimate receiver?

>>so my thinking is that there needs to be set of flexible layers 
>>and developer can choose on which layer to plugin their code: 
>>transport, XML message infoset, SOAP headers/payload (header
>>processors). XML Schema data binding, RelaxNG validation, whatnot ...
>IMO we need to classify different types of developers and provide
>different programming models for them. I want to keep app developers
>a level above all this .. basically at the level WSDL 2.0 is putting
>them at; anything else are policies they express or are expressed
>to them by someone else. 
i think it would be very valuable to have enumeration of roles (like 
EJB) but applied to building WS and SO(A).

>The developers who write such policy handlers of course have a
>different view of the world and get access to a different/additional
>set of information .. for example, the security handler is someone
>who will likely re-write the entire payload (if it were encrypted).
yes - we do it all the time including dreaded conversion to DOM so 
existing XML security libs can work on the message.

>>unfortunately XML is not designed for streaming and moreover 
>>streaming of payload is not supported in SOAP 1.1/1.2.
>Yes, unfortunately.
unfortunately :(

maybe we need SSOAP?

>>i think i can make this bold (?!) statement based on my past 
>>experience: only by breaking SOAP semantics it is i possible
>> to do limited streaming  of vanilla SOAP envelopes with just 
>I'm ok with "breaking" SOAP semantics a bit here .. 
i wish it could be expressed without any breakage - the heart of it is 
that if you want to stream output you can not know if there some 
processor that produces output (such as serializer or actual service 
when it computes stream content) that may fail *during* output - in this 
case you can either buffer whole thing (preferably to DB or file for 
really large outputs so at least memory footprint is not too bad ...) or 
start sending it immediately but then you can not signal fault in 

the only robust but sub-optimal way to deal with it (i found and 
implemented in XSOAP1) is to close abruptly output stream.

it would be much better if i could write <S:Fault> as last children of 
<S:Body> and have receiving processor to discard input and act on Fault.

>in fact the
>breakage would only be visible to an external observer in the form
>of the error they will get. 
breakage will be only if error happens but if you do what i did in 
XSOAP1 the receiver will not know what caused problem as no Fault is 
sent only that connection was lost ...

>Two well-behaved SOAP processors will
>not have any problem .. where well-behaved means that they basically
>general well-formed XML; a very low bar to pass.
it is more complicated than that as i described above: Fault is special 
and is supposed to be first child of Body ...

do you have some other solution in mind?

>>payload (why no way to signal in-stream faults?) and it gets 
>>very difficult with WSS (why there is no footers so one could
>>compute signature on the fly and then write it in footer!) and 
>>does not make sense for WS-ReliableMessaging (message is stored
>> before sending so it can be easily re-sent ...) except of course
>>for re-streaming out of (database) persistent storage later but 
>>that is just replay and will require coding to make sure it 
>>scales well ....
>Again, I believe the realistic business scenarios for WS-Security
>and WS-Reliable Messaging have different performance characteristics
>than a raw SOAP message exchange. Thus, I'm not convinced there's 
>much value in doing raw comparison of how long it takes an RM 
>exchange to occur .. that's not what RM is intended to be used for
IMHO as business and scientific worlds converges on Web services and 
Grids those distinctions are blurred.

for example one of the most important requirements for grid services (if 
not the most important ...) is to have security.

in current WS world security has serious impact on performance (like one 
order of magnitude slower for WSS and even more when you start doing SSO 
with capabilities ....).

so the time of simple non secure and non reliable SOAP messages may be 
going away but i hope it will not require more and more complex WS-* 
specs that are harder and harder to understand and work with (WSS and 
WS-Policy comes to mind ....).


The best way to predict the future is to invent it - Alan Kay

View raw message