RPC/RMI in Perl

[Nigel Rantor]

Kaoru wrote:
> 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, 
rather, interfaces.

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 
about it.

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.

I agree.

> 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 
serialisation scheme).

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 
wire.

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?

   n