Question about 'remote objects'

[Frank Millman]

Hi all

I am writing a multi-user business/accounting application. It is getting 
rather complex and I am looking at how to, not exactly simplify it, but find 
a way to manage the complexity.

I have realised that it is logically made up of a number of services -
    database service with connection to database
    workflow engine for business processes
    services manager to handle automated services, such as web services
    client manager to service logins from client workstations
    possibly others

I have made a start by splitting some of these off into separate modules and 
running them in their own threads.

I am concerned about scalability if they are all running on the same 
machine, so I am looking into how to enable these services to run on 
separate servers if required.

My first thought was to look into Pyro. It seems quite nice. One concern I 
had was that it creates a separate thread for each object made available by 
the server. My database server creates separate objects for each instance of 
a row read in from the database, and with multiple users running multiple 
applications, with each one opening multiple tables, this could run into 
hundreds, so I was not sure if that would work.

Then I read that the multiprocessing module allows processes to be spread 
across multiple servers. The documentation is not as clear as Pyro's, but it 
looks as if it could do what I want. I assume it would use processes rather 
than threads to make multiple objects available, but I don't know if there 
is a practical limit.

Then I thought that, instead of the database server exposing each object 
remotely, I could create one 'proxy' object on the server through which all 
clients would communicate, and it in turn would communicate with each 
instance locally.

That felt more managable, but then I thought - why bother with remote 
objects at all? Why not just run a SocketServer on the database server, and 
design a mini-protocol to allow clients to make requests and receive 
results. This is a technology I am already comfortable with, as this is how 
I handle client workstation logins. If I did go this route, I could apply 
the same principle to all the services.

I don't have the experience to make an informed decision at this point, so I 
thought I would see if there is any consensus on the best way to go from 
here.

Is there any particular benefit in using remote objects as opposed to 
writing a SocketServer?

Any advice will be much appreciated.

Thanks

Frank Millman