Re: use cases for MTOM

More usecases are located at [1]. These usecases were discussed during 
the March 2003 F2F.

Use cases from [1] are summaries below:

Use Cases

XMLP-UC-1: based on 
http://www.w3.org/TR/2002/WD-ws-arch-scenarios-20020730/#S090 .....

XMLP-UC-2: an application that uses URI to deref resources, and assumes 
the only representation travels with the message

XMLP-UC-3: an application that uses middleware/SOAP-stack to deref 
resources, and assumes the only representation travels with the message

XMLP-UC-4: digital camera wants to encrypt and/or sign the message 
and/or binary data

XMLP-UC-5: message with binary data successfully goes through SOAP 1.2 
intermediary

XMLP-UC-6: a representation is streamed upon receipt when sender and/or 
receiver is constrained

XMLP-UC-7 (meta): WSDL is is applicable where appropriate

XMLP-UC-8: representation is a digital camera produced VLOB


-Anish
--

[1] http://www.w3.org/2000/xp/Group/3/03/06-minutes.html

Mark Nottingham wrote:
> 
> I had an AI to generate some text for MTOM use cases. This is a starting 
> point;
> 
> 
> * Undesirable Message Bloat
> An application wishes to send a SOAP message that contains a large 
> binary piece of data; e.g., a JPG image, binary executable or other 
> sizeable, non-textual data. For design reasons, this data cannot be 
> referenced externally, but must be transported with the message. Doing 
> so using base64Binary or similar encoding involves an unacceptable 
> message size, due to bandwidth, latency and/or storage requirements.
> 
> * Undesirable Processing Overhead
> An application wishes to send a SOAP message that contains a large 
> binary piece of data; e.g., a JPG image, binary executable or other 
> sizeable, non-textual data. For design reasons, this data cannot be 
> referenced externally, but must be transported with the message. Doing 
> so using base64Binary or similar encoding involves unacceptable message 
> generation and/or parsing overhead, due to throughput requirements, 
> device limitations and/or other considerations.
> 
> * Focused Intermediaries
> An intermediary wishes to process a large message, but only needs to 
> access a small section of the message. For efficient operation, it needs 
> to be able to construct the relevant parts of the message infoset 
> without actually reading and parsing the rest of the message, whilst 
> still being able to successfully forward the entire message.
> 
> 
> -- 
> Mark Nottingham   Principal Technologist
> Office of the CTO   BEA Systems
>

Received on Wednesday, 3 September 2003 14:22:46 UTC