"Rob Walker" <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]>
