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
