You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cxf.apache.org by Freeman Fang <fr...@gmail.com> on 2010/12/07 12:30:12 UTC
[DISCUSS] Is there anyway to enable gzip encoding works with SOAP over Java Message Service 1.0
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
--
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
Re: [DISCUSS] Is there anyway to enable gzip encoding works with SOAP over Java Message Service 1.0
Posted by Freeman Fang <fr...@gmail.com>.
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-jms@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
> dkulp@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
Re: [DISCUSS] Is there anyway to enable gzip encoding works with SOAP over Java Message Service 1.0
Posted by Daniel Kulp <dk...@apache.org>.
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-jms@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
dkulp@apache.org
http://dankulp.com/blog
Re: [DISCUSS] Is there anyway to enable gzip encoding works with SOAP over Java Message Service 1.0
Posted by Freeman Fang <fr...@gmail.com>.
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-jms@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.
Previously our gzip encoding over http/jms actually use two
properties, Content-Encoding and Accept-Encoding, 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.
[1]http://lists.w3.org/Archives/Public/public-soap-jms/2010Dec/0001.html
Thanks
Freeman
On 2010-12-8, at 上午4:32, Christian Schneider wrote:
> 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
>
--
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
Re: [DISCUSS] Is there anyway to enable gzip encoding works with
SOAP over Java Message Service 1.0
Posted by Christian Schneider <ch...@die-schneider.net>.
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
Re: [DISCUSS] Is there anyway to enable gzip encoding works with SOAP over Java Message Service 1.0
Posted by Daniel Kulp <dk...@apache.org>.
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
--
Daniel Kulp
dkulp@apache.org
http://dankulp.com/blog
Re: [DISCUSS] Is there anyway to enable gzip encoding works with SOAP over Java Message Service 1.0
Posted by Freeman Fang <fr...@gmail.com>.
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
>>
>
>
> --
> Willem
> ----------------------------------
> FuseSource
> Web: http://www.fusesource.com
> Blog: http://willemjiang.blogspot.com (English)
> http://jnn.javaeye.com (Chinese)
> Twitter: willemjiang
--
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
Re: [DISCUSS] Is there anyway to enable gzip encoding works with
SOAP over Java Message Service 1.0
Posted by Willem Jiang <wi...@gmail.com>.
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
>
--
Willem
----------------------------------
FuseSource
Web: http://www.fusesource.com
Blog: http://willemjiang.blogspot.com (English)
http://jnn.javaeye.com (Chinese)
Twitter: willemjiang