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

Re: use cases for MTOM

From: Anish Karmarkar <Anish.Karmarkar@oracle.com>
Date: Wed, 03 Sep 2003 11:22:33 -0700
Message-ID: <3F563169.1030501@oracle.com>
To: Mark Nottingham <mark.nottingham@bea.com>
Cc: "Xml-Dist-App@W3. Org" <xml-dist-app@w3.org>

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 GMT

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