Hi Dan,
Thanks for your input.
And Peter Easton, who is from Soap over JMS spec group told me the new
version spec including this proposal should be released soon, I just
create CXF-3174[1] to track this issue and when the new version spec
released, I'll add implementation accordingly.
[1]https://issues.apache.org/jira/browse/CXF-3174
Regards
Freeman
On 2010-12-8, at 上午10:25, Daniel Kulp wrote:
On Tuesday 07 December 2010 9:14:27 pm Freeman Fang wrote:
Hi Dan & Christian,
Thanks for your comment, and it's true that the jms providers like
Tibco EMS and Activemq allow compress messages a transport level.
The problem is that the SOAP over JMS spec currently doesn't support
the behavior for encoded(like gzip) message.
Fortunately, there's same discussion on public-soap-...@w3.org
maillinglist recently[1], and the new proposal seems can resolve our
encoding issue, more importantly in the new proposal is that
===> Change to section 2.4:
Replace "The bytes or characters of the JMS Message payload
correspond
to the MIME format as indicated by the definition of the contentType
property" with:
"After being decoded according to the contentEncoding property, the
bytes or characters of the JMS Message payload correspond to the MIME
format as indicated by the definition of the contentType property"
Here a new contentEncoding property is introduced, moreover, it
specify the behavior that we can "decode according to the
contentEncoding property", which is exactly what we want IMO.
That's cool. Great timing actually as that does indeed do exactly
what we
need.
Previously our gzip encoding over http/jms actually use two
properties, Content-Encoding and Accept-Encoding,
And that's because that is exactly what the HTTP spec calls for
using in this
case.
the behavior on
server side is that check the Content-Encoding for incoming message
first to know if we need decode gzip, and check Accept-Encoding to
see
if we can do gzip encoding for outgoing message(as Dan already
mentioned).
As now the new proposal only have contentEncoding property(but no
Accept-Encoding), how about we change the behavior on server side a
little bit, only check the Content-Encoding, if it's gzip encoding,
then we also do gzip encoding for outgoing message, that's said, if a
client sent out the gzip encoding message, it means client can
receive
a gzip encoding message also.
As long as we also still check for the Accept-Encoding as well.
Basically,
if Content-Encoding is gzip and Accept-Encoding is not specified
(the JMS
case), then go ahead and do gzip. If Accept-Encoding is gzip,
then go ahead
and gzip. Thus, a client can send a non-gzip message but with the
Accept-
Encoding set and get the gzip back.
Dan
[1]http://lists.w3.org/Archives/Public/public-soap-jms/2010Dec/0001.html
Thanks
Freeman
--
Daniel Kulp
dk...@apache.org
http://dankulp.com/blog
--
Freeman Fang
------------------------
FuseSource: http://fusesource.com
blog: http://freemanfang.blogspot.com
twitter: http://twitter.com/freemanfang
Apache Servicemix:http://servicemix.apache.org
Apache Cxf: http://cxf.apache.org
Apache Karaf: http://karaf.apache.org
Apache Felix: http://felix.apache.org
