| Content of these pages are owned and copyrighted by the poster. | |
| Hosted by: |
|
Article contributed by GilbertHerschberger.
A discussion about distributed computing couldn't go on for too long without mentioning the proxy. In the real world, a proxy is a substitute or stand-in for something else. It is something akin to a government sending their ambassador to another country as a representative.
An emulator is a concept closely related to a proxy. A terminal emulator, like telnet, makes it look as if you have a real terminal. Terminal emulator software is a popular substitute for VT100, 3270, or 5250 hardware.
Is it necessary to have a proxy? No. It is beneficial sometimes to work with a remote program through an abstraction. FTP and HTTP are good examples of remote programs that hide the implementation details of the server side from the user.
On the other hand, the perspective is much diffent from a programmer's point of view. In an OS, device drivers are substitutes for hardware devices. In distributed computing, a local proxy is a substitute for a component in another process. In network computing, a local proxy is a substitute for a remote program (or component). ODBC and db-lib are proxies for an SQL server. So many API's are substitutes for the program, library or device that does all of the grunt work.
Java is unique on the landscape of distributed computing. Java already uses a novel approach to substitution, called an interface. In the same way that an interface has a relationship with a class that implements the interface, a proxy has a relationship with the real program on another machine.
Java doesn't need a separate interface definition language,or IDL. Java is an interface definition language.
When writing for distributed programming in Java, you can use the built-in strengths of type checking and all that when using an interface to a remote object, too.
When finished, a custom proxy is both a real object on its own and an interface to a remote object. In Java, it could be expressed like this:
public class ClockProxy
implements Clock, Proxy {
:
}
Java is strong on distributed computing. Some would say that it isn't because of the recommendations from Sun Microsystems don't work. Sun's implementation of three versions of Java, RMI and JINI are not up to the task. Who thinks Sun has to know everything about everything?
Ideally, a program shouldn't be able to tell the difference between the proxy and the real object. Sure, there is going to be a delay because all proxies are inherently slower than the real object. Sure, there is going to be more delay across an Internet than a network.
When a method is called, a proxy should perform the expected function perfectly, even if it means throwing an exception. A proxy is a relay; (although tempting) it doesn't do any thing on its own. It is completely dependent on a real object somewhere else.
Working with proxies in Java reveals a glaring error in the design of Java exceptions. None of the built-in exceptions have a default constructor and no property modifiers. In short, this means that you can't create a proxy that throws exceptions perfectly without a complex exception factory. It might be hard but not impossible to match exception for exception.
| Content of these pages are owned and copyrighted by the poster. | |
| Hosted by: |
|