You are viewing a plain text version of this content. The canonical link for it is here.
Posted to java-dev@axis.apache.org by Glen Daniels <gd...@sonicsoftware.com> on 2004/11/19 19:53:39 UTC
[Axis2] MTOM sketch
Hey OM folks:
I put up a very tiny model of how I was thinking the
OM/SerializationContext/Writer stuff might fit together for supporting
ser/deser and MTOM. It's in the MTOMToy/ directory of my scratch area.
--Glen
Re: [Axis2] MTOM sketch
Posted by thilina Gunarathne <cs...@gmail.com>.
Hi,
On Sat, 20 Nov 2004 17:26:31 -0800 (PST), Dasarath Weeratunge
<da...@yahoo.com> wrote:
> Hi
>
> Thilina, why do you want to revert back anyway? If you
> optimize when you selialize then it is obvious that
> the other party needs to know how to deserialize such
> a message. I think the sender can get this info in
> advance like from wsdl/policies ... So before
> serializing one decides whether or not to optimize.
>
> My worry is can there be elements which are not
> optimized in an optimized message? Say you have two
> jpeg s and when serializing for whatever reason you
> choose to optimize one but not the other. Is this
> allowed?
>
> --Dasarath
>
>
It is allowed. You can optimize parts of the message.It is in the MTOM spec.
~Thilina
Re: [Axis2] MTOM sketch
Posted by Dasarath Weeratunge <da...@yahoo.com>.
Hi
Thilina, why do you want to revert back anyway? If you
optimize when you selialize then it is obvious that
the other party needs to know how to deserialize such
a message. I think the sender can get this info in
advance like from wsdl/policies ... So before
serializing one decides whether or not to optimize.
My worry is can there be elements which are not
optimized in an optimized message? Say you have two
jpeg s and when serializing for whatever reason you
choose to optimize one but not the other. Is this
allowed?
--Dasarath
--- thilina Gunarathne <cs...@gmail.com> wrote:
> HI,
> >
> > >If not in a case where we fail to create MTOM (ex
> : if the
> > >infoset contains a item with namespace
> "www.w3...../xop/include") we
> > >cannot revert back to base 64. Any suggestions.
>
> My mistake. not to MTOM with base 64. but to pure
> SOAP with base 64.
>
>
> > >
> > >
> > why you can not revert back? you can always stream
> binary into byte[]
> > and convert to BASE64 - the only reason i would
> want to disable it (or
> > throw exception) may be to avoid
> OutOfMemoryException when streaming of
> > binary *is* required.
> >
> > any other reasons?
> >
>
> My concern is what to do if we want to revert back
> to xml SOAP infoset
> (not to base 64 :) ) while we are writing the xop
> MTOM message. once
> we have started to write the mime envelop reverting
> back to plain xml
> SOAP will be a problem.
> One suggestion is to construct the whole SOAP
> message part first with
> "includes & href to Mime parts" when serializing for
> MTOM . And
> then put that SOAP it in to the mime(or construct
> the mime including that soap).
>
> thanks & regards
> ~thilina
>
__________________________________
Do you Yahoo!?
Meet the all-new My Yahoo! - Try it today!
http://my.yahoo.com
Re: [Axis2] MTOM sketch
Posted by thilina Gunarathne <cs...@gmail.com>.
HI,
>
> >If not in a case where we fail to create MTOM (ex : if the
> >infoset contains a item with namespace "www.w3...../xop/include") we
> >cannot revert back to base 64. Any suggestions.
My mistake. not to MTOM with base 64. but to pure SOAP with base 64.
> >
> >
> why you can not revert back? you can always stream binary into byte[]
> and convert to BASE64 - the only reason i would want to disable it (or
> throw exception) may be to avoid OutOfMemoryException when streaming of
> binary *is* required.
>
> any other reasons?
>
My concern is what to do if we want to revert back to xml SOAP infoset
(not to base 64 :) ) while we are writing the xop MTOM message. once
we have started to write the mime envelop reverting back to plain xml
SOAP will be a problem.
One suggestion is to construct the whole SOAP message part first with
"includes & href to Mime parts" when serializing for MTOM . And
then put that SOAP it in to the mime(or construct the mime including that soap).
thanks & regards
~thilina
Re: [Axis2] MTOM sketch
Posted by Aleksander Slominski <as...@cs.indiana.edu>.
thilina Gunarathne wrote:
>Hi,
>
>
Hi Thilina,
>I'm implementing MTOM for axis2 as one of my undergratuate projects
>(level3). for the last few days i've been workin on to develop a
>prototype for mtom to clarify some issues.
>
>luckily the mtom toy has clarified most of them.
>In my case i've been planning to use some mime class package to create
>the mime parts. (ex. javax.xml.soap , javamail ).
>Will it add any performance penalty. Will there be an advantage of
>writing the code my self to handle mime.
>
>One more thing i've faced up is how to identify whether the receiving
>endpoint supports MTOM when sending the messages.
>
>
that probably will be part of some metadata, WSDL, WS-policy, or
discovered by WS-MeX.
>Other than having two writers (MTOM & OM) I thought of having one
>writer. Then we can decide within the writer whether to send a MTOM or
>base64.
>
that is always an option and main advantage of MTOM: binary data *is*
part of XML Infoset just if not "optimized" it looks like BASE64.
>If not in a case where we fail to create MTOM (ex : if the
>infoset contains a item with namespace "www.w3...../xop/include") we
>cannot revert back to base 64. Any suggestions.
>
>
why you can not revert back? you can always stream binary into byte[]
and convert to BASE64 - the only reason i would want to disable it (or
throw exception) may be to avoid OutOfMemoryException when streaming of
binary *is* required.
any other reasons?
i am writing my own MTOM toy too so we will have more to discuss.
thanks,
alek
>
>
>
>On Fri, 19 Nov 2004 13:53:39 -0500, Glen Daniels
><gd...@sonicsoftware.com> wrote:
>
>
>>Hey OM folks:
>>
>>I put up a very tiny model of how I was thinking the
>>OM/SerializationContext/Writer stuff might fit together for supporting
>>ser/deser and MTOM. It's in the MTOMToy/ directory of my scratch area.
>>
>>--Glen
>>
>>
>>
--
The best way to predict the future is to invent it - Alan Kay
Re: [Axis2] MTOM sketch
Posted by thilina Gunarathne <cs...@gmail.com>.
Hi,
I'm implementing MTOM for axis2 as one of my undergratuate projects
(level3). for the last few days i've been workin on to develop a
prototype for mtom to clarify some issues.
luckily the mtom toy has clarified most of them.
In my case i've been planning to use some mime class package to create
the mime parts. (ex. javax.xml.soap , javamail ).
Will it add any performance penalty. Will there be an advantage of
writing the code my self to handle mime.
One more thing i've faced up is how to identify whether the receiving
endpoint supports MTOM when sending the messages.
Other than having two writers (MTOM & OM) I thought of having one
writer. Then we can decide within the writer whether to send a MTOM or
base64. If not in a case where we fail to create MTOM (ex : if the
infoset contains a item with namespace "www.w3...../xop/include") we
cannot revert back to base 64. Any suggestions.
regards,
~Thilina
On Fri, 19 Nov 2004 13:53:39 -0500, Glen Daniels
<gd...@sonicsoftware.com> wrote:
>
> Hey OM folks:
>
> I put up a very tiny model of how I was thinking the
> OM/SerializationContext/Writer stuff might fit together for supporting
> ser/deser and MTOM. It's in the MTOMToy/ directory of my scratch area.
>
> --Glen
>
RE: [Axis2] MTOM sketch
Posted by Eran Chinthaka <ch...@gmail.com>.
Hi,
Glen thankx for this pattern.
BTW, we also was thinking of implementing MTOM in the same way, except we
thought of keeping the "content" in your impl, in a separate OMNode, which
we referred to as a BinaryNode. And I think this is same as the XMLInclude
node Alek was referring to.
And I would like to see the OMWriter implementing the ContentHandler
interface also, so that OMWriter will be a place to serialize the whole
content in OM. (Glen has specially stated that his impl is not serializing
attribs, namespaces, etc., ContentHandler will do that.)
In other words we were thinking of exposing OM through a Push interface,
expecially in the outpath. So we integrate that idea to OM by implementing
ContentHandler interface to OMWriter.
So from OM user point of view, he creates one of the derived classes of
OMWriter and ask an OMElement to serialize using that. Some of the
serialization logic is within the OMElement itself !!!.
This seems really cool to me and I already wrote a ContentHandler impl for
OM.
>>-----Original Message-----
>>From: Glen Daniels [mailto:gdaniels@sonicsoftware.com]
>>Sent: Saturday, November 20, 2004 12:54 AM
>>To: axis-dev@ws.apache.org
>>Subject: [Axis2] MTOM sketch
>>
>>
>>Hey OM folks:
>>
>>I put up a very tiny model of how I was thinking the
>>OM/SerializationContext/Writer stuff might fit together for supporting
>>ser/deser and MTOM. It's in the MTOMToy/ directory of my scratch area.
>>
>>--Glen