Re: customized encoding and SOAP interoperability

Neela Lakshminarayan wrote:
>>A "pure" SOAP way to do this, consistent with evolving practice
>>for security and encryption ... don't compress the entire SOAP
>>message, just your body content, and do it such that you still have
>>a valid XML document. Create a SOAP header block that specifies
>>that the payload is compressed, set to MustUnderstand true.
>>
>>This approach at least fits within the interoperability framework
>>and extension mechanism defined by SOAP as opposed to the hideous
>>hack you are inflicting on the SOAP world now.
>
> Your suggestion sounds good...and it could co-exist with my "hideous hack".

It is indeed an interesting suggestion, however it doesn't solve as much
of the performance problems related to parsing time as one would like in
a number of situations.

With large requests, a non-negligible amount of time is spent in the XML
parser, which isn't very efficient. That's why gzip compression rarely
helps because you need to gain more in transmission time than you loose
by adding compression-decompression steps.

I toyed with the option you describe and have found it rarely gains much
as well (unfortunately, as it would have been great for my project if I
could have used it).

There appeared to be interest from the WSDL people in adding flags to
WSDL documents to specify protocol binding options. Those could include
compression methods. If that were the case, it would be easy to be
interoperably simply by agreeing on compression methods at the WSDL level.

>>By the way, I have yet to see any situation where there is any
>>throughput gain in compressing XML. I suggest looking at the processes
>>you've created which are probably inefficiently handling your large
>>payloads.
>
> From the preliminary studies we've done, it seems that in some situations
> (typical to us) compression does pay off.
> We would need to change a lot of processes to ignore compression and get the
> same benefit.

The studies done here show the same result, but with gzip compression
being worthwhile only on large messages. The scheme we've been using
(and demonstrated at the recent XML Technoforum on Web Services) relies
on the transmission of binary infosets as described in the SOAP spec. We
get compression ratios between 2 and 200, with an average between 25 and
35 (depending on how structured the message is, which depends on the
service). Given that the decoding time is circa 10 times faster than an
XML parser working on the XML serialisation of the same infoset, the
overall request-response time shows very noticeable pay off.

I'd be interested in knowing if other people on this list have
experimented with binary infoset approaches, and what they have found.

--
Robin Berjon <[email protected]>
Research Engineer, Expway
7FC0 6F5F D864 EFB8 08CE  8E74 58E6 D5DB 4889 2488

You can read messages from the SOAP archive, unsubscribe from SOAP, or subscribe to other
DevelopMentor lists at http://discuss.develop.com.