[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: OT: Remote objects WAS: Re: [pygame] InteractiveConsole
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