cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Kulp <dk...@apache.org>
Subject Re: [DISCUSS] Is there anyway to enable gzip encoding works with SOAP over Java Message Service 1.0
Date Tue, 07 Dec 2010 19:39:39 GMT

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

Mime
View raw message