- From: Anish Karmarkar <Anish.Karmarkar@oracle.com>
- Date: Wed, 10 Sep 2003 16:09:40 -0700
- To: "John J. Barton" <John_Barton@hpl.hp.com>
- Cc: Mark Nottingham <mark.nottingham@bea.com>, "Xml-Dist-App@W3. Org" <xml-dist-app@w3.org>
John, I am using the term 'streaming' in a difference sense than you are. I was using it from the point of view of applications APIs (i.e. streaming APIs) and not as a unending broadcast stream. An attachment mechanism where the (relatively) small SOAP message is received before the binary goop, allows the application to start processing the soap message before entire MIME package (in the case of SwA) is received. For example, in the case of Java, one could use the JavaBeans Activation Framework's (JAF) DataHandler class to get/put large binary objects from/to a database very efficiently (from the point of view of the SOAP node processing the message). Make sense? -Anish -- John J. Barton wrote: > At 10:39 AM 9/10/2003 -0700, Anish Karmarkar wrote: > >> Mark, >> >> I mostly agree with you comments. >> >> XMLP-UC-6 needs to be discussed further. One of the biggest advantages >> of using attachments is streaming. This can be positioned either as a >> usecase or a requirement. > > > I wonder about the use of the words "attachments" and "streaming" here. > To me "attachments" means a single > message with two or more parts, a major part and other stuff attached. > "Streaming" means data sent continuously > with out any end predicted (radio station). So the statement > "advantages of using attachments is streaming" does > not make sense to me. > > I do absolutely agree that a good mechanism for client/server > interaction on buffer management is important for > binary in SOAP. The simplest and a very effective way is for the > protocol to allow binary object sizes to be > sent in the message early. SwA can be used in this way: the entire SOAP > message can appear first and > a large binary can still be on the wire, allowing a client to prepare > itself based on the first part of the message. > > >> For example, consider a header containing large binary data. If this >> binary data is contained in an attachment, then the sender (and >> receiver) can stream the data out (and in). This allows the receiver >> to start processing the SOAP message (for example looking at all the >> headers and checking for MU) before the binary data has been received >> (or sent by the sender). > > > As above, I'm not sure you mean the same thing by "stream" that I > commonly hear. Typically streamed data > does not go over TCP/IP let alone HTTP. But otherwise I agree with the > need for the requirement doc to take > the case of a very large binary in to serious consideration. > > >> Comments? >> >> -Anish >> -- >> >> Mark Nottingham wrote: >> >>> >>> My .02 - >>> On Wednesday, September 3, 2003, at 11:22 AM, Anish Karmarkar wrote: >>> >>>> >>>> XMLP-UC-1: based on >>>> http://www.w3.org/TR/2002/WD-ws-arch-scenarios-20020730/#S090 ..... >>> >>> >>> Strictly speaking, this doesn't require anything beyond base64Binary. >>> >>>> XMLP-UC-2: an application that uses URI to deref resources, and >>>> assumes the only representation travels with the message >>> >>> >>> Is this still an in-scope use case? I think we need to discuss this. >>> >>>> XMLP-UC-3: an application that uses middleware/SOAP-stack to deref >>>> resources, and assumes the only representation travels with the > >>>> message >>> >>> >>> This feels more like implementation details to me, with some implied >>> requirements. >>> >>>> XMLP-UC-4: digital camera wants to encrypt and/or sign the message >>>> and/or binary data >>> >>> >>> Is this a requirement (that it work with encryption/digsig)? >>> >>>> XMLP-UC-5: message with binary data successfully goes through SOAP >>>> 1.2 intermediary >>> >>> >>> Sounds like a requirement to work with intermediaries. >>> >>>> XMLP-UC-6: a representation is streamed upon receipt when sender >>>> and/or receiver is constrained >>> >>> >>> Yes; we should discuss whether this is a motivation for the work, and >>> whether MTOM enables it. >>> >>>> XMLP-UC-7 (meta): WSDL is is applicable where appropriate >>> >>> >>> Sounds like a requirement. >>> >>>> XMLP-UC-8: representation is a digital camera produced VLOB >>> >>> >>> ??? >> >> >> ______________________________________________________ >> 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 Wednesday, 10 September 2003 19:09:57 UTC