471,306 Members | 838 Online
Bytes | Software Development & Data Engineering Community
Post +

Home Posts Topics Members FAQ

Join Bytes to post your question to a community of 471,306 software developers and data experts.

Problem with XML-RPC, possibly with SOAP too

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
Jul 17 '05 #1
2 2320
Li Ma wrote:
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.

--
Chris Gray ch***@kiffer.eunet.be

Jul 17 '05 #2
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

chris <ch***@kiffer.eunet.be> wrote in message news:<bu**********@reader10.wxs.nl>...
Li Ma wrote:
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.

Jul 17 '05 #3

This discussion thread is closed

Replies have been disabled for this discussion.

Similar topics

1 post views Thread by Dennis Westermann | last post: by
7 posts views Thread by Andy Fish | last post: by
2 posts views Thread by Billy Smith | last post: by
10 posts views Thread by Michael Strorm | last post: by
2 posts views Thread by Learner | last post: by
3 posts views Thread by Peppe | last post: by
2 posts views Thread by Colin Young | last post: by
1 post views Thread by sobczyk.wojciech | last post: by

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.