Re: customized encoding and SOAP interoperability

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.
A SOAP Processor which does not understand your header block
(and therefore doesn't know how to handle the compression) is
required to return a MustUnderstand fault to you. You can
respond to this SOAP Fault by resending without compression.

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.

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.

Cheers, Michael

-----Original Message-----
From: Neela Lakshminarayan [mailto:[email protected]]
Sent: Thursday, November 14, 2002 6:24 PM
To: [email protected]
Subject: Re: [SOAP] customized encoding and SOAP interoperability


----- Original Message -----
From: "Soumen Sarkar" <[email protected]>
To: <[email protected]>
Sent: Thursday, November 14, 2002 3:01 PM
Subject: Re: [SOAP] customized encoding and SOAP interoperability


> Customized encoding means you have compromised SOAP interoperability.
> Is there any reason not to expect so?

No - there's no reason not to expect so. I was wondering how big a price we
are paying for making this compromise.
As far as I can tell - it is probably one additional round trip. i.e our
client may send a customized encoding to a server that may not understand
this encoding. The server will hopefully return a HTTP 415 error. The client
will then send uncompressed content.
The client will also learn the fact that this server does not understand
this encoding and will not send customized encoded content to this server in
the future.


> To foster interoperability you
> may document well your encoding methods, have readily available
> implementation
> and be ready to share it with business partners.
>

Yes - that's a good idea. Thanks!

> Soumen Sarkar.
>

Neela

> -----Original Message-----
> From: Neela Lakshminarayan [mailto:[email protected]]
> Sent: Thursday, November 14, 2002 4:44 AM
> To: [email protected]
> Subject: [SOAP] customized encoding and SOAP interoperability
>
>
> We have a client communitcating with a Java Servlet through SOAP messages.
> The SOAP implementation is our own but it does conform to the SOAP
> specification. Since our response can be very verbose, we decided to
> compress our messages. For certain reasons, we are unable to use the
> standard encoding methods such as gZip, deflate, compress etc. We have a
> customized encoding. We don't like deviating from standards but in this
case
> we had to.
>
> My question is - by using a customized encoding, have we terribly
> compromised SOAP interoperability? Is customized encoding a terrible thing
> to do?
>
> Currently we don't care about being interoperable with other SOAP
toolkits -
> but the requirement might change in the future.
>
> Thanks,
> Neela
>
> You can read messages from the SOAP archive, unsubscribe from SOAP, or
> subscribe to other
> DevelopMentor lists at http://discuss.develop.com.
>
> You can read messages from the SOAP archive, unsubscribe from SOAP, or
subscribe to other
> DevelopMentor lists at http://discuss.develop.com.

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

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