cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christian Schneider <ch...@die-schneider.net>
Subject Re: [DISCUSS] Is there anyway to enable gzip encoding works with SOAP over Java Message Service 1.0
Date Tue, 07 Dec 2010 20:32:58 GMT
Hi all,

most jms providers allow to compress messages on the transport level. I 
guess this is a safe and unproblematic way.
For example in Tibco EMS you use the message property 
JMS_TIBCO_COMPRESS=true to enable compression.
In activemq it seems to be doMessageCompression=true in the connection url.

Best regards

Christian


Am 07.12.2010 20:39, schrieb Daniel Kulp:
> I would just say that once you configure in  the GZIP interceptors and such,
> you are kind of outside the SOAP/JMS spec.   By default, the GZIP stuff is
> negotiated anyway.   If a non-CXF SOAP/JMS client sends a message, it wouldn't
> have the Accept-Transfer-Encoding thing and thus the server would just respond
> back in the normal non-gzip form anyway.    Completely compliant.
>
> Dan
>
>
> On Tuesday 07 December 2010 8:24:00 am Freeman Fang wrote:
>> Hi Willem,
>>
>> Actually what my real concer  is the chapter 2.4 in the spec
>> 2.4 The JMS Message Body
>> The contents of the JMS Message body MUST be the SOAP payload as a JMS
>> BytesMessage or TextMessage. † [Definition: A fault MUST be generated
>> with subcode unsupportedJMSMessageFormat when the arriving message
>> format is not BytesMessage or TextMessage. † ]
>>
>> The bytes or characters of the JMS Message payload correspond to the
>> MIME format as indicated by the definition of the contentType
>> property. In this way, the SOAP node determines the proper formatting
>> of the SOAP payload irrespective of the underlying JMS message type,
>> and specifies an appropriate value for the contentType property which
>> describes it to the receiving SOAP node. Specifically, if the payload
>> is formatted as a MIME multipart message, then the first byte or
>> character encountered in the JMS Message body MUST be the start of the
>> MIME boundary for the start of the first part — what MIME Part One
>> [IETF RFC 2045] section 2.5 calls a "Body Part". † If the message is
>> formatted as "text/xml" or "application/soap+xml", then the first byte
>> or character of the JMS Message body MUST be the start of a conforming
>> XML document. †
>>
>>
>>
>> Regards
>>
>> Freeman
>>
>> On 2010-12-7, at 下午9:13, Willem Jiang wrote:
>>> Hi Freeman,
>>>
>>> I think as there is no Content-Encoding/Accept-Encoding "JMS Message
>>> Properties" defined in the specs, we are safe to extends the gzip
>>> support in soap over jms.
>>>
>>> If the server doesn't support the gzip encoding, CXF client can
>>> adjust itself, as this extension is not in the spec.
>>>
>>> Just my 2 cents.
>>>
>>> On 12/7/10 7:30 PM, Freeman Fang wrote:
>>>> Hi,
>>>>
>>>> Recently with [1]CXF-3146, I make an improvement to let gzip encoding
>>>> works over jms transport, but it's only applicable with cxf 2.2
>>>> branch,
>>>> as the jms transport with cxf 2.2 is a kind of proprietary
>>>> implementation.
>>>> Since cxf 2.3, cxf implements the soap over jms spec[2] which ensure
>>>> interoperability between the implementations of different Web
>>>> services
>>>> vendors. With this spec, seems there's noway we can enable gzip
>>>> encoding
>>>> over jms. I previously thought the main barrier is there's no
>>>> Content-Encoding/Accept-Encoding "JMS Message Properties" defined
>>>> in the
>>>> specs, but "JMS Message Properties" in the spec isn't exclusive so
>>>> that
>>>> seems we could have extend it to make at least both cxf client/server
>>>> over jms understand gzip encoding. But finally I realize that the
>>>> below
>>>> part in the spec is the real reason we can't use gzip encoding.
>>>>
>>>> 2.4 The JMS Message Body
>>>>
>>>> The contents of the JMS Message body MUST be the SOAP payload as a
>>>> JMS
>>>> BytesMessage or TextMessage. † [Definition: A fault MUST be
>>>> generated
>>>> with subcode unsupportedJMSMessageFormat when the arriving message
>>>> format is not BytesMessage or TextMessage. † ]
>>>>
>>>> The bytes or characters of the JMS Message payload correspond to the
>>>> MIME format as indicated by the definition of the contentType
>>>> property.
>>>> In this way, the SOAP node determines the proper formatting of the
>>>> SOAP
>>>> payload irrespective of the underlying JMS message type, and
>>>> specifies
>>>> an appropriate value for the contentType property which describes
>>>> it to
>>>> the receiving SOAP node. Specifically, if the payload is formatted
>>>> as a
>>>> MIME multipart message, then the first byte or character
>>>> encountered in
>>>> the JMS Message body MUST be the start of the MIME boundary for the
>>>> start of the first part — what MIME Part One [IETF RFC 2045]
>>>> section 2.5
>>>> calls a "Body Part". † If the message is formatted as "text/xml" or
>>>> "application/soap+xml", then the first byte or character of the JMS
>>>> Message body MUST be the start of a conforming XML document. †
>>>>
>>>>
>>>>
>>>> Is my understanding correct? Or is there any way we can implement the
>>>> gzip encoding without breaking the spec?
>>>>
>>>> Any comment is welcome.
>>>>
>>>> [1]https://issues.apache.org/jira/browse/CXF-3146
>>>> [2]http://www.w3.org/TR/soapjms/
>>>>
>>>> Thanks
>>>>
>>>> Freeman

-- 
----
http://www.liquid-reality.de


Mime
View raw message