We have some large SOAP messages which should be sent to an external party (aprox 15MB). I was wondering if it is possible to enable request compression in a call to pub.client:soapClient. Compression of an HTTP request is not a common setup, as you can never be sure the receiver can handle the compression. That’s why normally, only responses are compressed if the Accept-Encoding header of the request contains “gzip” or “deflate”. However, from the HTTP specs, I understand the Content-Encoding header is also accepted for requests (it’s an Entity header), so we can just set the header “Content-Encoding” of the request to gzip, compress the request itself and send it to the web service provider. The provider should then be able to decompress the request.

This approach is available in other products, such as Apache Axis (using the HTTPConstants.MC_GZIP_REQUEST property), so maybe it is also available for webMethods? If not, would it be hard to create this functionality using a custom Java service? And would this be advisable?

Just want to make sure I understand the situation and what you want to achieve.

I’m interpreting that your web service provider currently do not accept compressed soap body message, and you’d like to enable compression on transport layer hoping that the app server hosting the provider can decompress it before passing to the soap handler.

Have I misinterpreted anything?

Thanks for your reply. Currently, the web service provider is not yet set up, we currently are adding some details to an application architecture where Software AG would send messages to different parties, using the same webservice which will be hosted at the different parties. These parties will use different technologies to provide this soap web service, so I want to setup a solution which is widely supported, however, we have the option to request these parties to support/enable additional compression functionalities.

The messages which are being sent to the different parties would have a lot of XML content. It’s not an attachment to the XML, but really just a lot of XML elements, resulting in an XML file of approx 15MB. To decrease the transfer time I want to compress this soap body. I see several options:

1. Compress the transport layer.
   This solution I already used in the past with other technologies to compress the soap response. This is a widely accepted solution, which improved the performance greatly, as in that case, the communication was over a wireless connection. However, now I want to compress the request instead of the response. It would be up to the web service provider to automatically detect the content is compressed, by interpreting the “Content-type” header. I still have to check which technologies accept compressed requests, but a first analysis leads me to believe this is accepted by the majority of the implementors. Before analysing this further, I first need to know if I can even create compressed requests in webMethods.

2. Compress the SOAP body
   I found information about binary message encoding which supports gzip compression, however, I only found information about this in Microsoft documentation, it doesn’t seem to be a widely accepted solution. Is this correct?

3. Using MTOM (Message Transmission Optimization Mechanism-
   This mechanism is used to compress binary data, which would normally be sent using base64 encoding. In my case, I want to send xml data, so this option doesn’t seem to be the most user-friendly solution.

So indeed in short, I would like to enable compression on the transport layer when sending the request to the soap webservice within webMethods.

There’s something a little off about your point 1, I feel that we are mixing topics there and generated concussion.

If going back to basics (that I think worth mentioning):

1. Web service works with WSDL, hence all parties “should” already know how to handle request/response data.

2. Regardless of soap request or response, they both have header and body elements. Soap message is just an envelope.

I’m not aware of any reason why it won’t work for request when compressed soap body data with added soap header works for response.

So here is my high level steps:

1. Consumer: compress data in request soap body.
2. Consumer: add compression meta data in request soap header.
3. Provider: read request soap header for compression meta data.
4. Provider: decompress request soap body data base on compression meta data.

HTH.

LoL, concussion reads confusion please. It wasn’t that bad.