xml-rpc-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Rall <...@finemaltcoding.com>
Subject Re: WebServer.java
Date Thu, 15 Aug 2002 16:43:33 GMT
"Rob Walker" <robw@softsell.com> writes:

> > I'd rather have the stability of a full-blown, maintained servlet
> > engine; XML-RPC's spec makes perfomant implementations difficult,
> > anyhow.  We avoid doing performance-critical operations over XML-RPC. In
> > the future, we will be using more and more Spread
> > <http://www.spread.org/>, perhaps eventually via JMS
> > <http://jms4spread.tigris.org/>.  We may install the XmlRpcServer as the
> > RPC layer to use over Spread or JMS. -- 
> Interesting - thanks for the links. I'll take a look
> Performance wise, maybe our app is peculiar, but for us XML/RPC 
> absolutely flies. We use it for a variety of things, but one aspect is remote 
> log and stats monitoring - which generates a very high rate/volume, of short 
> to medium size (http payload wise) xml/rpc calls. Once we got keep alive 
> figured, xml/rpc beat the daylights out of most other things we tried - direct 
> socket level, binary messaging was about the only thing to beat it, and then 
> not by enough to make the loss of flexibility worthwhile.

That's actually why I like message oriented middleware (MOM) so much.
A good implementation (such as Spread) provides a very thin layer
above TCP multicast sockets, yielding an extremely efficient
implementation.  JMS provides an excellent Java API abstraction which
works across MOM vendors.

I like Spread as my MOM provider do not only to its implementation
(which avoids a single point of failure), but also to the fact that
there are client language bindings for Java, Python, Perl, C (and I
think, Ruby).

Now, if you need RPC, you have to build something on top of the MOM.
Which is where XML-RPC could come in (let's not invent yet another
custom wire protocol, UGH).

Daniel Rall <dlr@finemaltcoding.com>

View raw message