Re: Proposed resolution for issue 440

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
--------------------------------------

Received on Thursday, 13 November 2003 17:31:31 UTC