- From: christopher ferris <chris.ferris@east.sun.com>
- Date: Wed, 13 Jun 2001 19:29:23 -0400
- To: xml-dist-app@w3.org
In response to [1], I see the core issue as whether SOAP does or does not support a streamed processing model. The three section fragments below imply that it cannot if one takes a strict interpretation of the SOAP1.1 specification (regardless of what Jacek points out in [2] regarding current implementations doing an mU check on the body entries): 2. The SOAP Message Exchange Model A SOAP application receiving a SOAP message MUST process that message by performing the following actions in the order listed below: 1.Identify all parts of the SOAP message intended for that application (see section 4.2.2) 2.Verify that all mandatory parts identified in step 1 are supported by the application for this message (see section 4.2.3) and process them accordingly. If this is not the case then discard the message (see section 4.4). The processor MAY ignore optional parts identified in step 1 without affecting the outcome of the processing. ... 4.2.3 SOAP mustUnderstand Attribute The SOAP mustUnderstand global attribute can be used to indicate whether a header entry is mandatory or optional for the recipient to process. The recipient of a header entry is defined by the SOAP actor attribute (see section 4.2.2). The value of the mustUnderstand attribute is either "1" or "0". The absence of the SOAP mustUnderstand attribute is semantically equivalent to its presence with the value "0". If a header element is tagged with a SOAP mustUnderstand attribute with a value of "1", the recipient of that header entry either MUST obey the semantics (as conveyed by the fully qualified name of the element) and process correctly to those semantics, or MUST fail processing the message (see section 4.4). 4.3.1 Relationship between SOAP Header and Body While the Header and Body are defined as independent elements, they are in fact related. The relationship between a body entry and a header entry is as follows: A body entry is semantically equivalent to a header entry intended for the default actor and with a SOAP mustUnderstand attribute with a value of "1". The default actor is indicated by not using the actor attribute (see section 4.2.2). Specifically, to satisfy step 1 of the message exchange model, one MUST parse the whole message (well, at least the Header and Body since nothing is said about trailers), not just the headers because of what is stated in section 4.3.1. Semantic equivalence means (IMO) that a body entry that is not understood by the ultimate recipient MUST be handled in the same manner as "header entries". Since there can be more than one body entry, all must be inspected before processing can be performed (again, based on a strict, literal, interpretation of section 2). Again, I recognize that [2] suggests that no current SOAP implementations do an mU check on Body, but that doesn't make it correct. Section 4.3.1 must either be removed or completely recast. I think that our spec needs to be much clearer on handling of "you sent me this Body and I don't get it" faults if they are indeed different than header mU faults. We could separate out the Header and Body mU checks, but this raises the same issues as with allowing for trailer mU checks (should we allow for this) in a streamed processing model where both the input message and "response" are streamed (e.g. output is streamed as a *direct* result of streamed input processing) because there is no mechanism for handling "oops!! nevermind, I didn't understand the whole message...". What is also unclear to me is how an application-level or for that matter parser-level error (as in the case of a not-well-formed SOAP message) would be reported in a streamed processing model should one be encountered as the message is being processed, regardless of whether or not there was total understanding of the message or whether only the Body element were being streamed. In conclusion, I don't think that it is realistic to expect that any purely or even partially streamed process model can be supported without some provision for buffering the "response" (or causally subsequent message) which would seem to me to suggest that it *would* be practical to support both Body and Trailer mU checks using the algorithm that is suggested by Jacek in [1]: > Interleaving mU checks with processing (the first step being > splitting mU checking into before-Headers and before-Body) could > lead us to do the mU check on each single block only before > processing each one of them. Something like: > > while(! bs.atEnd()) { > Block b=bs.next(); > checkMU(b); > b.process(...); > }; > Note that this *does* provide for checking mU on trailers *after* the body has been processed. In fact, the whole algorithm, including mU faulting could be expressed as (excuse my Java;-): ByteArrayOutputStream res = new ByteArrayOutputStream(); try { while(! bs.hasMoreElements()) { Block b=(Block)bs.nextElement(); checkMU(b); b.process(res, ...); } req.send(res); } catch (Exception x) { req.fault(x); } This requires that the text of section 2 (above) will require modification to relax the required ordering currently specified with a note that addresses the implications which captures much of the discussion that this issue has raised especially as regards to streamed processing of SOAP messages as well as to highlight the potential need for (in certain, but certainly not all, cases) rollback of partial processing in the face of an exception. I believe that it also provides for equal and consistent handling of header, body AND trailers whether they or not any attempt is made to remove or recast the distinction between header, body and trailer blocks. Note that I don't believe that this approach impacts backward compatibility, it just removes the required ordering of: 1) identify all headers [blocks] 2) verify mU on all 3) process all A possible revised section 2 might look like: A SOAP application receiving a SOAP message MUST process that message by performing the following actions: 1.Identify all parts of the SOAP message intended for that application (see section 4.2.2) 2.For each mandatory part identified in step 1, verify that it is supported by the application (see section 4.2.3) and process accordingly. If this is not the case then fault the message as described in section 4.4. The processor MAY ignore optional parts identified in step 1 without affecting the outcome of the processing. ... Cheers, Chris [1] http://lists.w3.org/Archives/Public/xml-dist-app/2001Jun/0111.html [2] http://lists.w3.org/Archives/Public/xml-dist-app/2001Jun/0113.html
Received on Wednesday, 13 June 2001 19:29:33 UTC