Re: use cases for MTOM

I agree with this description.

Question: If this is an in-scope use case, will we need to model this 
in properties in some fashion? If so, what would it look like?


On Wednesday, September 10, 2003, at 04:09  PM, Anish Karmarkar wrote:

> 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 Thursday, 11 September 2003 02:40:18 UTC