W3C home > Mailing lists > Public > xml-dist-app@w3.org > September 2003

Re: use cases for MTOM

From: John J. Barton <John_Barton@hpl.hp.com>
Date: Wed, 10 Sep 2003 11:00:18 -0700
Message-Id: <5.1.1.6.2.20030910104955.01e89ac8@hplex1.hpl.hp.com>
To: Anish Karmarkar <Anish.Karmarkar@oracle.com>, Mark Nottingham <mark.nottingham@bea.com>
Cc: "Xml-Dist-App@W3. Org" <xml-dist-app@w3.org>

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 14:00:52 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 7 December 2009 10:59:15 GMT