You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@cxf.apache.org by Thomas Sauzedde <th...@gmail.com> on 2009/08/14 11:57:13 UTC

CXF client and generated SOAP requests : how to optimize namespaces declarations ?

Hi,

First of all, I'm a happy CXF user. Everything is working perfectly ;-)

On the project I'm working on I need to do some optimizations on the
bandwidth usage.

One "easy" way will be to reduce the size of  the generated SOAP
requests by removing redundant namespaces declarations.
(I'm talking about a CXF client)

In the provided sample (generated request that has been logged), is
there a way to put all the namespaces declarations in the <Envelope> tag
once and so avoid identical declarations below ?

Thanks in advance

--
Tom


Re: CXF client and generated SOAP requests : how to optimize namespaces declarations ?

Posted by Daniel Kulp <dk...@apache.org>.
Ah...  Yea.  I thought it was CXF on the server as well, not .NET.

With .NET on the server, about the only option would be to do the JAXB 
NamespaceMapper thing to reduce the number of namespaces written out.   You 
would need to configure the jaxb databinding with marshaller properties that 
contain the NamespaceMapper that you would need to write.   Definitely more 
involved.  :-(

Dan


On Fri August 14 2009 11:51:54 am Thomas Sauzedde wrote:
> Thanks for the fast & detailed answer !
>
> I've tried the two features ...
> The bad news is that I'm not in an easy position, because one feature
> does nothing, and the other is rejected :-(
>
> The server (.Net absolutely not under my control), simply ignore the
> FastInfoset header; so I suppose this is not a supported "encoding" on
> their side ...
>
> And, more strange, with the gzip feature it simply rejects all my request :
>
> HTTP/1.1 400 BadRequest
> Connection: close
> Date: Fri, 14 Aug 2009 15:39:14 GMT
> Server: Microsoft-IIS/6.0
> X-Powered-By: ASP.NET
> MSNSERVER: BL2MOBHGW3G07
> P3P:CP="BUS CUR CONo FIN IVDo ONL OUR PHY SAMo TEL o"
> X-AspNet-Version: 2.0.50727
> Cache-Control: private
> Content-Type: text/html
>
> If you (or someone else) have any other idea to preserve my bandwith,
> I'll be happy to read you ;-)
> Another precision, perhaps it could be important, my client is talking
> over HTTPS with the server ...
>
> Thanks again !
>
> --
> Tom
>
> Daniel Kulp a écrit :
> > I'm not sure much can be done in those cases.   In general, most of those
> > cases, (headers) they are kind of built up before they are even stuck in
> > a soap message.  You MIGHT be able to set some marshaller properties on
> > the JAXBDataBinding to include a JAXB NamespaceMapper thing which can be
> > used to prevent some of the useless namespaces from being outputted until
> > they are needed.   That may help a bit.
> >
> > For bandwidth, though, I'd HIGHLY HIGHLY recommend turning on the
> > FastInfoset feature and possibly the GZIP feature.  FastInfoset would
> > shrink that message down to easily 1/4 the size as all the strings and
> > such are just indexed into a table.  (side affect is that it's also MUCH
> > faster than normal soap parsing, also lowering CPU usage)   GZIP would
> > then compress it even more (although that then increases CPU usage).
> >
> > See the bottom of:
> > http://cwiki.apache.org/CXF20DOC/features.html
> > for how to configure the features.   See
> > http://cwiki.apache.org/CXF20DOC/featureslist.html
> > for the classnames for the GZIP and FastInfoset features.
> >
> > Note: both plugins are "negotiated" (unless you add force=true) in that
> > exising applications won't really change.  On the first request, the CXF
> > client will use a normal soap message and add "Accept" type headers and
> > if the feature is turned on on the server, the server will then respond
> > back with the compressed forms and the client will recognize that and
> > send subsequent requests compressed in same.   If the server doesn't see
> > the accept headers, it would return normal soap messages.   Thus,
> > existing clients that don't support gzip/fastinfoset would be unaffected.
> >
> > Also note: several other SOAP clients support FastInfoset and/or GZIP.  
> > I know Metro and Axis2 have support for FastInfoset.
> >
> >
> > Dan
> >
> > On Fri August 14 2009 5:57:13 am Thomas Sauzedde wrote:
> >> Hi,
> >>
> >> First of all, I'm a happy CXF user. Everything is working perfectly ;-)
> >>
> >> On the project I'm working on I need to do some optimizations on the
> >> bandwidth usage.
> >>
> >> One "easy" way will be to reduce the size of  the generated SOAP
> >> requests by removing redundant namespaces declarations.
> >> (I'm talking about a CXF client)
> >>
> >> In the provided sample (generated request that has been logged), is
> >> there a way to put all the namespaces declarations in the <Envelope> tag
> >> once and so avoid identical declarations below ?
> >>
> >> Thanks in advance
> >>
> >> --
> >> Tom

-- 
Daniel Kulp
dkulp@apache.org
http://www.dankulp.com/blog

Re: CXF client and generated SOAP requests : how to optimize namespaces declarations ?

Posted by Thomas Sauzedde <th...@gmail.com>.
Thanks for the fast & detailed answer !

I've tried the two features ...
The bad news is that I'm not in an easy position, because one feature
does nothing, and the other is rejected :-(

The server (.Net absolutely not under my control), simply ignore the
FastInfoset header; so I suppose this is not a supported "encoding" on
their side ...

And, more strange, with the gzip feature it simply rejects all my request :

HTTP/1.1 400 BadRequest
Connection: close
Date: Fri, 14 Aug 2009 15:39:14 GMT
Server: Microsoft-IIS/6.0
X-Powered-By: ASP.NET
MSNSERVER: BL2MOBHGW3G07
P3P:CP="BUS CUR CONo FIN IVDo ONL OUR PHY SAMo TEL o"
X-AspNet-Version: 2.0.50727
Cache-Control: private
Content-Type: text/html

If you (or someone else) have any other idea to preserve my bandwith,
I'll be happy to read you ;-)
Another precision, perhaps it could be important, my client is talking
over HTTPS with the server ...

Thanks again !

--
Tom

Daniel Kulp a écrit :
> I'm not sure much can be done in those cases.   In general, most of those 
> cases, (headers) they are kind of built up before they are even stuck in a 
> soap message.  You MIGHT be able to set some marshaller properties on the 
> JAXBDataBinding to include a JAXB NamespaceMapper thing which can be used to 
> prevent some of the useless namespaces from being outputted until they are 
> needed.   That may help a bit.
>
> For bandwidth, though, I'd HIGHLY HIGHLY recommend turning on the FastInfoset 
> feature and possibly the GZIP feature.  FastInfoset would shrink that message 
> down to easily 1/4 the size as all the strings and such are just indexed into 
> a table.  (side affect is that it's also MUCH faster than normal soap parsing, 
> also lowering CPU usage)   GZIP would then compress it even more (although 
> that then increases CPU usage).    
>
> See the bottom of:
> http://cwiki.apache.org/CXF20DOC/features.html
> for how to configure the features.   See
> http://cwiki.apache.org/CXF20DOC/featureslist.html
> for the classnames for the GZIP and FastInfoset features.
>
> Note: both plugins are "negotiated" (unless you add force=true) in that 
> exising applications won't really change.  On the first request, the CXF 
> client will use a normal soap message and add "Accept" type headers and if the 
> feature is turned on on the server, the server will then respond back with the 
> compressed forms and the client will recognize that and send subsequent 
> requests compressed in same.   If the server doesn't see the accept headers, 
> it would return normal soap messages.   Thus, existing clients that don't 
> support gzip/fastinfoset would be unaffected. 
>
> Also note: several other SOAP clients support FastInfoset and/or GZIP.   I 
> know Metro and Axis2 have support for FastInfoset.   
>
>
> Dan
>
>
>
> On Fri August 14 2009 5:57:13 am Thomas Sauzedde wrote:
>   
>> Hi,
>>
>> First of all, I'm a happy CXF user. Everything is working perfectly ;-)
>>
>> On the project I'm working on I need to do some optimizations on the
>> bandwidth usage.
>>
>> One "easy" way will be to reduce the size of  the generated SOAP
>> requests by removing redundant namespaces declarations.
>> (I'm talking about a CXF client)
>>
>> In the provided sample (generated request that has been logged), is
>> there a way to put all the namespaces declarations in the <Envelope> tag
>> once and so avoid identical declarations below ?
>>
>> Thanks in advance
>>
>> --
>> Tom
>>     
>
>   


Re: CXF client and generated SOAP requests : how to optimize namespaces declarations ?

Posted by Daniel Kulp <dk...@apache.org>.
I'm not sure much can be done in those cases.   In general, most of those 
cases, (headers) they are kind of built up before they are even stuck in a 
soap message.  You MIGHT be able to set some marshaller properties on the 
JAXBDataBinding to include a JAXB NamespaceMapper thing which can be used to 
prevent some of the useless namespaces from being outputted until they are 
needed.   That may help a bit.

For bandwidth, though, I'd HIGHLY HIGHLY recommend turning on the FastInfoset 
feature and possibly the GZIP feature.  FastInfoset would shrink that message 
down to easily 1/4 the size as all the strings and such are just indexed into 
a table.  (side affect is that it's also MUCH faster than normal soap parsing, 
also lowering CPU usage)   GZIP would then compress it even more (although 
that then increases CPU usage).    

See the bottom of:
http://cwiki.apache.org/CXF20DOC/features.html
for how to configure the features.   See
http://cwiki.apache.org/CXF20DOC/featureslist.html
for the classnames for the GZIP and FastInfoset features.

Note: both plugins are "negotiated" (unless you add force=true) in that 
exising applications won't really change.  On the first request, the CXF 
client will use a normal soap message and add "Accept" type headers and if the 
feature is turned on on the server, the server will then respond back with the 
compressed forms and the client will recognize that and send subsequent 
requests compressed in same.   If the server doesn't see the accept headers, 
it would return normal soap messages.   Thus, existing clients that don't 
support gzip/fastinfoset would be unaffected. 

Also note: several other SOAP clients support FastInfoset and/or GZIP.   I 
know Metro and Axis2 have support for FastInfoset.   


Dan



On Fri August 14 2009 5:57:13 am Thomas Sauzedde wrote:
> Hi,
>
> First of all, I'm a happy CXF user. Everything is working perfectly ;-)
>
> On the project I'm working on I need to do some optimizations on the
> bandwidth usage.
>
> One "easy" way will be to reduce the size of  the generated SOAP
> requests by removing redundant namespaces declarations.
> (I'm talking about a CXF client)
>
> In the provided sample (generated request that has been logged), is
> there a way to put all the namespaces declarations in the <Envelope> tag
> once and so avoid identical declarations below ?
>
> Thanks in advance
>
> --
> Tom

-- 
Daniel Kulp
dkulp@apache.org
http://www.dankulp.com/blog