By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
459,203 Members | 1,623 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 459,203 IT Pros & Developers. It's quick & easy.

SOAP Performance - Really so slow ?

P: n/a
>From my simple performance tests of SOAP it seems that it is about ten
times slower than binary object request protocols such as RMI, IIOP or
SimpleORB.
Is this also YOUR experience ?

Nov 28 '05 #1
Share this Question
Share on Google+
52 Replies


P: n/a
I think, that everybody will have the same experience, because using SOAP
means that you will get more data then in binary mode. And if data size is
larger then network transfer of this data will be slow...

However, the flavor of SOAP is interoperability with different systems (
e.g. you can have web service written in Java and clients on .NET or vice
versa ).
If interoprability is not your goal then it is better to use binary
protocols...

--
Vadym Stetsyak aka Vadmyst
http://vadmyst.blogspot.com
<fr**********@gmail.com> wrote in message
news:11**********************@g47g2000cwa.googlegr oups.com...
From my simple performance tests of SOAP it seems that it is about ten

times slower than binary object request protocols such as RMI, IIOP or
SimpleORB.
Is this also YOUR experience ?

Nov 28 '05 #2

P: n/a
....not to mention that serialization / deserialization will be slower,
and the routing of the request on the server side will be much slower.

As Vadym says, what SOAP (Web Services) give you is interoperability:
the option to use various technologies for your clients, now or in the
future.

Binary protocols are definitely faster, but they lock you into having a
..NET server and .NET clients forever....

Nov 28 '05 #3

P: n/a
If you want the advantages of interoperability AND the performance of a
binary protocol, then J-Integra is the solution. J-Integra offers
interoperability between .NET, Java, COM, and Corba applications
without the overhead of Web Services. The following whitepaper
summarizes a performance analysis of using J-Integra versus Web
Services for Java .NET interop...

http://j-integra.intrinsyc.com/pdfs/...ce_summary.pdf

Shane Sauer
J-Integra Interoperability Solutions
http://j-integra.intrinsyc.com/
high performance interop middleware for java, corba, com & .net

Nov 28 '05 #4

P: n/a
In article <11**********************@g47g2000cwa.googlegroups .com>,
fr**********@gmail.com wrote:
From my simple performance tests of SOAP it seems that it is about ten

times slower than binary object request protocols such as RMI, IIOP or
SimpleORB. Is this also YOUR experience ?


We had such problems at one point, then realized that we were doing a
SOAP call for simple data accessors. Once we bundled up the calls to be
somewhat higher level - returning whole collections of local objects,
for example, the overhead dropped to where we were willing to use SOAP.

If you are doing something very simple, RMI is going to just scream by
comparison to SOAP.

Scott

--
Scott Ellsworth
sc***@alodar.nospam.com
Java and database consulting for the life sciences
Nov 28 '05 #5

P: n/a
On 28 Nov 2005 12:06:06 -0800, fr**********@gmail.com wrote, quoted or
indirectly quoted someone who said :
From my simple performance tests of SOAP it seems that it is about ten

times slower than binary object request protocols such as RMI, IIOP or
SimpleORB.
Is this also YOUR experience ?


Just consider what goes down the wire for a
SOAP int.

<sometag>12345</sometag> = 24 chars.

vs two binary bytes.

--
Canadian Mind Products, Roedy Green.
http://mindprod.com Java custom programming, consulting and coaching.
Nov 28 '05 #6

P: n/a
It's always the same: "Industry Standards" are propagated, regardless
of actual performance or suitability. Just because SOAP is the hype,
all major vendors seem to promote it, without even thinking about
alternatives....
Publishing a "custom" client class library (for all major programming
languages) instead of WSDL would provide a tenfold better performance.
I wonder when the anti-SOAP backlash will happen....

Nov 28 '05 #7

P: n/a
fr**********@gmail.com wrote:
It's always the same: "Industry Standards" are propagated, regardless
of actual performance or suitability. Just because SOAP is the hype,
all major vendors seem to promote it, without even thinking about
alternatives....
Publishing a "custom" client class library (for all major programming
languages) instead of WSDL would provide a tenfold better performance.
I wonder when the anti-SOAP backlash will happen....


sure a custom or lightweight standard would give much higher
performance, but then we run into all kinds of problem areas:

technology - .net apps talking to mainframes...
Platform mapping - endianness
Language mapping - Java int is signed 32 bits, C++ has un/signed 1/2/4
bits depending upon complier.
etc...
All of these areas have been addressed in various ways by the various
comms standards: DCOM, CORBA, RMI, SOAP, etc..

Hell, most of the custom lightweight standards I've seen go over TCP/IP,
yet there are times when its preferable for sending data over raw UPD
sockets (as I've had to do in real time Telecoms apps).

What this boils down to, is that there is no 'Right' or 'OneTrue' way.

Each application needs to chose the right distributed technology for its
own characteristics.

Soap allows multiple different technologies, languages, platforms and
environments to communicate via a neutral 'self describing' means - but
this comes with a price - as you say slow performance.

but keep in mind, this slow performance may not actually be the bottle
neck within the system, so 'curing' it would be a false victory.
Andrew
Nov 29 '05 #8

P: n/a
j-***************@intrinsyc.com wrote:
If you want the advantages of interoperability AND the performance of a
binary protocol, then J-Integra is the solution. J-Integra offers
interoperability between .NET, Java, COM, and Corba applications
without the overhead of Web Services. The following whitepaper
summarizes a performance analysis of using J-Integra versus Web
Services for Java .NET interop...

http://j-integra.intrinsyc.com/pdfs/...ce_summary.pdf

Shane Sauer
J-Integra Interoperability Solutions
http://j-integra.intrinsyc.com/
high performance interop middleware for java, corba, com & .net


or there's ICE - http://www.zeroc.com/performance/index.html

which has the benefits of Corba without the rubbish and is highly
efficient too.

Andrew
Nov 29 '05 #9

P: n/a
Bruce Wood wrote:

Binary protocols are definitely faster, but they lock you into having a
.NET server and .NET clients forever....


Really? Actually I think binary protocols were used a long time before
..Net was invented.
Nov 29 '05 #10

P: n/a
On Tue, 29 Nov 2005 01:16:31 +0000, Andrew McDonagh
<ne**@andrewcdonagh.f2s.com> wrote, quoted or indirectly quoted
someone who said :
http://www.zeroc.com/performance/index.html


is that the right url?
--
Canadian Mind Products, Roedy Green.
http://mindprod.com Java custom programming, consulting and coaching.
Nov 29 '05 #11

P: n/a
On Tue, 29 Nov 2005 01:14:00 +0000, Andrew McDonagh
<ne**@andrewcdonagh.f2s.com> wrote, quoted or indirectly quoted
someone who said :
What this boils down to, is that there is no 'Right' or 'OneTrue' way.

Correct, but there are some ways that deserve to die they are so
inept.
--
Canadian Mind Products, Roedy Green.
http://mindprod.com Java custom programming, consulting and coaching.
Nov 29 '05 #12

P: n/a

<fr**********@gmail.com> wrote in message
news:11**********************@g47g2000cwa.googlegr oups.com...
From my simple performance tests of SOAP it seems that it is about ten

times slower than binary object request protocols such as RMI, IIOP or
SimpleORB.
Is this also YOUR experience ?


Can you quantify your results?

Thanks, Mike

----== Posted via Newsfeeds.Com - Unlimited-Unrestricted-Secure Usenet News==----
http://www.newsfeeds.com The #1 Newsgroup Service in the World! 120,000+ Newsgroups
----= East and West-Coast Server Farms - Total Privacy via Encryption =----
Nov 29 '05 #13

P: n/a
A hello-world (with one String as parameter) SOAP application was at
about 140 calls/sec when running the client and the server on the same
PC (2 GHz Athlon). RMI and SimpleORB would be at about 1600 calls/sec
with the same helloworld app, on the same machine.
This means that SOAP is an order of a magnitude slower than competing
technologies...
Regarding interoperability: CORBA and technologies like SimpleORB ARE
cross-platform, they might only need an http "converter" so that they
can tunnel through firewalls.

Nov 29 '05 #14

P: n/a
Hi,

Well, this is an extremely non-real-word :) benchmark, that would work
for cases where the request takes zero time at the server side, which is
not a common case, or is simply caused by a design flaw.

You say that you get 140 SOAP calls / sec = cca 7 ms per call, and 1600
RMI calls = cca 0.6 ms. But should the request take 10 ms to complete at
the server, the difference would be 17 ms vs. 10.6 ms, less than
two-fold. With a 100 ms request, this would be 107 ms compared to 100.6
ms, a difference that's completely negligible compared to the benefits
provided by SOAP.

Just my 2c.

Stefan

fr**********@gmail.com wrote:
A hello-world (with one String as parameter) SOAP application was at
about 140 calls/sec when running the client and the server on the same
PC (2 GHz Athlon). RMI and SimpleORB would be at about 1600 calls/sec
with the same helloworld app, on the same machine.
This means that SOAP is an order of a magnitude slower than competing
technologies...
Regarding interoperability: CORBA and technologies like SimpleORB ARE
cross-platform, they might only need an http "converter" so that they
can tunnel through firewalls.

Nov 29 '05 #15

P: n/a

Jon Martin Solaas wrote:
Bruce Wood wrote:

Binary protocols are definitely faster, but they lock you into having a
.NET server and .NET clients forever....


Really? Actually I think binary protocols were used a long time before
.Net was invented.


Yes, of course, but binary protocols tend to be technology-specific. If
you use RMI in Java then you are pretty-much stuck with having a Java
client and a Java server (or at least a server that speaks RMI). If you
use .NET Remoting then you are pretty-much stuck with writing all of
your clients in .NET.

Since the post was in a C# newgroup, I assumed that the OP would write
at least one part of the system in C#, and therefore if the OP were to
use a binary protocol it is a practical necessity that all other
parties in the communication also be .NET.

Of course, in theory this isn't really true. One could try to write a
Java client for .NET Remoting, for example, but I shudder at the
thought... you'd have to be a masochist to take that one on.

So, yes, I know that binary protocols were used a long time before .NET
was invented. Binary protocols came first... before any other kind of
protocol. However, I didn't really consider that pertienent to the
discussion. :-)

Nov 29 '05 #16

P: n/a
Ah. I see now that the OP cross-posted into a Java newsgroup. I hadn't
noticed that at first (the sins of using Google Groups). My apologies
to the Java folk for implying that "binary protocol = .NET"... it was a
problem of context. :-)

Nov 29 '05 #17

P: n/a

Roedy Green wrote:
On Tue, 29 Nov 2005 01:14:00 +0000, Andrew McDonagh
<ne**@andrewcdonagh.f2s.com> wrote, quoted or indirectly quoted
someone who said :
What this boils down to, is that there is no 'Right' or 'OneTrue' way.

Correct, but there are some ways that deserve to die they are so
inept.
--
Canadian Mind Products, Roedy Green.
http://mindprod.com Java custom programming, consulting and coaching.


Be that as it may, I beg to differ that SOAP / Web Services is one of
those "inept" ways that deserves to die.

In our case, for example, SOAP / Web Services is a godsend. We have a
legacy back-end consisting of millions of lines of code, and no, we're
not about to rewrite the thing in Java or C# just to make purists
happy. Web Services is the first thing we've seen that could open up
our closed mainframe-style architecture and start delivering some
results. Is it inefficient compared to binary protocols? Yup. However,
it's also the only practical way to deal with a heterogeneous
environment.

Binary protocols are efficient and easy to work with until you come up
against a system that has different parts written in different
languages. Then they quickly become a nightmare. For all of its
inefficiencies and problems, SOAP doesn't suffer from that one critical
flaw.

Sure, there may be a "SOAP backlash" coming from twits who use the
technology for absolutely everything, including inter-process
communication. However, the technology does fill a niche (and a huge
niche it is) that RMI, Remoting, etc. have never been able to
adequately address. I think that SOAP / Web Services are here to stay.

Nov 29 '05 #18

P: n/a
Everything I've ever heard about SOAP / Web Services says the same
thing: the protocol is heavyweight, so do everything you can to make
fewer calls and ship more information across the wire on each call. We
know that we have to design differently for WS than we would if we were
using a binary protocol.

Your "Hello World" app benchmark doesn't surprise me. In fact, it just
re-enforces what I had already heard. This doesn't mean that the
protocol is crap. All it means is that you have to keep in mind its
strengths and weaknesses when evaluating it and if you decide to start
writing code and using it.

So, yes, SOAP / WS has the weakness that each call carries with it a
lot of overhead. Tons of overhead. Its strength is that it's highly
interoperable. For highly interactive applications where the server and
all clients use the same language, SOAP / WS is probably not a smart
way to go. For applications that send few messages, each containing
potentially large amounts of data, high chance of flux in the data
contents, and widely varying technologies on the client side, SOAP / WS
is probably your best choice. It all depends upon what you're trying to
do and in what context.

Nov 29 '05 #19

P: n/a

"Bruce Wood" <br*******@canada.com> wrote in message
news:11*********************@g49g2000cwa.googlegro ups.com...
so do everything you can to make
fewer calls and ship more information across the wire on each call. We
know that we have to design differently for WS than we would if we were
using a binary protocol.


Could you elaborate a tad? Just what can be done?

Also, I'm not sure how to determine when a WS should be used over some
other techology. If I my business uses a Java server, then just use a Java
technology to pass the data. Is that how you are determining which to use?
What would be some other factors?

Thanks, Mike

----== Posted via Newsfeeds.Com - Unlimited-Unrestricted-Secure Usenet News==----
http://www.newsfeeds.com The #1 Newsgroup Service in the World! 120,000+ Newsgroups
----= East and West-Coast Server Farms - Total Privacy via Encryption =----
Nov 29 '05 #20

P: n/a

Mike Gaab wrote:
"Bruce Wood" <br*******@canada.com> wrote in message
news:11*********************@g49g2000cwa.googlegro ups.com...
>so do everything you can to make
fewer calls and ship more information across the wire on each call. We
know that we have to design differently for WS than we would if we were
using a binary protocol.
Could you elaborate a tad? Just what can be done?


Well, for example, the gurus recommend that Web Services be stateless.
That, along with the knowledge that each call carries a lot of overhead
makes us prefer to make one call to search for stock items and return
the whole list to the client, rather than writing a "get first / get
next" style interface. We also offer client programs fewer options as
to how much information is returned for each item, because it's better
to return more info than the client wanted than to have a client
calling over and over again to get progressively more information about
a particular item. "Return the entire result, and return enough or more
than enough information about each item on one call" is the philosophy
we're running with for now.

If we were running a binary interface we might have done it
differently: make more calls to finer-grained routines on the server
side.

Also, I'm not sure how to determine when a WS should be used over some
other techology. If I my business uses a Java server, then just use a Java
technology to pass the data. Is that how you are determining which to use?
What would be some other factors?


I think of it this way: If I have a server running Java, and I'm pretty
sure that all of my clients, now and in the future, will either be Java
clients or browser-based clients (which could be served by a Java-based
Web server), then I would go with RMI, knowing that that would, for all
practical purposes, lock me into Java forever. I would get much better
performance and it would be easier to make the whole thing work. The
price I pay is that if my bosses ever come to me and say that they want
me to write a C# client on a Windows handheld then I'm in a bit of
trouble. (At that point I would either talk them out of it or build Web
Services on top of the Java server framework and use those, but I
wouldn't really be leveraging all of that RMI investment.) Lots of
shops are one-language shops, and in that environment there's really no
reason to incur the performance penalties of Web Services.

If, on the other hand, there is a reasonable likelihood that I'll be
dealing with all sorts of clients, and browser-based won't cut it (so I
would need to deploy client apps on various client platforms), then I'd
seriously consider Web Services because of the interoperability, even
though the performance sucks (comparatively) and in some cases it's not
as solid as some of the binary protocols (depending upon whose app
server you're using).

In our case, it's our server side that's the problem. Our choices there
are extremely limited... basically it's Web Services or nothing for us
on the server side.

Nov 29 '05 #21

P: n/a
Roedy Green wrote:
On Tue, 29 Nov 2005 01:16:31 +0000, Andrew McDonagh
<ne**@andrewcdonagh.f2s.com> wrote, quoted or indirectly quoted
someone who said :

http://www.zeroc.com/performance/index.html

is that the right url?


yeah works for me - is not for you?
Nov 29 '05 #22

P: n/a
Bruce Wood wrote:
Roedy Green wrote:
On Tue, 29 Nov 2005 01:14:00 +0000, Andrew McDonagh
<ne**@andrewcdonagh.f2s.com> wrote, quoted or indirectly quoted
someone who said :

What this boils down to, is that there is no 'Right' or 'OneTrue' way.
Correct, but there are some ways that deserve to die they are so
inept.
--
Canadian Mind Products, Roedy Green.
http://mindprod.com Java custom programming, consulting and coaching.

Be that as it may, I beg to differ that SOAP / Web Services is one of
those "inept" ways that deserves to die.


Agreed -
In our case, for example, SOAP / Web Services is a godsend. We have a
legacy back-end consisting of millions of lines of code, and no, we're
not about to rewrite the thing in Java or C# just to make purists
happy. Web Services is the first thing we've seen that could open up
our closed mainframe-style architecture and start delivering some
results. Is it inefficient compared to binary protocols? Yup. However,
it's also the only practical way to deal with a heterogeneous
environment.

Binary protocols are efficient and easy to work with until you come up
against a system that has different parts written in different
languages. Then they quickly become a nightmare. For all of its
inefficiencies and problems, SOAP doesn't suffer from that one critical
flaw.

Sure, there may be a "SOAP backlash" coming from twits who use the
technology for absolutely everything, including inter-process
communication. However, the technology does fill a niche (and a huge
niche it is) that RMI, Remoting, etc. have never been able to
adequately address. I think that SOAP / Web Services are here to stay.


Those twits are usually (though not always) the same people who abuse
all distributed messaging technologies by creating tiny methods that
pull or push singular atomic data values between two points. Early
CORBA days were full of people creating Business Object models that had
the objects residing anywhere and then having set/gets & normal methods
on those objects. And they wondered why it did run very quickly?????

Even with SOAP I see people making this fundamental mistake.

Andrew
Nov 29 '05 #23

P: n/a
Stefan Simek wrote:
Hi,

Well, this is an extremely non-real-word :) benchmark, that would work
for cases where the request takes zero time at the server side, which is
not a common case, or is simply caused by a design flaw.

You say that you get 140 SOAP calls / sec = cca 7 ms per call, and 1600
RMI calls = cca 0.6 ms. But should the request take 10 ms to complete at
the server, the difference would be 17 ms vs. 10.6 ms, less than
two-fold. With a 100 ms request, this would be 107 ms compared to 100.6
ms, a difference that's completely negligible compared to the benefits
provided by SOAP.

Just my 2c.

Stefan

fr**********@gmail.com wrote:
A hello-world (with one String as parameter) SOAP application was at
about 140 calls/sec when running the client and the server on the same
PC (2 GHz Athlon). RMI and SimpleORB would be at about 1600 calls/sec
with the same helloworld app, on the same machine.
This means that SOAP is an order of a magnitude slower than competing
technologies...
Regarding interoperability: CORBA and technologies like SimpleORB ARE
cross-platform, they might only need an http "converter" so that they
can tunnel through firewalls.


:-) Nice!
Nov 29 '05 #24

P: n/a
On 29 Nov 2005 10:16:54 -0800, "Bruce Wood" <br*******@canada.com>
wrote, quoted or indirectly quoted someone who said :

Binary protocols are efficient and easy to work with until you come up
against a system that has different parts written in different
languages. Then they quickly become a nightmare. For all of its
inefficiencies and problems, SOAP doesn't suffer from that one critical
flaw.


A soap creator/parser is much more complex that a package to deal with
the wrong endianness of data. Just count lines of code to convert
binary to char to byte to char to binary compared with little endian
to big endian network order.

Soap has an illusion of simplicity because it is easy for humans to
deal with, but it is not humans dealing with it.
--
Canadian Mind Products, Roedy Green.
http://mindprod.com Java custom programming, consulting and coaching.
Nov 30 '05 #25

P: n/a

Roedy Green wrote:
On 29 Nov 2005 10:16:54 -0800, "Bruce Wood" <br*******@canada.com>
wrote, quoted or indirectly quoted someone who said :

Binary protocols are efficient and easy to work with until you come up
against a system that has different parts written in different
languages. Then they quickly become a nightmare. For all of its
inefficiencies and problems, SOAP doesn't suffer from that one critical
flaw.


A soap creator/parser is much more complex that a package to deal with
the wrong endianness of data. Just count lines of code to convert
binary to char to byte to char to binary compared with little endian
to big endian network order.


But it's not about just big-endian versus little-endian and low-level
concerns like that.

My point is that tools and frameworks for producing / consuming SOAP /
Web Services on all sorts of platforms and languages are sprouting up
like mushrooms. I don't have to write the bare-bones code that worries
about serialization, transport, and even (latterly) security and
encryption because it's all being done for me by hundreds of vendors.

The beauty of SOAP / WS isn't that it's easy for any particular vendor
to support it on any particular platform. In fact, as you pointed out,
it's not: it's bloody difficult, and getting more difficult by the
month as higher and higher level standards are created.

Instead, the beauty of SOAP / WS is that I as a consumer can buy an
application server that is designed to run services written in Java
from one vendor and a client platform for .NET clients from another
vendor and the two work together. CORBA never managed to get that much
market penetration. So far as I know the field of players trying to do
that sort of thing with RMI or .NET Remoting is thin indeed. If I can
grab products off the shelf and have them interoperate out of the box,
I don't care how much of a pain it was for the vendor to create them.
I'm happy. I'm even happier when vendor #1's client platform turns out
to be crap and I can just dump it and substitute another platform from
a competing vendor and it still works with my server-side Web Services.
I like the security of knowing that my whole system doesn't live or die
based on one vendor's ability to deliver, or even one language's
ability to deliver.

As well, my business partners can choose their own platforms and
languages and call my Web Services without knowing or caring what
language they're written in. Try doing that with .NET Remoting.

There's nothing wrong with RMI / Remoting / CORBA / whatever. They're
great technologies. However, they just don't have the vast market
penetration that Web Services is shaping up to have. As I said, if
interoperability between heterogeneous platforms is high on my list of
requirements, I probably won't be considering Java RMI as my protocol.
If I'm in a closed, all-Java shop, then that changes everything. Use
the right tool for the right job... and there are many jobs for which
SOAP is the right tool.

Nov 30 '05 #26

P: n/a
I got 1600 calls/s with RMI or SimpleORB and about 140 calls/s with
SOAP. Application was hello-world with one String as argument.

Nov 30 '05 #27

P: n/a
On 29 Nov 2005 17:46:22 -0800, "Bruce Wood" <br*******@canada.com>
wrote, quoted or indirectly quoted someone who said :
Instead, the beauty of SOAP / WS is that I as a consumer can buy an
application server that is designed to run services written in Java
from one vendor and a client platform for .NET clients from another
vendor and the two work together.

that is also true of CORBA or messages defined by ASN.1.
--
Canadian Mind Products, Roedy Green.
http://mindprod.com Java custom programming, consulting and coaching.
Nov 30 '05 #28

P: n/a
Potentially WRONG: Real-world requests will transfer much more data,
which produces a VERY lengthy SOAP message. SOAP is not just a huge
envelope around efficiently encoded data, but a lengthy envelope that
contains lenghty data structures.
Just look at the encoding of an integer:
<Integer xmlns="urn:vwservices">1</Integer>
That is 40 bytes for a single integer - about a factor of ten (actually
40 if intelligently encoded) worse than CORBA.
This means that multi-object messages are ALSO inefficient, because
each object/value if inefficiently encoded.

Nov 30 '05 #29

P: n/a
fr**********@gmail.com wrote:
Potentially WRONG: Real-world requests will transfer much more data,
which produces a VERY lengthy SOAP message. SOAP is not just a huge
envelope around efficiently encoded data, but a lengthy envelope that
contains lenghty data structures.
Just look at the encoding of an integer:
<Integer xmlns="urn:vwservices">1</Integer>
That is 40 bytes for a single integer - about a factor of ten (actually
40 if intelligently encoded) worse than CORBA.
This means that multi-object messages are ALSO inefficient, because
each object/value if inefficiently encoded.


hmmm couldn't this be easily solved by compression??

Nov 30 '05 #30

P: n/a

"Aquila Deus" <aq*********@gmail.com> wrote in message
news:11**********************@o13g2000cwo.googlegr oups.com...
fr**********@gmail.com wrote:
Potentially WRONG: Real-world requests will transfer much more data,
which produces a VERY lengthy SOAP message. SOAP is not just a huge
envelope around efficiently encoded data, but a lengthy envelope that
contains lenghty data structures.
Just look at the encoding of an integer:
<Integer xmlns="urn:vwservices">1</Integer>
That is 40 bytes for a single integer - about a factor of ten (actually
40 if intelligently encoded) worse than CORBA.
This means that multi-object messages are ALSO inefficient, because
each object/value if inefficiently encoded.


hmmm couldn't this be easily solved by compression??


http://www.osmoticweb.com/axis-soap-compression.htm

----== Posted via Newsfeeds.Com - Unlimited-Unrestricted-Secure Usenet News==----
http://www.newsfeeds.com The #1 Newsgroup Service in the World! 120,000+ Newsgroups
----= East and West-Coast Server Farms - Total Privacy via Encryption =----
Nov 30 '05 #31

P: n/a

"Mike Gaab" <mi****@montana.com> wrote in message
news:11**************@spool6-east.superfeed.net...

"Aquila Deus" <aq*********@gmail.com> wrote in message
news:11**********************@o13g2000cwo.googlegr oups.com...
fr**********@gmail.com wrote:
Potentially WRONG: Real-world requests will transfer much more data,
which produces a VERY lengthy SOAP message. SOAP is not just a huge
envelope around efficiently encoded data, but a lengthy envelope that
contains lenghty data structures.
Just look at the encoding of an integer:
<Integer xmlns="urn:vwservices">1</Integer>
That is 40 bytes for a single integer - about a factor of ten (actually
40 if intelligently encoded) worse than CORBA.
This means that multi-object messages are ALSO inefficient, because
each object/value if inefficiently encoded.


hmmm couldn't this be easily solved by compression??


http://www.osmoticweb.com/axis-soap-compression.htm

http://www-128.ibm.com/developerwork...s-sqzsoap.html

----== Posted via Newsfeeds.Com - Unlimited-Unrestricted-Secure Usenet News==----
http://www.newsfeeds.com The #1 Newsgroup Service in the World! 120,000+ Newsgroups
----= East and West-Coast Server Farms - Total Privacy via Encryption =----
Nov 30 '05 #32

P: n/a
On 29 Nov 2005 20:12:00 -0800, "Aquila Deus" <aq*********@gmail.com>
wrote, quoted or indirectly quoted someone who said :
<Integer xmlns="urn:vwservices">1</Integer>
That is 40 bytes for a single integer - about a factor of ten (actually
40 if intelligently encoded) worse than CORBA.
This means that multi-object messages are ALSO inefficient, because
each object/value if inefficiently encoded.


hmmm couldn't this be easily solved by compression??


Let's say you got 50% compression. You are down to 20 bytes per
integer verses 2. AND you have yet another cpu intensive step at both
ends.
--
Canadian Mind Products, Roedy Green.
http://mindprod.com Java custom programming, consulting and coaching.
Nov 30 '05 #33

P: n/a
Roedy Green wrote:
On 29 Nov 2005 20:12:00 -0800, "Aquila Deus" <aq*********@gmail.com>
wrote, quoted or indirectly quoted someone who said :
<Integer xmlns="urn:vwservices">1</Integer>
That is 40 bytes for a single integer - about a factor of ten (actually
40 if intelligently encoded) worse than CORBA.
This means that multi-object messages are ALSO inefficient, because
each object/value if inefficiently encoded.


hmmm couldn't this be easily solved by compression??


Let's say you got 50% compression. You are down to 20 bytes per
integer verses 2. AND you have yet another cpu intensive step at both
ends.


I plan to use it with AJAX, so the client-side cpu loading isn't
important, and the compression rate should be much higher than 50%
usually (most data transfered will be xml tags...). Besides, if I dont
use SOAP, what else can I choose?? IIOP over HTTP?

Nov 30 '05 #34

P: n/a
Roedy Green wrote:

Let's say you got 50% compression. You are down to 20 bytes per
integer verses 2. AND you have yet another cpu intensive step at both
ends.


With a suitable encoding, the protocol can be compacted by 80% while
reducing CPU load.

http://java.sun.com/developer/techni...rvices/fastWS/

Tom Hawtin
--
Unemployed English Java programmer
http://jroller.com/page/tackline/
Nov 30 '05 #35

P: n/a
Bruce Wood sez:
.... Instead, the beauty of SOAP / WS is that I as a consumer can buy an
application server that is designed to run services written in Java
from one vendor and a client platform for .NET clients from another
vendor and the two work together.


Uh-huh. The beauty of windows is that a consumer can buy a windows
peecee and go whenever he wants to today by just clicking on the
"Start" button.

When I become the Evil Overlord I'll have every SOAPophiliac do 3
years of system administration in heterogeneous environment before
they're allowed to comment on "ease" of SOAP.

Dima
--
.... If you want to make sure you don't put a Pig in a List of airplanes and
have it fail at insertion rather than extraction, use
planelist.add((Airplane)o) instead of planelist.add(o). It's that easy.
-- Mark 'Kamikaze' Hughes
Nov 30 '05 #36

P: n/a
Bruce Wood wrote:
Ah. I see now that the OP cross-posted into a Java newsgroup. I hadn't
noticed that at first (the sins of using Google Groups). My apologies
to the Java folk for implying that "binary protocol = .NET"... it was a
problem of context. :-)


Exactly. And I just realized it was posted on a .net-group too :-) My
point was merely that big bad binary protocol isn't just a dot-net
thingie. RMI and EJB-remoting is just as binary in the Java world.

--
jon martin solaas
Dec 1 '05 #37

P: n/a
Stefan Simek wrote:
Hi,

Well, this is an extremely non-real-word :) benchmark, that would work
for cases where the request takes zero time at the server side, which is
not a common case, or is simply caused by a design flaw.

You say that you get 140 SOAP calls / sec = cca 7 ms per call, and 1600
RMI calls = cca 0.6 ms. But should the request take 10 ms to complete at
the server, the difference would be 17 ms vs. 10.6 ms, less than
two-fold. With a 100 ms request, this would be 107 ms compared to 100.6
ms, a difference that's completely negligible compared to the benefits
provided by SOAP.

Just my 2c.


Or slightly rephrased - If the server takes forever to answer, the
protocol is irrelevant.

And if you consider message size and payload also, suddenly protocol
isn't that irrelevant again. Funny isn't it?

--
jon martin solaas
Dec 1 '05 #38

P: n/a
Aquila Deus wrote:
I plan to use it with AJAX, so the client-side cpu loading isn't
important, and the compression rate should be much higher than 50%
usually (most data transfered will be xml tags...). Besides, if I dont
use SOAP, what else can I choose?? IIOP over HTTP?


Aren't most remoting protocol networkable?

--
jon martin solaas
Dec 1 '05 #39

P: n/a

"Jon Martin Solaas" <jo***************@jahoo.nei> wrote in message
news:dm**********@bat-news01.banetele.basefarm.net...
Stefan Simek wrote:
Hi,

Well, this is an extremely non-real-word :) benchmark, that would work
for cases where the request takes zero time at the server side, which is
not a common case, or is simply caused by a design flaw.

You say that you get 140 SOAP calls / sec = cca 7 ms per call, and 1600
RMI calls = cca 0.6 ms. But should the request take 10 ms to complete at
the server, the difference would be 17 ms vs. 10.6 ms, less than
two-fold. With a 100 ms request, this would be 107 ms compared to 100.6
ms, a difference that's completely negligible compared to the benefits
provided by SOAP.

Just my 2c.


Or slightly rephrased - If the server takes forever to answer, the
protocol is irrelevant.

And if you consider message size and payload also, suddenly protocol isn't
that irrelevant again. Funny isn't it?


And what about routing, isn't that also a factor?
Isn't it really hard to benchmark something that is not deterministic?
(I know you can run lots of tests and that will tend to flatten some of the
peaks and valleys.)

Mike

----== Posted via Newsfeeds.Com - Unlimited-Unrestricted-Secure Usenet News==----
http://www.newsfeeds.com The #1 Newsgroup Service in the World! 120,000+ Newsgroups
----= East and West-Coast Server Farms - Total Privacy via Encryption =----
Dec 1 '05 #40

P: n/a
Jon Martin Solaas wrote:
Aquila Deus wrote:
I plan to use it with AJAX, so the client-side cpu loading isn't
important, and the compression rate should be much higher than 50%
usually (most data transfered will be xml tags...). Besides, if I dont
use SOAP, what else can I choose?? IIOP over HTTP?


Aren't most remoting protocol networkable?


Yes but XMLHttpRequest works with HTTP only....

Dec 1 '05 #41

P: n/a
Hi,

On Tue, 29 Nov 2005 17:46:22 -0800, Bruce Wood wrote:
There's nothing wrong with RMI / Remoting / CORBA / whatever. They're
great technologies. However, they just don't have the vast market
penetration that Web Services is shaping up to have. As I said, if I depends on what you mean with market penetration. As the standard Java
classlibraries have been including a CORBA implementation for years, I
think CORBA has been around and available for a long time. Before that,
Netscape included the Visibroker ORB in Navigator.

So, frankly, I do not think it is market penetration that causes people to
choose SOAP over CORBA. Personally, I think it is marketing, hype and
buzzwords working.

If SOAP had not been XML based, but a plain humanly
readable (ASCII or UTF-8) protocol, it wouldn't have been as popular as it
is now. And from most people, that's exactly what they claim is so great
about SOAP and XML-RPC. And actually, I don't really by into that argument
either, as a nice protocol analyzer (such as Ethereal) shows this info in
a much more human friendly form than looking at plain SOAP data.

The only nice thing about it imho, is that it works out of the box on
HTTP, making it easier to deploy then CORBA based applications.

But, in fact the reasoning behind this seems kind of strange too:
Sysadmins block everything but port 80, 'cause hey, there's "only
HTML/static content" passing through that port. And don't ask to open any
other ports to put a custom server online, because that's a security
hazard. But now, people hook up whatever servers they want behind a
dispatcher at port 80, and now people seem to believe there's no hazard
involved...
interoperability between heterogeneous platforms is high on my list of
requirements, I probably won't be considering Java RMI as my protocol. No, surely not: It sound like the prototype problem for a CORBA based
solution.
If I'm in a closed, all-Java shop, then that changes everything. Use
the right tool for the right job... and there are many jobs for which
SOAP is the right tool.

With friendly regards,
Takis
Dec 2 '05 #42

P: n/a
Hi,

On Mon, 28 Nov 2005 22:25:47 +0200, Vadym Stetsyak wrote:
I think, that everybody will have the same experience, because using SOAP
means that you will get more data then in binary mode. And if data size is
larger then network transfer of this data will be slow...

However, the flavor of SOAP is interoperability with different systems (
e.g. you can have web service written in Java and clients on .NET or vice
versa ).
If interoprability is not your goal then it is better to use binary
protocols...

Binary protocols or formats _do not_ prevent interoperability. The TCP/IP
stack is binary, the JPEG format is binary and numerous other formats are
binary and perfectly interoperable. The only thing that using non-binary
formats buy you is being able to use a "textviewer" to watch the protocol
on the wire (apps like cat, grep, more on Unix systems).

Being CORBA 2.x compliant requires supporting IIOP and thus 2.x compliant
CORBA implementations are interoperable. CORBA implementations are
available for numerous platforms (read: all) and numerous programming
languages.

The only reason SOAP is getting successful is because Microsoft's
refused to support the OMG standard. So now we'll have a new, albeit very
ineffecient "standard" protocol being SOAP.

With friendly regards,
Takis

Dec 2 '05 #43

P: n/a
On Thu, 01 Dec 2005 15:59:11 +0100, Jon Martin Solaas wrote:
Bruce Wood wrote:
Ah. I see now that the OP cross-posted into a Java newsgroup. I hadn't
noticed that at first (the sins of using Google Groups). My apologies
to the Java folk for implying that "binary protocol = .NET"... it was a
problem of context. :-)


Exactly. And I just realized it was posted on a .net-group too :-) My
point was merely that big bad binary protocol isn't just a dot-net
thingie. RMI and EJB-remoting is just as binary in the Java world.

Binary protocols are not "big bad" things. They are efficient and pretty
things if and only if they are openly specified :) Then there's no
reason for interoperability issues.

With friendly regards,
Takis
Dec 2 '05 #44

P: n/a
On Tue, 29 Nov 2005 10:06:12 -0800, Bruce Wood wrote:
Really? Actually I think binary protocols were used a long time before
.Net was invented.


Yes, of course, but binary protocols tend to be technology-specific. If
you use RMI in Java then you are pretty-much stuck with having a Java
client and a Java server (or at least a server that speaks RMI). If you
use .NET Remoting then you are pretty-much stuck with writing all of
your clients in .NET.

Yes, .Net is a Microsoft only solution, which will lock you into Microsoft
solutions and thus give you zero freedom of choice afterwards.

RMI is a nicer solutions since there are multiple vendors.

But the obvious solution for binary protocols is using IIOP (CORBA). It is
an open standard specified by the OMG being implemented by many vendors.
So if you choose for CORBA, you'll get freedom of choice. Which is
ofcourse not surprising, as choosing a standard has the obvious result of
giving you freedom of choice of a particular implementation.

With friendly regards,
Takis
Dec 2 '05 #45

P: n/a
On Tue, 29 Nov 2005 01:16:31 +0000, Andrew McDonagh wrote:
j-***************@intrinsyc.com wrote:
If you want the advantages of interoperability AND the performance of a
binary protocol, then J-Integra is the solution. J-Integra offers
interoperability between .NET, Java, COM, and Corba applications
without the overhead of Web Services. The following whitepaper
summarizes a performance analysis of using J-Integra versus Web
Services for Java .NET interop...

http://j-integra.intrinsyc.com/pdfs/...ce_summary.pdf

Shane Sauer
J-Integra Interoperability Solutions
http://j-integra.intrinsyc.com/
high performance interop middleware for java, corba, com & .net


or there's ICE - http://www.zeroc.com/performance/index.html

which has the benefits of Corba without the rubbish and is highly
efficient too.

It hasn't got the benefits of CORBA as it is *no standard*. There's only
_one_ implementation of ICE, being the one that ZeroC provides.

And in fact, I found it highly disappointing that ZeroC did not just
introduce a new nicer IDL C++ mapping for CORBA.

With friendly regards,
Takis
Dec 2 '05 #46

P: n/a
Panagiotis Issaris wrote:
On Tue, 29 Nov 2005 01:16:31 +0000, Andrew McDonagh wrote:

j-***************@intrinsyc.com wrote:
If you want the advantages of interoperability AND the performance of a
binary protocol, then J-Integra is the solution. J-Integra offers
interoperability between .NET, Java, COM, and Corba applications
without the overhead of Web Services. The following whitepaper
summarizes a performance analysis of using J-Integra versus Web
Services for Java .NET interop...

http://j-integra.intrinsyc.com/pdfs/...ce_summary.pdf

Shane Sauer
J-Integra Interoperability Solutions
http://j-integra.intrinsyc.com/
high performance interop middleware for java, corba, com & .net

or there's ICE - http://www.zeroc.com/performance/index.html

which has the benefits of Corba without the rubbish and is highly
efficient too.


It hasn't got the benefits of CORBA as it is *no standard*.


Benefits do not equal standards - or why else would we have POAs?

I've worked on enough telecoms projects which use lots of ratified
standards and each equipment manufacture implements those 'standards'
differently.

There's only
_one_ implementation of ICE, being the one that ZeroC provides.

And in fact, I found it highly disappointing that ZeroC did not just
introduce a new nicer IDL C++ mapping for CORBA.

Agreed - but ICE does a little more than that.
With friendly regards,
Takis

Dec 2 '05 #47

P: n/a
In article <11**********************@o13g2000cwo.googlegroups .com>,
Aquila Deus <aq*********@gmail.com> wrote:

hmmm couldn't this be easily solved by compression??


But then it becomes a binary protocol and you might as well just start
out with a binary one in the first place.

Cheers
Bent D
--
Bent Dalager - bc*@pvv.org - http://www.pvv.org/~bcd
powered by emacs
Dec 2 '05 #48

P: n/a
On Fri, 02 Dec 2005 15:48:12 +0000, Andrew McDonagh wrote:
or there's ICE - http://www.zeroc.com/performance/index.html

which has the benefits of Corba without the rubbish and is highly
efficient too.
It hasn't got the benefits of CORBA as it is *no standard*.


Benefits do not equal standards - or why else would we have POAs?

Well, yes, but by accepting the POAs you get portability, and thus you get
choice of middleware implementation and choice of middleware
vendor/support.
I've worked on enough telecoms projects which use lots of ratified
standards and each equipment manufacture implements those 'standards'
differently.

But does dumping all standards solve anything?

When I program according to the POSIX threading specs or to the CORBA
2.6 specs, I can migrate my application from one environment to another.
Not without any changes, but still easier then when I had programmed to a
proprietary interface.

They could have dumped the parts they didn't like, and which really made a
difference. But instead, they decided to write an "entirely new"
middleware stack... which _strongly_ resembles the existing standard, but
is different (mostly simplified).
There's only
_one_ implementation of ICE, being the one that ZeroC provides.

And in fact, I found it highly disappointing that ZeroC did not just
introduce a new nicer IDL C++ mapping for CORBA.

Agreed - but ICE does a little more than that.

If I were to believe their marketing page, it is the problem free solution
to all our problems, being efficient, scalable, easy and all other great
things.

On that same marketing page, they critisize CORBA for having many specs
being only implemented by "few" vendors. How many vendors implement ICE?
And this worries me too:
"Ice supports C++, Java, Python, PHP, C#, and Visual Basic. We are not
aware of any CORBA company that offers so much choice. In fact, most CORBA
vendors only offer C++ and Java. If you want to use other languages, you
have switch to different vendors, or consider using unsupported
experimental CORBA implementations."

In their mindset it is a problem if you have to rely on different vendors
for different software solutions: If you choose CORBA and want to use
multiple languages, you'll have to use products of many vendors. While if
you choose ICE, ZeroC can provide all your needs. Sounds very Microsoftish.

I would prefer to read that as: If you choose ZeroC you can only have
_one_ vendor: ZeroC.

With friendly regards,
Takis
Dec 2 '05 #49

P: n/a
On Fri, 02 Dec 2005 16:15:54 +0100, Panagiotis Issaris
<ta***@issaris.org> wrote, quoted or indirectly quoted someone who
said :
Binary protocols or formats _do not_ prevent interoperability. The TCP/IP
stack is binary, the JPEG format is binary and numerous other formats are
binary and perfectly interoperable.


The nice thing about binary formats is they are specified down to the
bit.

With any character based protocol there is always the ambiguity of
what encoding s supposed to be used. And even if the standard has
the balls to demand it, GUARANTEED you will soon find documents
floating about the universe with every encoding under the sun with
unmarked or mislabeled encodings.
--
Canadian Mind Products, Roedy Green.
http://mindprod.com Java custom programming, consulting and coaching.
Dec 2 '05 #50

52 Replies

This discussion thread is closed

Replies have been disabled for this discussion.