FW: [DISCUSS] Is there anyway to enable gzip encoding works with SOAP over Java Message Service 1.0

-----Original Message-----
From: Peter Easton 
Sent: Tuesday, December 07, 2010 9:59 AM
To: 'Willem Jiang'; freeman fang
Subject: RE: [DISCUSS] Is there anyway to enable gzip encoding works with SOAP over Java Message Service 1.0

Hi Freeman,

Willem asked me join in on this. As it happens the SOAP/JMS WG is currently discussing the exact same issue, this time in the context of EXI encoding.

I am attaching the proposed spec changes to be discussed today - basically a new contentEncoding (but not acceptEncoding) property will be introduced.

You can see these discussions on:

http://lists.w3.org/Archives/Public/public-soap-jms/


Peter
.....

From: Eric Johnson <eric@tibco.com> 
Date: Mon, 06 Dec 2010 12:06:26 -0800
Message-ID: <4CFD4242.1030306@tibco.com> 
To: SOAP-JMS <public-soap-jms@w3.org> 

Completing my ACTION-232, updating this proposal with two changes:

  * Add the fault to the schema section.
  * Add an explicit bullet that the contentEncoding is not supported for 
multipart messages, as per text from Amy.

===> Add to section 2.2.3:

[Definition: soapjms:contentEncoding] (xsd:string)
   * Identifies the transformation that has been applied to the message 
payload body.  Contains one of the values defined by IANA for the 
Content-Coding values of [IANA HTTP PARAMS].  Defaults to "identity" if 
the property is not present.
   * Corresponds to the JMS Message property named SOAPJMS_contentEncoding
   * [Definition: If the content encoding is specified, it is checked to 
ensure that it matches the content encoding values supported. A fault 
MUST be generated with subcode contentEncodingNotSupported if the 
encoding values do not match.†]
   * Restriction: the meaning of the property is not defined for 
composite messages (messages with a Content-Type of "multipart" or 
"message"), only for discrete messages (Content-Type "application" or 
"text", for this specification).

===> 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"

===> Addition to section 2.4.1

New bullet point:
  * Use of the contentEncoding property is not defined, since the 
underlying message payload is not raw bytes.

===> Add to section 2.8

Add an entry for contentEncodingNotSupported to the list in this section.

===> Add to section A.1 (Normative References)

[IANA HTTP PARAMS]
   Hypertext Transfer Protocol (HTTP) Parameters, Internet Assigned 
Names And Numbers (IANA), Sept. 2, 2009, Available at 
http://www.iana.org/assignments/http-parameters/http-parameters.xml

==== Add to Appendix B:

In the definition of FaultCodesType, add:

       <xs:enumeration value="soapjms:contentEncodingNotSupported"/>

===== ******* =====


-----Original Message-----
From: Willem Jiang [mailto:willem.jiang@gmail.com] 
Sent: Tuesday, December 07, 2010 8:57 AM
To: Peter Easton
Cc: freeman fang
Subject: Fwd: [DISCUSS] Is there anyway to enable gzip encoding works with SOAP over Java Message Service 1.0


Hi Peter

Freeman raised a discussion about adding gzip encoding support on CXF. 
The main concern of him is if this change will introduce any 
incompatibility of SOAP over JMS spec.

Would you please jump into the discussion?


-------- Original Message --------
Subject: [DISCUSS] Is there anyway to enable gzip encoding works with 
SOAP over Java Message Service 1.0
Date: Tue, 7 Dec 2010 19:30:12 +0800
From: Freeman Fang <freeman.fang@gmail.com>
Reply-To: dev@cxf.apache.org
To: dev@cxf.apache.org

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

Received on Tuesday, 7 December 2010 17:21:13 UTC