Re: Remote commands

Jens Gruschel wrote:
> I'd like to implement some kind of RPC mechanism, executing some 
> commands on another machine. Now I don't like to use CORBA or another 
> standard RPC mechanism, but code this fairly simple thing by myself. 
> Technically it's no problem at all, but I'm a bit unsure what's the best 
> design and how I should name my classes.
> 
> For the sender my first thought was to base it on a modified command 
> design pattern (some serialization method instead of an execute method) 
> like this:
> 
> TRemoteCommand = class
> public
>   procedure Serialize(const OutStream: TStream); virtual; abstract;
> end;
> 
> A sender object would call the Serialize method and send the stream over 
> a socket connection or whatever. Alternatively I could do it like this:
> 
> TRemoteCommand = class
> protected
>   procedure Serialize(const OutStream: TStream); virtual; abstract;
> public
>   procedure Execute(const Sender: TRemoteCommandSender);
> end;
> 
> The Execute method would call Serialize passing a stream created by the 
> sender.
> 
> Of course I'd have to register the concrete command classes somehow, 
> giving them a unique id (sent over the network together with the 
> parameter data).
> 
> But what would I have on the receiver side? Some kind of observer 
> objects registered with the same id? My first thoughts were something 
> like this:
> 
> TRemoteCommandObserver = class
> public
>   procedure Serialize(const InStream: TStream); virtual; abstract;
>   procedure Update/Execute/Handle/Process(?); virtual; abstract;
> end;
> 
> But I think that's not a real observer, except that some other class 
> (the one receiving the streams) has a subscribe and an unsubscribe 
> method for it. So how could I name it and where should I change my 
> design? Would it make any sense to create command objects on the 
> receiver side? It's really very simple and I think I could do it with a 
> few if/then/else statements within one simple class receiving the data, 
> however I'd like to have a more beautiful design. Any thoughts?
> 
> P.S. And are there any network design patterns? I'm only aware of the 
> "normal" ones suitable for a single process on a single machine.
> 

Proxy Pattern ? :)

-- 
Warm Regards,

I'd like to implement some kind of RPC mechanism, executing some 
commands on another machine. Now I don't like to use CORBA or another 
standard RPC mechanism, but code this fairly simple thing by myself. 
Technically it's no problem at all, but I'm a bit unsure what's the best 
design and how I should name my classes.

For the sender my first thought was to base it on a modified command 
design pattern (some serialization method instead of an execute method) 
like this:

TRemoteCommand = class
public
   procedure Serialize(const OutStream: TStream); virtual; abstract;
end;

A sender object would call the Serialize method and send the stream over 
a socket connection or whatever. Alternatively I could do it like this:

TRemoteCommand = class
protected
   procedure Serialize(const OutStream: TStream); virtual; abstract;
public
   procedure Execute(const Sender: TRemoteCommandSender);
end;

The Execute method would call Serialize passing a stream created by the 
sender.

Of course I'd have to register the concrete command classes somehow, 
giving them a unique id (sent over the network together with the 
parameter data).

But what would I have on the receiver side? Some kind of observer 
objects registered with the same id? My first thoughts were something 
like this:

TRemoteCommandObserver = class
public
   procedure Serialize(const InStream: TStream); virtual; abstract;
   procedure Update/Execute/Handle/Process(?); virtual; abstract;
end;

But I think that's not a real observer, except that some other class 
(the one receiving the streams) has a subscribe and an unsubscribe 
method for it. So how could I name it and where should I change my 
design? Would it make any sense to create command objects on the 
receiver side? It's really very simple and I think I could do it with a 
few if/then/else statements within one simple class receiving the data, 
however I'd like to have a more beautiful design. Any thoughts?

P.S. And are there any network design patterns? I'm only aware of the 
"normal" ones suitable for a single process on a single machine.

-- 
Jens Gruschel

> Proxy Pattern ? :)

You are right, I probably should use proxies. However I don't want to 
have a single proxy with several methods, but several classes with a 
single method, so I think I should combine it with the command pattern 
somehow. Maybe a proxy which can be fed with command objects (since no 
execution is done by the sender maybe it's not real command objects).

But I'm still not sure about the receiver side. Ideally I want a 
separate receiver class for each sender class, which is capable of 
reading the serialized data and handling it as intended. Maybe a 
TRemoteCommandFactory creating TRemoteCommands.

Alternatively maybe I should separate reading the data from executing my 
commands. I could introduce parameter classes used by sender and 
receiver holding the command parameters only (and maybe use RTTI to 
serialize them, or define a synchronization method for reading and 
writing using either a reader or a writer object). Another class would 
then execute the command using such a parameter object. On the other 
hand this would require two different classes for each command which 
have to by kept compatible, probably not the best solution. Well, but 
it'd save me from keeping sender and receiver compatible, and pure data 
objects passed to a proxy seem to have some advantages...

I'm still not 100% sure, but I more and more get an idea, thank you for 
your input, Lee!

-- 
Jens Gruschel

I have built something like this already.  The server contained different 
classes which could be created by a remote call.  Each server object had 
different methods but the signature took only 1 parameter which was a 
variant. (If you need more parameters then simply pass a variant array).

You also may want to look into this.
http://www.realthinclient.com/




"Jens Gruschel" <nospam@thisurldoesnotexist.com> wrote in
message 
news:47fa5ca6@newsgroups.borland.com...
> I'd like to implement some kind of RPC mechanism, executing some commands 
> on another machine. Now I don't like to use CORBA or another standard RPC 
> mechanism, but code this fairly simple thing by myself. Technically it's 
> no problem at all, but I'm a bit unsure what's the best design and how I 
> should name my classes.
>
> For the sender my first thought was to base it on a modified command 
> design pattern (some serialization method instead of an execute method) 
> like this:
>
> TRemoteCommand = class
> public
>   procedure Serialize(const OutStream: TStream); virtual; abstract;
> end;
>
> A sender object would call the Serialize method and send the stream over a

> socket connection or whatever. Alternatively I could do it like this:
>
> TRemoteCommand = class
> protected
>   procedure Serialize(const OutStream: TStream); virtual; abstract;
> public
>   procedure Execute(const Sender: TRemoteCommandSender);
> end;
>
> The Execute method would call Serialize passing a stream created by the 
> sender.
>
> Of course I'd have to register the concrete command classes somehow, 
> giving them a unique id (sent over the network together with the parameter

> data).
>
> But what would I have on the receiver side? Some kind of observer objects 
> registered with the same id? My first thoughts were something like this:
>
> TRemoteCommandObserver = class
> public
>   procedure Serialize(const InStream: TStream); virtual; abstract;
>   procedure Update/Execute/Handle/Process(?); virtual; abstract;
> end;
>
> But I think that's not a real observer, except that some other class (the 
> one receiving the streams) has a subscribe and an unsubscribe method for 
> it. So how could I name it and where should I change my design? Would it 
> make any sense to create command objects on the receiver side? It's really

> very simple and I think I could do it with a few if/then/else statements 
> within one simple class receiving the data, however I'd like to have a 
> more beautiful design. Any thoughts?
>
> P.S. And are there any network design patterns? I'm only aware of the 
> "normal" ones suitable for a single process on a single machine.
>
> -- 
> Jens Gruschel
> http://www.pegtop.net 

> Each server object had 
> different methods but the signature took only 1 parameter which was a 
> variant. (If you need more parameters then simply pass a variant array).

Finding the method address by RTTI? Yes, that's a pretty simple solution 
to add "commands" dynamically. However some other registration
mechanism 
might be better for my problem. The parameters can be pretty complex 
data structures, so I think it's better to use serialization instead (in 
fact I already have this, at least partially). Of course I could still 
use the approach you suggested, replacing variants with streams.

> You also may want to look into this.
> http://www.realthinclient.com/

Thanks. I already knew this product, but I just took a closer look at 
it, especially the tutorials, quite impressive. But using it I still 
have to find a good design for my application, right? I mean I don't 
want an event handler with "if request = a then / else if request = b 
then". That's what I have right now, but since I have to do some 
modifications anyway I thought some refactoring is a good idea, too. 
What I'm really after is a clean design and proper names for my 
identifiers - I know, that's my job, but some hints like "use this 
design pattern" or "oh my God, don't do it that way" are very
welcome.

-- 
Jens Gruschel