Does that answer your question? ;)
For my sins, I have to interface with a server[1] which does something like this; in the previous version they had a semi-reasonable SOAP interface which compressed and base64'd some fields. The latest release of the product contains a 'new simplified' interface, where the request and response contain a single field - a compressed, base-64 encoded xml document.
There are a number of problems with this approach:
- it throws away interop. Try speccing what you described in WSDL.
- it throws away the serialization/deserialization engine, since you end up with a lump of XML you need to deal with by hand (I appreciate you're saying you think you can reset the SOAP message body after the fact, but it seems a bit wacky)
Probably because they realized there would be 'issues' writing a client for this, the product shipped with a half-assed java client which hid too much information, so I had to write us another one in order to continue working as we had with their previous releases. It ended up that the actual SOAP calls boiled down to 8 lines of code in a 700+ line wrapper that does all the ser/deser stuff - by hand. If they'd actually written their service so that WSDL for it made sense, I'd have been able to write /no/ code.
I understand there are interop issues with this just now, but compression is better left to the HTTP layer.
Cheers,
Baz
[1] I can't mention the company name because it might muck up our relation with them. But its a /big/ software company, you will have some of their software installed. They should have known better.
James Carman wrote:
I forgot to mention this. I have been toying with the idea of using a handler by gzipping up the entire SOAP part and putting it on the message as an attachment (and also removing all contents of the soap message). The receiver would then gunzip the attachment and set it as the SOAP part for the incoming message. Anybody have any thoughts/concerns with this approach?----- Original Message ----- From: "James Carman" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Friday, January 10, 2003 11:56 AM Subject: Re: gzip supportI would be very interested in the implementation also. Brian, you could also achieve the GZIP decompression/compression on the server using a reusable servlet filter quite easily, without extending AxisServlet.That'swhat I've considered, but I would like a more reciprocal relationship between the entities responsible for the decompression/compression on the client and server. Namely, I would rather do it using handlers ifpossible,or implement my own transport as you have said. ----- Original Message ----- From: "Brian W. Young" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Friday, January 10, 2003 11:35 AM Subject: re: gzip supportThanks for the input. I'm determined to make this work because without compression, I can't use Axis. I'm sending too much data for SOAP to be feasible w/o compression. Of course, I'll make any solution I implement available to the community. I found some info on handlers but not a lot, especially on handlers at the transport level. Here is what I am thinking. The HTTPSender class is apparently a client transport handler. I need to extend this class to wrap the output stream in a GZIP stream so that data going from the client to the server is compressed. I do not yet know how to make an Axis SOAP client use my new, extended HTTPSender class. On the server, it looks like all requests coming in come to the AxisServlet. I would assume I need to extend this servlet and wrap its InputStream in a GZIP stream, and then modify web.xml to use the new servlet instead. I've not found where on the server that I can put a handler which will decompress the inbound data. This approach may be incorrect. However, I have the skill set to implement a good solution if someone more knowledgable of Axis can give me some additional pointers. Let me know if this thread should move to the deveoper list. Thanks sincerely Brian Young >You should be able to write "Handlers" for Axis that will process the >messages (both client and server) on the way in/out. This would allow >you to support gzip'd data transparently. > >This is how Axis is designed, to be extensible. See the documentation >for architecture details. > >Note that on the client, you configure the handlers in the >'client-config.wsdd' file, pretty much the same way you do in the >server-config.wsdd file. > >Hope this helps point you in the right diirection. > >-- >Tom Jordahl >Macromedia Server Development
