Problem with XML-RPC, possibly with SOAP too

[Li Ma]

Just want to share my experience on XML-RPC.

We were working on a messaging middleware. We were using XML-RPC as
communication protocol amoing client apps and server. Client could be
written by Java, C/C++, VB, Delphi on both Windows or Unix platforms.
Seams like XML-RPC( similiar to SOAP as you know) was a good choice
for us. But while the project went on, I encountered some critical
problems:

First of all, performance problem. Messages must be going accross
network in XML format, the encoding/decoding/transmition overhead made
the communcation slower than normal JMS/MQ/CORBA based systems.

The second problem was XML-RPC is built upon HTTP which is stateless
communication protocol and every time a remote call is invoked, a new
socket connection must be established. That slows down the speed a lot
too.

The third problem was since a new connection is needed on each call,
socket was not released right away( at least on Windows ), therefore
if messages are sent too frequently(more than a few hundreds per
second), no more socket connection can be made, and communication just
failed.

I never tried it on WebService platform, but as far as I understand,
web Service is mainly based-on SOAP for communication and SOAP is
similiar to XML-RPC, I guess it will create the same problem as we
had. Because of those problems we had to change our communication
layer to plain socket. With a dedicated socket connection, all the
problems above were easily gone.

Anyone had similiar problem as we had? Can you share your experience?

Li

 

[chris]

Just want to share my experience on XML-RPC.

We were working on a messaging middleware. We were using XML-RPC as
communication protocol amoing client apps and server. Client could be
written by Java, C/C++, VB, Delphi on both Windows or Unix platforms.
Seams like XML-RPC( similiar to SOAP as you know) was a good choice
for us. But while the project went on, I encountered some critical
problems:

First of all, performance problem. Messages must be going accross
network in XML format, the encoding/decoding/transmition overhead made
the communcation slower than normal JMS/MQ/CORBA based systems.

The second problem was XML-RPC is built upon HTTP which is stateless
communication protocol and every time a remote call is invoked, a new
socket connection must be established. That slows down the speed a lot
too.

The third problem was since a new connection is needed on each call,
socket was not released right away( at least on Windows ), therefore
if messages are sent too frequently(more than a few hundreds per
second), no more socket connection can be made, and communication just
failed.

Are you sure about the second and third problems? HTTP 1.1 allows sockets
to be re-used, and most recent implementations support this. I'm playing
with an XML-RPC application right now, and I don't see a ServerSocket being
created and destroyed for every remote call.

 

[Li Ma]

Yes, pretty positive. You can try write a little program to constantly
call server. after a few hundred or thousand calls, the call will
fail.

Use netstat to check used connections.

Maybe it is a XML-RPC problem. I'm using Apache XML-RPC for Java 1.1.

Anyone has tried on SOAP?

-Li