Re: customized encoding and SOAP interoperability

Michael,

----- Original Message -----
From: "Leventhal, Michael" <[email protected]>
To: <[email protected]>
Sent: Thursday, November 14, 2002 9:47 PM
Subject: Re: [SOAP] 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.
>

Your suggestion sounds good...and it could co-exist with my "hideous hack".
Thanks!

> 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.

In the long term - I agree that streamlining the processes will yield larger
returns. But even so, compression and streamlined processes could co-exist,
couldn't they?


> Cheers, Michael
>

Thanks for you comments! They were helpful.

Neela.

> -----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.
>

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