- From: John J. Barton <John_Barton@hpl.hp.com>
- Date: Tue, 01 Apr 2003 09:39:01 -0800
- To: Marc Hadley <Marc.Hadley@Sun.COM>, Noah Mendelsohn/Cambridge/IBM <noah_mendelsohn@us.ibm.com>
- Cc: xml-dist-app@w3.org
There seems to be different ideas of what "streaming" means here. In one case streaming means the that request is large compared with the bandwidth to the processing engine. Perhaps we might prefer to call this case "partial transmission" meaning that the message is finite similar in size to common service buffers. This is an important case: digital data is growing as is applications of computers to smaller systems. In another case streaming means that the input or output is "infinite". As I have said here before, XML cannot, by design, handle this case. You can't put an Internet Radio station in a SOAP message without lying about it. I believe that most of the rest of the world uses the term "streaming" to mean these infinite sources. Of course SOAP messages can be used to control out-of-band streaming. I guess all of this discussion concerns the "partial transmission" meaning of "streaming"? At 09:49 AM 4/1/2003 -0500, Marc Hadley wrote: >I agree that there are cases where streaming is difficult, but there are >some cases where streaming is useful. E.g. a receiver can send a >mustUnderstand fault without waiting for the (potentially large) body of >the incoming message to be completely received. > >Regards, >Marc. > >On Monday, Mar 31, 2003, at 20:50 US/Eastern, Noah >Mendelsohn/Cambridge/IBM wrote: > >> >> >> >> >> >>A recent internal discussion at IBM has led me to question the degree to >>which SOAP is amendable to streaming. On the one hand, we know that our >>mustUnderstand rules tend to preclude streaming until at least the start of >>the body, but I had more or less assumed that we would allow for streaming >>past that, and indeed I believe that in the description of the >>Request/Response pattern [1] we specifically allow for this by saying: >> >>----------------------- >>Bindings that implement this MEP MAY provide for streaming of SOAP >>responses. That is, responding SOAP nodes MAY begin transmission of a SOAP >>response while a SOAP request is still being received and processed. When >>SOAP nodes implement bindings that support streaming, the following rules >>apply: >> >>* All the rules in [SOAP Part 1] Binding Framework regarding streaming of >>individual SOAP messages MUST be obeyed for both request and response SOAP >>messages. >> >>* When using streaming SOAP bindings, requesting SOAP nodes MUST avoid >>deadlock by accepting and if necessary processing SOAP response information >>while the SOAP request is being transmitted. >> >>--Note: >> >>--Depending on the implementation used and the size of the messages >>involved, this rule MAY require that SOAP applications stream >>application-level response processing in parallel with request generation. >> >>* A requesting SOAP node MAY enter the "Fail" state, and thus abort >>transmission of the outbound SOAP request, based on information contained >>in an incoming streamed SOAP response. >>----------------------- >>The referenced section in part 1 says [2]: >> >>----------------------- >>Bindings MAY provide for streaming when processing messages. That is, SOAP >>nodes MAY begin processing a received SOAP message as soon as the necessary >>information is available. SOAP processing is specified in terms of SOAP >>message infosets (see 5. SOAP Message Construct). Although streaming SOAP >>receivers will acquire such XML infosets incrementally, SOAP processing >>MUST yield results identical to those that would have been achieved if the >>entire SOAP envelope were available prior to the start of processing. For >>example, as provided in 2.6 Processing SOAP Messages, identification of >>targeted SOAP header blocks, and checking of all mustUnderstand attributes >>is to be done before successful processing can proceed. Depending on the >>representation used for the XML infoset, and the order in which it is >>transmitted, this rule might limit the degree to which streaming can be >>achieved. >>----------------------- >> >>That all makes sense, except for one thing. When using the obvious XML 1.0 >>serialization as in the HTTP binding, we do not even know that the XML is >>well formed until the end. >> >>So my question: other than the usual provision that allows for rollback >>etc., do we in fact support any form of streaming when using the HTTP >>binding (or any other XML 1.0 serialization)? Seems to me the rules above >>preclude it. Once we start to do useful application processing, we can't >>send a fault, particularly if we have started to stream a response while >>the request is still coming in as signaled in [1]. Is this old news? I >>guess I sort of knew it in the back of my mind all along, but this is the >>first time I've really thought through the implications. Am I missing >>something? Thanks. >> >> >>[1] http://www.w3.org/TR/2002/CR-soap12-part2-20021219/#bindformdesc >>[2] http://www.w3.org/TR/2002/CR-soap12-part1-20021219/#bindfw >> >>------------------------------------------------------------------ >>Noah Mendelsohn Voice: 1-617-693-4036 >>IBM Corporation Fax: 1-617-693-8676 >>One Rogers Street >>Cambridge, MA 02142 >>------------------------------------------------------------------ >> >> >> >-- >Marc Hadley <marc.hadley@sun.com> >Web Technologies and Standards, Sun Microsystems. ______________________________________________________ John J. Barton email: John_Barton@hpl.hp.com http://www.hpl.hp.com/personal/John_Barton/index.htm MS 1U-17 Hewlett-Packard Labs 1501 Page Mill Road phone: (650)-236-2888 Palo Alto CA 94304-1126 FAX: (650)-857-5100
Received on Tuesday, 1 April 2003 12:39:06 UTC