Mailing-List: contact axis-dev-help@ws.apache.org; run by ezmlm
Precedence: bulk
Reply-To: axis-dev@ws.apache.org
Received-SPF: pass (asf.osuosl.org: local policy)
Message-ID: <442DC270.3080101@thoughtcraft.com>
Date: Fri, 31 Mar 2006 18:59:44 -0500
User-Agent: Thunderbird 1.5 (Windows/20051201)
MIME-Version: 1.0
To: axis-dev@ws.apache.org
Subject: Re: [Axis2] Data binding attachments support
References: <442B6149.2050104@thoughtcraft.com>	
	<442B6C40.2060405@sosnoski.com>	
	<e9115cfd0603310135x1c9d3d4l6387a6bfc5eb7a9f@mail.gmail.com>	
	<1143812971.8353.27.camel@localhost.localdomain>	
	<19e0530f0603310553m12e50509nd8ac6226d3b0d007@mail.gmail.com>	
	<442D4240.6020906@thoughtcraft.com>	
	<1143819428.8353.32.camel@localhost.localdomain>	
	<19e0530f0603310755r23749a7eg4917575bb61c8e6f@mail.gmail.com>
	<1143833748.9435.4.camel@localhost.localdomain>
In-Reply-To: <1143833748.9435.4.camel@localhost.localdomain>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
From: Glen Daniels <glen@thoughtcraft.com>

Hey Sanjiva:

> On Fri, 2006-03-31 at 10:55 -0500, Davanum Srinivas wrote:
>> Let me try again...The DB framework will build the java objects
>> directly from the MIME root part (this is the first step always!) and
>> *then* accesses the other mime parts and sticks them where it is
>> needed (or adds a reference) on the java objects that it already
>> created. Except that OM tree is *never* built.
> 
> Ah but that's inconsistent with XOP .. if you do XOP, then when you look
> at the XML at the Infoset level (which is what you do when you look at
> the root part thru Axiom) then you have to un-XOPify it and just see the
> XML Infoset. There's no halfway point. 

Rrright, exactly.  The point is that while what you just said is 
perfectly true, you see the INFOSET (i.e. what you get out of 
XmlStreamReader) but not necessarily the OM tree.  So if a DB framework 
like JIBX wants to handle the XOP support itself, it can do that by 
doing something like this in the deserializer:

   ...deserializing from StAX events...
   if (currentElement.getQName().equals(XOP_INCLUDE)) {
     String contentID = getIDFromXopInclude();
     XOPThing binaryThing =
         new XOPThing(attachmentContext, contentID);
     // insert binaryThing into the object we're deserializing
   }
   ...continue...

XOPThing is this "future DataHandler" that we were talking about, maybe 
just a DataHandler.  But the point is it knows how to ask the 
AttachmentContext object (with an API like what Dennis proposes) for the 
actual InputStream and process it at the right time (obviously after all 
the XML has been pulled/deserialized from the root part - when the 
object tree is compete and the application asks for the image/data/etc).

As I'm thinking about it I wonder if we want to add a configuration 
option which would automatically "pre-cache" all the attachments into 
files immediately upon parsing the end of the root part, or if that 
should indeed be the default behaviour.  In other words, do we want to 
support pausing the read on the actual HTTP InputStream until the 
application asks for an attachment, much as we do with the SOAP envelope?

> What you're looking at is SwA .. MTOM is not that IMO.

Same deal for either really, just in one case you have hrefs and in 
another you have xop:Includes.

> I guess we could put a flag saying "don't unXOPify" but that seems like
> a hack.

You don't need a flag other than "don't cache" - which is really "don't 
build the Object Model".  If OM isn't building the Object Model, it 
can't very well do unXOPification (where would it put anything?).

>>  And on the sending
>> side, it generates stax events directly from the the java objects into
>> the MIME root part and adds the attachments into a bag while it is
>> doing so...again no OM tree in the picture at all.

+1 dims.

> Again, you're thinking like SwA and not like a single unified Infoset
> that has the binary parts logically in it. Think of WS-Security- how
> will your model work with WS-Sec turned on to sign the whole shebang?

Great point.  WS-Security (or anything else which requires the full 
infoset to be preserved in the OM as well as the databound objects) will 
need to switch on a flag which indicates "build the object model 
always".  So really, on the receiving side that flag should be an option 
on the OM builder which overrides a call to 
getXMLStreamReaderWithoutCaching() and turns it into a caching call. 
This is transparent to both the security code (which wants an OM) and 
the DB code (which wants StAX events) - both sides can get at the 
attachments using the correct APIs.  The optimization only works when no 
one sets the "always build the OM" flag, but other than that it should 
work transparently.

The same is true on the outbound side - if the flag is set, the StAX 
events won't go directly out to the OutputStream representing the root 
part of the MIME envelope (as they could in the optimized case), but 
instead build up an OM so that a security (or checksum, or whatever) 
handler can deal with it later.

Make sense?

--Glen