Re: Proposed resolution for issue 440

I saw Herve's answer as well, but I am a bit surprised. I expected something
more like this story.

To create a message with content like:

<person>
         <name>Noah Mendelsohn</name>
         <picture>...base64 of jpeg suitable for MTOM...</picture>
</person>

first, go back one step to the info model the app will really be working 
against:

<person>
         <name>Noah Mendelsohn</name>
         <picture href="file://mylocaldrive/file_or_DB"/>
</person>

Next add MTOM support that has two parts. First a schema part that causes me
to lay out my message with a manifest (called something else now and really
a SOAP header, not simple elements):

<manifest>
    <attachment metadata="image/jpeg etc..."  ID="1">
         <xbinc:include href="file://mylocaldrive/file_or_DB"/>
    </attachement>
</manifest>
<person>
         <name>Noah Mendelsohn</name>
         <picture href="#1"/>
</person>

The second MTOM part is a packaging option at transmission time that
accepts XML in the MTOM schema.  In this packager I suppose we would
find the kinds of calls Noah outlines below.

This model means that there is no application level API calls needed.
I can use plain XML DOM calls. Of course I could have a library that
encapsulated the schema model for me.  Then I am back to where
Noah is.  But the difference in this presentation is that the mechanism
for avoiding or allowing multiple includes of the same content is
quite transparent: I can see that the outside doc contains one external
ref in the manifest and the inside doc refs the manifest possibly multiple
times.  That is why I brought this up in the first place.

John.

At 05:27 PM 11/13/2003 -0500, noah_mendelsohn@us.ibm.com wrote:
>John Barton asks:
>
> >> What's the API going to look like?
>
>SOAP goes to some length to remain agnostic on APIs, but I certainly agree
>that supporting representative APIs is part of our use case
>justifications.  Here's a schematic of the API I have in mind as typical
>of use with MTOM.  The syntax in this sample is sort of Java, sort of DOM,
>but that's not particularly important and I've taken no trouble to get the
>details right on either.  Anyway, to create:
>
><person>
>         <name>Noah Mendelsohn</name>
>         <picture>...base64 of jpeg suitable for MTOM...</picture>
></person>
>
>I would suggest something along the lines of the following.  Assume in
>this that the class MTOMElement extends Element in the DOM-like API:
>
>
>         // Create the person element
>         Element person = new Element();
>         person.setElementName("person"):
>
>         // Add the name child - this is just for
>         // comparison so we can see how a non-MTOM
>         // node differs from an MTOM node
>         Element name = person.createElementChild();
>         name.setElementName("name"):
>         name.setElementText("Noah Mendelsohn");
>
>         // Add the picture child
>         // Note that the API has a special element type
>         // that knows about mtom optimization
>         MTOMElement picture = person.createMTOMElementChild();
>         picture.setElementName("picture"):
>         FILE jpegFile = openFile("NoahsMug.jpeg");
>         picture.setMTOMContentFromFile(jpegFile);
>
>Under the covers, I would expect that the API would (a) note that the
>content is known to be in base64Binary canonical (b) defer creating the
>character content in the hope that it will never be needed and maybe (c)
>defer even reading the file in the hope that some optimizations will be
>possible when the data is needed.  I would assume the element would
>support operations along the lines of:
>
>         OctetStream binaryPicture = picture.getAsBinary();
>and/or
>         String base64Picture = picture.getElementText();
>
>The first of these would take the octet stream directly from the file,
>preserving the MTOM optimization.  The latter would do the base64
>conversion to characters, possibly caching the results for reuse.
>
>My assumption is that an MTOM binding implementation sending this content
>would issue a getAsBinary, or might even use the availability of the file
>descriptor to do some memory mapping games between file buffers and I/O
>buffers, allowing one to avoid data copying between the filesystem and
>network system.
>
>At the receiving end, I would expect that a similar MTOM element would be
>created, with content set from the contents of the binary part.   It would
>then be possible to optimize the writing of that content to a file, etc.
>
>Of course, there are many variations on this theme, but I hope this gives
>a schematic sense of what I've been assuming optimized MTOM apis might be
>like.
>
>--------------------------------------
>Noah Mendelsohn
>IBM Corporation
>One Rogers Street
>Cambridge, MA 02142
>1-617-693-4036
>--------------------------------------

______________________________________________________
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 Monday, 17 November 2003 12:39:42 UTC