> Can you explain this better? In particular, what do you see as the set of
> possible solutions of which none are elegant?
>
Solutions are cheaper to extend than others while maintaining
backward compatibility. For example adding a new field to an xml document
parsed by a custom parser is much simpler than adding a new field to a
SOAP document which some times breaks the client implementation (not to
mention trying to make this mandatory as of a certain version of the
protocol).
One of the options is to publish different protocols on different
URIs, but it still requires us to maintain different objects on our side
and after a number of releases it becomes hard to maintain. Another
approach would be to simple send over a object consisting only of hashes
and lists and the marshal and unmarshal them into real objects on the
server side this requires some extra work on the server and effectively
slows everything down. Sending XML over soap is no different than using
SOAP, you still have to create and parse it and with SOAP over it you are
adding extra overhead.
The other thing to be consider is availability of SOAP
implementations for perl. Currently available SOAP implementations are by
the order of magnitude slower than our OPS codec, which would pose a
significant performance impact both on the client side and the server side
(see a sample comparison below).
IMHO SOAP is great for applications where both ends of the
application are maintained in sync and the APIs do not change often. Both
are not the case for us.
I've thrown a quick test together to demonstrate the performance
differences done on my P4 2.4GHZ using a very simple SOAP request - with
one variable inside, this is just the encoding and decoding of the data.
I've seen relatively simple soap responses taking up to 40 ms to
deserialize.
Benchmark: timing 10000 iterations of OPS decode, OPS encode, SOAP::Lite
decode, SOAP::Lite encode...
OPS decode: 4 wallclock secs ( 3.68 usr + 0.01 sys = 3.69 CPU) @
2710.03/s (n=10000)
OPS encode: 0 wallclock secs (0.56 usr + 0.00 sys = 0.56 CPU) @
17857.14/s (n=10000)
SOAP::Lite decode: 11 wallclock secs (10.67 usr + 0.04 sys = 10.71 CPU) @
933.71/s (n=10000)
SOAP::Lite encode: 17 wallclock secs (16.40 usr + 0.04 sys = 16.44 CPU) @
608.27/s (n=10000)
Code of the benchmark is available if anyone is interested to see.
Leonid
On Mon, 27 Oct 2003 [EMAIL PROTECTED] wrote:
> How is this different from any deployed client-server application?
> This is a *VERY* weak straw man argument you've advanced, Leonid<g>
>
> John Roche
> einfosystems.net
> Microsoft Certified Partner
>
>
>
>
>
>
> -----Original Message-----
> From: Leonid Igolnik [mailto:[EMAIL PROTECTED]
> Sent: Sunday, October 26, 2003 11:48 PM
> To: Adam Selene
> Cc:
> Subject: Re: SSL certs on Horizon - pricing error?
>
>
> > SOAP over SSL would be the simplest and most standard,
> Although SOAP over SSL would very simple to implement and deploy, it
> creates a maintenance nightmare when changing method signatures. There
> is no
> elegant solution to this problem and IMHO this is a major problem with
> deploying SOAP in our environment. Replacing Blowfish and DES crypto
> with
> something more standard on the other hand is a different thing that is
> being worked on.
>
>
--
Leonid Igolnik.
