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 [email protected] > 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 [email protected] http://dankulp.com/blog
