SOAP, XML & RPC - some thoughts

djberg96 on 2002-03-04T05:43:55

I'm reading about XML::RPC (ok, I was reading about the *Ruby* implementation - sue me), and while I understand what it does, I'm confused by the philosophy of the whole thing.

Mainly, I don't understand the need to lump everything into one huge server that does *everything*, with predefined data classes to boot. Seems awfully inefficient and clunky. Reminds me of a macro-kernel approach. Not to mention the bureaucracy that will inevitably follow to actually get a method *added* to the precious server.

My plans for an RPC module will take the micro-kernel approach; keep the kernel (i.e. server) small and let the clients do the work. Let the clients define the methods/objects/code references they want to use and let the server handle them as the client wishes.

I suppose security is a big issue. But then, I've never designed a system where someone from the outside could ever get in without some other layer of security having been breached first (at which point, it would be too late anyway).

I'm really kinda excited about this. I think my idea is *better* than SOAP in some ways. Maybe I just don't fully comprehend SOAP. Maybe I'm delusional. Now, I just need some time and a flavor of *nix installed at home sometime soon.

REST

Matts on 2002-03-04T07:23:10

What you're talking about sounds a bit like the REST Architectural Style. I personally think it's a much better model for computer to computer communication than SOAP/XML-RPC, in fact I've been talking about it since way before it was even called REST (my 2001 OSCon talk about "Why SOAP Sucks", which I hope to be expanding on this year).

Interesting

djberg96 on 2002-03-04T13:55:36

Thanks for the link. What I'm planning will be even *more* flexible than simple interface genericity (at least as I understand it). There won't necessarily need to be an interface - the server will simply do what the client tells it to do (danger - "rm *" - danger). You won't have to know the methods - you can *make* the methods on the fly.

I should say, there will at least be an *option* to set up the server that way. In a secure intranet (i.e. no outside access), I don't see this as a problem. I realize this could be a loaded gun in the hands of a child programmer, so I'll have to plan out how I want to approach the security aspect.