Re: OT: Remote objects WAS: Re: [pygame] InteractiveConsole

[Robert Mark Waugh <robert@waugh.com>]

> How would such a system differ from, say, Samba (which lets clients
> talk to each other from different machines)? I still don't see why I
> would ever want to run a function on another box, except maybe in a
> render farm for a raytracer.
>  
First, to address you last comment.  Most computing applications aren't 
graphical in nature.  Computers are primarily used in information 
systems of one sort or another.  Web browsers and email clients fall 
into these categories.  Companies build giant systems across many 
departments and organizations.  Companies talk to other companies.  
Companies talk to central trade organizations.  Trade organizations talk 
amongst each other.  By being able to publish an object interface and 
methods that can be invoked by these different layers it becomes a 
trivial task to integrate one system to another.  For instance, let's 
say I'm in the accounting department and I want to credit vacation time 
to the HR department's employee roster.  They are running PeopleSoft and 
I'm running SAP.  Instead of having to write some sort of translation 
layer or staging tables on an intermediate database I can just through 
together a remote object on the HR systems that defines a method 
"creditVacationHour(String employeeID, int numberOfHours)".  Then my 
accounting folk can through into their code a line that calls this 
remote method.  Tadah!  Problem solved.  Now anyone in the company (with 
proper security and access control authorization) can integrate to the 
HR department's vacation hour interface without a lot of upfront work.  
In your example, obviously such functionality is trivial.  But you could 
even see a use there.  If you wrote an up front interface that could 
communicate to all your nodes in the render farm and get detailed 
information regarding their progress and system state, it would be 
relatively trivial to do it with SOAP/WSDL.  You could concentrate on 
building the front end and back end functionality and not worry so much 
about the communication protocol.  I could also then write my own front 
end that talks to your backend interfaces without needing to coordinate 
with you.

In the end, a serializing object protocol can be implemented much like 
SMB or NFS.  In fact, NFS uses RPC/XDR which is a older version of these 
remote method / object serialization protocols.  The server defines 
procedures that can be invoked by a remote client, and they pass 
information through a platform independent encoding layer.  Some people 
(myself included) think that the difference between RPC and SOAP are not 
great, except that SOAP is a lot fatter a protocol and requires a lot 
more processing to serialize the messages.

The big difference is that the systems provide a robust mechanism for 
remotely calling and passing objects between dispariate systems.  This 
means that my cell phone, which may not even natively support floating 
point values and runs on some cheap motorola processor, can seemlessly 
invoke methods on a server running Solaris as if they were local.  (this 
is the ideal, but of course you need to go through some serialization 
and request steps which makes it less seemless)  The fact that they are 
on another system or on a vastly different archtecture is meaningless.   
Byte boundaries may not be the same, word orientation may even be 
different, and supported variable types may be different.  The 
intermediate serialization layer converts the system specific 
information into a platform neutral representation and transmits it.

Now, you say, why couldn't I just write my own protocol that 
encapsulates my requests and save a lot of overhead?  You absolutely 
can.  Indeed, I was working at a company that switched from XML/RPC 
(predecessor to SOAP) for it's inter-component communication.  They 
wrote their very concise serialization/translation layer that consumed 
considerably less bandwidth and processing time to deal with.  We saw a 
significant (30%+) performance improvement because these components were 
chatting quite a bit.  However what we gave up was the ability to send 
any arbitrary information to any client/server.  Not a huge loss in this 
situation because there was a clear line of communication that would 
never vary so long as this system exists.  But it required a significant 
amount of time to redevelop a new protocol and implement the code on the 
different architectures that it communicated with (C, Java, and perl).  
If your performance penalty is near zero, then you're going to gain a 
lot of time and flexibility.

When you're looking at CORBA it provides a lot more than just this.  
Indeed, CORBA is more like the kitchen sink.  It provides security, 
access control, interfaces, etc etc etc.  So it's a lot more than just a 
serialization/translation layer.  SOAP is becoming more.  But it's still 
largely just an RPC encoding format.  I'm guessing the reason we need a 
new one is a) Microsoft needs more money, b) it's much more trivial to 
write a SOAP implementation than a full RPC stack.

robert