RPC/RMI in Perl
wiggly at wiggly.org
Wed Oct 15 01:00:59 BST 2008
> On Tue, Oct 14, 2008 at 5:21 PM, Aaron Trevena <aaron.trevena at gmail.com> wrote:
>> It sounds like you want CORBA rather than RPC/RMI given you're passing
>> objects about rather than calling remote methods or procedures on
>> objects that are in one place.
> Thanks, I'll take a look.
If you want to have the objects migrate then I wouldn't bother.
The RMI model is the same as the CORBA one with respect to objects, or,
In CORBA a Servant implements an Interface and can be contacted via an
IOR. The CORBA model doesn't let you know anything about the location of
the object, pesky location transparency...
It may decide to migrate it somewhere else behind your back. It might
not. CORBA IOR's and IIOP are designed so that this can be done via
redirection, proxying and bridging without the client knowing anything
So, if you want to definitely know where your objects are, CORBA,
possibly isn't for you.
>> Either way it's worth deciding if and explaining why you need to pass
>> objects around, rather than just invoke methods on them.
> The idea is that we have a Buffer which is basically a set of obejcts.
> The Buffer sits on Machine A and Machine B says "hey, Machine A, can I
> get an Object?", Machine A dutifully passes an Object to Machine B and
> removes it from its Buffer. The object should then only exist on
> Machine B, which can later put it back on the Buffer if necessary.
aside: You don't have objects anymore...if you can muck with their state
willy nilly then you've just broken encapsulation...and unless you also
send the subs that make up the objects accessors then you don't even
have the same behaviour on both machines, you're merely passing state
around. Not objects.
Having said that, if the data you pass around is serialised by the
object itself, and you know the implementations are identical on both
ends then you can migrate objects by sending their serialised state.
> What I really need is an Event::RPC which uses Data::Serializer to
> pass around objects. The question is do I get that by using Event::RPC
> and making my obejcts serialize themselves, by using RPC::Serialized
> but making it keep state, or in some other way entirely.
If you *really* *really* want to pass object state around like this then
I agree. You need your objects to be able to serialise their state. At
that point you have a blob of data that you can use *any* RPC mechanism
to shovel around the network. Possibly along with some metadata telling
the other side what kind of object you'd like it deserialised into if
there are multiple options.
In terms of what you should be using, I'd say you should choose your IPC
mechanism based on how much traffic you're going to have, how quick you
want to be able to build something and whether or not you're going to
need to interoperate with anything else (and this one also affects your
For RPC I'd avoid CORBA and Perl. The implementations (mainly badly done
XS bindings to other, C/C++ libraries) are poo-pants rubbish, and have
been for years. (I like CORBA, just not with Perl). Plus, if you don't
want the CORBA/RMI model anyway there's no point, you'll just end up
defining structs to hold your object states and be sending them over the
I'd be happy to provide a less vague answer if you can provide us with
some more detail.
aside: yes, I know, CORBA has Objects By Value but that was Sun being
childish whilst they were on the OMG committee...another few hundred
pages of spec that no-one wanted (Sun wanted RMI to win not CORBA) and
never got used. Pathetic isn't it?
More information about the london.pm