The Net Worth of an
Object-Oriented Pattern
Practical Implications of the Java RMI
Adrian German
Lecturer, Computer Science Department
Indiana University Bloomington
There will be a server, implemented as follows:
class ServerImplementation {
}
There will be many clients, implemented as follows:
class ClientImplementation {
}
The server has a business card:
public interface Server {
}
And it implements it:
class ServerImplementation implements Server {
}
The client also has a business card:
public interface Client {
}
And, like the server, it makes a promise to fulfill it:
class ClientImplementation implements Client {
}
The server keeps track of clients:
class ServerImplementation implements Server {
Client[] clients = new Client[100];
int index = -1;
}
The server keeps track of clients:
class ServerImplementation implements Server {
Client[] clients = new Client[100];
int index = -1;
}
The index of the most recently allocated cell is -1 if the array is empty.
The server keeps track of clients:
class ServerImplementation implements Server {
Client[] clients = new Client[100];
int index = -1;
}
The index of the most recently allocated cell is -1 if the array is empty.
Note that:
• the server calls the clients by using the title (type) printed on their business cards
The server keeps track of clients:
class ServerImplementation implements Server {
Client[] clients = new Client[100];
int index = -1;
}
The index of the most recently allocated cell is -1 if the array is empty.
Note that:
• the server calls the clients by using the title (type) printed on their business cards
• plain arrays are used as instance variables to just make the type(s) more explicit
What else does the server do?
What else does the server do?
public interface Server {
public void register(Client client);
}
What else does the server do?
public interface Server {
public void register(Client client);
}
It allows clients to register with it, whatever that means.
Although that, in this case, amounts to:
synchronized public void register(Client client) {
clients[++this.index] = client;
client.setID(new Integer(this.index));
for (int i = 0; i < this.index; i++) {
clients[i].register(new Integer(this.index), client);
client.register(new Integer(i), clients[i]);
}
}
Although that, in this case, amounts to:
synchronized public void register(Client client) {
clients[++this.index] = client;
client.setID(new Integer(this.index));
for (int i = 0; i < this.index; i++) {
clients[i].register(new Integer(this.index), client);
client.register(new Integer(i), clients[i]);
}
}
So we see that, apparently, a client:
• can set its ID (through/during registration with the server,)
Although that, in this case, amounts to:
synchronized public void register(Client client) {
clients[++this.index] = client;
client.setID(new Integer(this.index));
for (int i = 0; i < this.index; i++) {
clients[i].register(new Integer(this.index), client);
client.register(new Integer(i), clients[i]);
}
}
So we see that, apparently, a client:
• can set its ID (through/during registration with the server,) and
• allows any other client to register with it (also through/by the server)
This changes the client business card a little:
(that the server knows)
public interface Client {
public void setID(Integer index);
public void register(Integer index, Client client);
}
This changes the client business card a little:
(that the server knows)
public interface Client {
public void setID(Integer index);
public void register(Integer index, Client client);
}
Let’s see how these promises can be fulfiled.
First off, every client will have an own numeric id:
class ClientImplementation implements Client {
int id;
synchronized public void setID (Integer index) {
this.id = index.intValue();
}
}
Secondly, the world (collection) of peers initially
registered with the server is replicated in each client:
class ClientImplementation implements Client {
int id;
synchronized public void setID (Integer index) {
this.id = index.intValue();
}
Client[] peer = new Client[100];
int index = -1;
synchronized public void register(Integer index, Client client) {
this.index = index.intValue();
this.peer[this.index] = client;
}
}
Secondly, the world (collection) of peers initially
registered with the server is replicated in each client:
class ClientImplementation implements Client {
int id;
synchronized public void setID (Integer index) {
this.id = index.intValue();
}
Client[] peer = new Client[100];
int index = -1;
synchronized public void register(Integer index, Client client) {
this.index = index.intValue();
this.peer[this.index] = client;
}
}
Let’s go back to the server.
Let’s go back to the server.
How does it get started and what does it do?
Let’s go back to the server.
How does it get started and what does it do?
The server has no constructor.
Let’s go back to the server.
How does it get started and what does it do?
The server has no constructor.
The server is implemented as a thread.
In its run() method the server
constantly broadcasts to clients:
class ServerImplementation implements Server, Runnable {
...
public void run() {
while (true) {
try {
Thread.sleep((int)(Math.random() * 5000 + 5000));
this.broadcast();
} catch (Exception e) { }
}
}
}
Broadcasting amounts to the following:
synchronized public void broadcast() {
for (int i = 0; i <= this.index; i++)
clients[i].setAvailable(new Boolean(false));
for (int i = 0, check = 0; i <= this.index; i++)
check += clients[i].getBalance();
for (int i = 0; i <= this.index; i++)
clients[i].setAvailable(new Boolean(true));
}
Broadcasting amounts to the following:
synchronized public void broadcast() {
for (int i = 0; i <= this.index; i++)
clients[i].setAvailable(new Boolean(false));
for (int i = 0, check = 0; i <= this.index; i++)
check += clients[i].getBalance();
for (int i = 0; i <= this.index; i++)
clients[i].setAvailable(new Boolean(true));
}
Broadcasting amounts to the following:
synchronized public void broadcast() {
for (int i = 0; i <= this.index; i++)
clients[i].setAvailable(new Boolean(false));
for (int i = 0, check = 0; i <= this.index; i++)
check += clients[i].getBalance();
for (int i = 0; i <= this.index; i++)
clients[i].setAvailable(new Boolean(true));
}
During broadcasting:
During broadcasting:
• clients are first shut down
(by setting their availability to false)
During broadcasting:
• clients are first shut down
(by setting their availability to false)
• the sum of points for the entire
collection of clients is calculated
During broadcasting:
• clients are first shut down
(by setting their availability to false)
• the sum of points for the entire
collection of clients is calculated
• and clients are then turned back on, one by one
During broadcasting:
• clients are first shut down
(by setting their availability to false)
• the sum of points for the entire
collection of clients is calculated
• and clients are then turned back on, one by one
Here’s how we accomplish these steps.
Setting the availability and returning the current
balance are advertised by the clients.
public interface Client {
public void register(Client client);
public void setID(Integer index);
public void setAvailable(Boolean availability);
public int getBalance();
}
Setting the availability and returning the current
balance are advertised by the clients.
public interface Client {
public void register(Client client);
public void setID(Integer index);
public void setAvailable(Boolean availability);
public int getBalance();
}
The implementation of these two functions is immediate.
Boolean available = new Boolean(true);
synchronized public void setAvailable(Boolean availability) {
this.available = availability;
}
int balance;
public int getBalance() {
return this.balance;
}
Boolean available = new Boolean(true);
synchronized public void setAvailable(Boolean availability) {
this.available = availability;
}
int balance;
public int getBalance() {
return this.balance;
}
What else does the server do?
Broadcasting is just a little bit more complicated but
other than that, that’s it.
// after turning the clients off
String report = “”, calculation=“”;
int check = 0;
for (int i = 0; i <= this.index; i++) {
report += clients[i].report() + "\n";
calculation += "(" + clients[i].getBalance() + ")..";
check += clients[i].getBalance();
}
System.out.println("Server sees: " + report);
System.out.println(calculation + " ---> " + check);
// now turn the clients back on
Clients need to provide the added level of functionality:
public interface Client {
public void setID(Integer index);
public void register(Integer index, Client client);
public void setAvailable(Boolean availability);
public int getBalance();
public String report();
}
Implementation for this extra feature is immediate, as well:
class ClientImplementation implements Client {
...
String name;
public String report() {
return this.name + ": " + this.balance;
}
}
Implementation for this extra feature is immediate, as well:
class ClientImplementation implements Client {
...
String name;
public String report() {
return this.name + ": " + this.balance;
}
}
How does one start the server?
The server provides a method for that:
class ServerImplementation implements Server, Runnable {
...
public void startAsLocalServer() {
new Thread(this).start();
}
}
If we were to try this program out we'd do something like this:
class LocalSetup {
public static void main(String[] args) {
}
}
A server needs to be created, then started:
class LocalSetup {
public static void main(String[] args) {
ServerImplementation server = new ServerImplementation();
server.startAsLocalServer();
}
}
A server needs to be created, then started:
class LocalSetup {
public static void main(String[] args) {
ServerImplementation server = new ServerImplementation();
server.startAsLocalServer();
}
}
We need some clients, too.
A server needs to be created, then started:
class LocalSetup {
public static void main(String[] args) {
ServerImplementation server = new ServerImplementation();
server.startAsLocalServer();
}
}
We need some clients, too. But how does one create a client?
class ClientImplementation implements Client {
...
public ClientImplementation(String name) {
this.name = name;
}
}
We need some clients, too. But how does one create a client?
So we can create a few clients now:
class LocalSetup {
public static void main(String[] args) {
ServerImplementation server =
new ServerImplementation();
server.startAsLocalServer();
for (int i = 0; i < 6; i++) {
ClientImplementation dealer =
new ClientImplementation("Dealer_" + i);
dealer.startAsClientOf(server);
}
}
}
And, if started, what do clients do?
class ClientImplementation implements Client {
...
public void startAsClientOf(java.rmi.Remote peer) {
Server server = (Server) peer;
server.register(this);
this.server = server;
new Thread(this).start();
}
Server server;
}
class ClientImplementation implements Client {
...
public void startAsClientOf(java.rmi.Remote peer) {
Server server = (Server) peer;
server.register(this);
this.server = server;
new Thread(this).start();
}
Server server;
}
class ClientImplementation implements Client {
...
public void startAsClientOf(java.rmi.Remote peer) {
Server server = (Server) peer;
server.register(this);
this.server = server;
new Thread(this).start();
}
Server server;
}
In describing how we start the clients we acknowledge for the
first time the distributed nature of our goal.
And,
if
started,
what
do
This addition however has significant ramifications.
clients do?
And,
if
started,
what
do
This addition however has significant ramifications.
clients
do?
public interface Server extends java.rmi.Remote {
public void register(Client client);
}
First, the server needs to match the type.
In addition to that clients need to be described in their active
behaviour.
class ClientImplementation implements Client, Runnable {
...
public void run() {
while (true) {
try {
Thread.sleep((int)(Math.random() * 1000 + 1000));
if (this.available.booleanValue())
this.initiateTransfer();
} catch (Exception e) { }
}
}
}
In addition to that clients need to be described in their active
behaviour.
class ClientImplementation implements Client, Runnable {
...
public void run() {
while (true) {
try {
Thread.sleep((int)(Math.random() * 1000 + 1000));
if (this.available.booleanValue())
this.initiateTransfer();
} catch (Exception e) { }
}
}
}
So that's what clients typically do: wait, then initiate a transfer.
Initiating a transfer has the following description:
class ClientImplementation implements Client, Runnable {
...
synchronized private void initiateTransfer() {
if (this.index > 0) {
int chosen = (int) (Math.random() * (this.index + 1));
if (chosen == this.id // always deal with someone else
|| peer[chosen] == null) return;
this.balance += peer[chosen].process(
new Transaction(this.name, this.id,
(int) (Math.random() * 10 + 1),
Math.random() > 0.5 ? "sent" : "requested"));
}
}
}
Initiating a transfer has the following description:
class ClientImplementation implements Client, Runnable {
...
synchronized private void initiateTransfer() {
if (this.index > 0) {
int chosen = (int) (Math.random() * (this.index + 1));
if (chosen == this.id // always deal with someone else
|| peer[chosen] == null) return;
this.balance += peer[chosen].process(
new Transaction(this.name, this.id,
(int) (Math.random() * 10 + 1),
Math.random() > 0.5 ? "sent" : "requested"));
}
}
}
A description of process() and Transaction follows:
public class Transaction {
String initiatorName;
int initiatorID;
int amount;
String direction;
public Transaction(String name, int id, int amount,
String direction) {
this.initiatorName = name;
this.id = id; this.amount = amount;
this.direction = direction;
}
}
A description of process() and Transaction follows:
public class Transaction {
String initiatorName;
int initiatorID;
int amount;
String direction;
public Transaction(String name, int id, int amount,
String direction) {
this.initiatorName = name;
this.id = id; this.amount = amount;
this.direction = direction;
}
}
Transactions are passive, but they could easily be turned into visitors.
Processing is not very complicated:
class ClientImplementation implements ... {
...
synchronized public int process(Transaction trans) {
if (this.available.booleanValue())
if (trans.direction.equals("sent")) {
this.balance += trans.amount;
return - (trans.amount);
} else {
this.balance -= trans.amount;
return (trans.amount);
}
else return 0; // object unavailable: method idempotent
}
}
And process() must be added to a Client's business card:
public interface Client {
...
public int process(Transaction transaction);
}
So our application has been developed now.
And process() must be added to a Client's business card:
public interface Client {
...
public int process(Transaction transaction);
}
So our application has been developed now.
One can run LocalSetup to test it.
Is it possible to have avoided using java.rmi.Remote at all?
Is it possible to have avoided using java.rmi.Remote at all?
Perhaps so, but this approach is a bit more general, since we
could have more than one kind of server.
Is it possible to have avoided using java.rmi.Remote at all?
Perhaps so, but this approach is a bit more general, since we
could have more than one kind of server.
That is, we could easily rewrite startAsClientOf as follows:
public void startAsClientOf(java.rmi.Remote peer) {
if (peer instanceof Server) {
// the code we have thus far
} else {
// throw an exception or do something else
}
}
Is it possible to have avoided using java.rmi.Remote at all?
Perhaps so, but this approach is a bit more general, since we
could have more than one kind of server.
That is, we could easily rewrite startAsClientOf as follows:
public void startAsClientOf(java.rmi.Remote peer) {
if (peer instanceof Server) {
// the code we have thus far
} else {
// throw an exception or something
}
}
Now we will show how we distribute the program without
touching the application logic developed thus far.
Let's introduce this abstraction:
public abstract class NetworkPeer implements java.rmi.Remote {
}
It provides tools for creating proxies used for remote access:
public abstract class NetworkPeer implements java.rmi.Remote {
public void exportMethods() throws java.rmi.RemoteException {
java.rmi.server.UnicastRemoteObject.exportObject(this);
}
}
It provides the ability to locate a peer server (by its external address):
public abstract class NetworkPeer implements java.rmi.Remote {
...
public java.rmi.Remote locatePeer(String peerHost,
int peerPort,
String peerName)
throws Exception {
return java.rmi.Naming.lookup(
"rmi://" + peerHost + ":" + peerPort + "/" + peerName
);
}
}
It provides a standard/default definition of startAsNetworkClient()
public abstract class NetworkPeer implements java.rmi.Remote {
...
public void startAsNetworkClient(String peerHost,
int peerPort,
String peerName)
throws Exception {
this.exportMethods();
java.rmi.Remote peer = this.locatePeer(peerHost, peerPort,
peerName);
this.startAsClientOf(peer); // see below ...
}
}
It provides a standard/default definition of startAsNetworkClient()
public abstract class NetworkPeer implements java.rmi.Remote {
...
public void startAsNetworkClient(...) throws Exception {
...
this.startAsClientOf(peer); // see below ...
}
public abstract void startAsClientOf(java.rmi.Remote peer)
throws java.rmi.RemoteException;
}
It provides a standard/default definition of startAsNetworkServer()
public abstract class NetworkPeer implements java.rmi.Remote {
...
public void startAsNetworkServer(String name, int port) {
System.setSecurityManager(new java.rmi.RMISecurityManager());
try {
this.exportMethods();
java.rmi.registry.Registry registry =
java.rmi.registry.LocateRegistry.createRegistry(port);
registry.bind(name, this);
this.startAsLocalServer(); // see below ...
System.out.println("Server is ready ... ");
} catch (Exception e) {
System.out.println("Server error: " + e + " ... ");
}
}
public abstract void startAsLocalServer(); // startAsServer?
}
This abstraction encapsulates and provides everything needed.
public abstract class NetworkPeer implements java.rmi.Remote {
...
public void startAsNetworkServer(String name, int port) {
System.setSecurityManager(new java.rmi.RMISecurityManager());
try {
this.exportMethods();
java.rmi.registry.Registry registry =
java.rmi.registry.LocateRegistry.createRegistry(port);
registry.bind(name, this);
this.startAsLocalServer(); // see below ...
System.out.println("Server is ready ... ");
} catch (Exception e) {
System.out.println("Server error: " + e + " ... ");
}
}
public abstract void startAsLocalServer(); // startAsServer?
}
First for the server:
class ServerImplementation extends NetworkPeer
implements Server, Runnable {
...
public static void main(String[] args) {
String portNumber = args[0], ownName = args[1];
ServerImplementation here = new ServerImplementation();
here.startAsNetworkServer(ownName,
Integer.parseInt(portNumber));
// startAsLocalServer called in the process ...
}
public void startAsClientOf(java.rmi.Remote peer) {
// empty, server is a peer with a public address
}
}
And then for the client:
class ClientImplementation extends NetworkPeer
implements Client, Runnable {
...
public static void main(String[] args) throws Exception {
String ownName = args[0], serverHostName = args[1],
serverPortNumber = args[2], serverName = args[3];
ClientImplementation client = new ClientImplementation(name);
client.startAsNetworkClientOf(serverHostName,
Integer.parseInt(serverPortNumber), serverName);
// startAsClientOf will be called in the process ...
}
public void startAsLocalServer() {
// a client is a peer/guest without a permanent address ...
}
}
And there's one last change we need to make:
public class Transaction implements java.io.Serializable {
// everything else exactly the same
}
However, additional decoration will be required for networking:
class ServerImplementation extends ... implements ..., java.rmi.Remote {
...
... void register(...) throws java.rmi.RemoteException { ... }
...
}
public interface Server extends java.rmi.Remote {
public void register(...) throws java.rmi.RemoteException;
}
class ClientImplementation extends ... implements ... {
...
... void startAsClientOf(...) throws java.rmi.RemoteException { ... }
}
class LocalSetup {
public static void main(String[] args) throws /*java.rmi.Remote*/Exception { ... }
}
And we need to take care of the ClientImplementation as well:
public interface Client extends java.rmi.Remote {
public void setID(...) throws java.rmi.RemoteException;
public void register(...) throws java.rmi.RemoteException;
public void setAvailable(...) throws java.rmi.RemoteException;
public int getBalance() throws java.rmi.RemoteException;
public String report() throws java.rmi.RemoteException;
public int process(...) throws java.rmi.RemoteException;
}
class ClientImplementation extends ... implements ... {
...
public void setID(...) throws java.rmi.RemoteException { ... };
public void register(...) throws java.rmi.RemoteException { ... };
public void setAvailable(...) throws java.rmi.RemoteException { ... };
public int getBalance() throws java.rmi.RemoteException { ... };
public String report() throws java.rmi.RemoteException { ... };
public int process(...) throws java.rmi.RemoteException { ... };
}
And the decorations propagate one last step:
class ServerImplementation extends ... implements ... {
...
synchronized public void broadcast() throws java.rmi.RemoteException { ... }
...
}
And the decorations propagate one last step:
class ServerImplementation extends ... implements ... {
...
synchronized public void broadcast() throws java.rmi.RemoteException { ... }
...
}
So, as we can see, the code we developed originally has not been
touched, and is being used unchanged.
Now we can start the programs in distributed fashion:
tucotuco% javac *.java
tucotuco% rmic ServerImplementation
tucotuco% rmic ClientIimplementation
tucotuco% java ServerImplementation 36091 theServer
Server is ready...
In this example the server is started on tucotuco.cs.indiana.edu
as theServer on port 36091. The clients will be started on molerat,
burrowww, blesmol, and bobac, when they are ready to join. These
are different machines that share the filespace through NFS so one
doesn't need to worry about distributing (deploying) the code around.
But the machines have distinct network identity so when we start the
programs they are loaded in distinct locations of the network as well.
Now we can start the programs in distributed fashion:
tucotuco% javac *.java
tucotuco% rmic ServerImplementation
tucotuco% rmic ClientIimplementation
tucotuco% java ServerImplementation 36091 theServer
Server is ready...
In this example the server is started on tucotuco.cs.indiana.edu
as theServer on port 36091. The clients will be started on molerat,
burrowww, blesmol, and bobac, when they are ready to join. These
are different machines that share the filespace through NFS so one
doesn't need to worry about distributing (deploying) the code around.
But the machines have distinct network identity so when we start the
programs they are loaded in distinct locations of the network as well.
Now we can start the programs in distributed fashion:
tucotuco% javac *.java
tucotuco% rmic ServerImplementation
tucotuco% rmic ClientIimplementation
tucotuco% java ServerImplementation 36091 theServer
Server is ready...
In this example the server is started on tucotuco.cs.indiana.edu
as theServer on port 36091. The clients will be started on molerat,
burrowww, blesmol, and bobac, when they are ready to join. These
are different machines that share the filespace through NFS so one
doesn't need to worry about distributing (deploying) the code around.
But the machines have distinct network identity so when we start the
programs they are loaded in distinct locations of the network as well.
Now we can start the programs in distributed fashion:
tucotuco% javac *.java
tucotuco% rmic ServerImplementation
tucotuco% rmic ClientIimplementation
tucotuco% java ServerImplementation 36091 theServer
Server is ready...
In this example the server is started on tucotuco.cs.indiana.edu
as theServer on port 36091. The clients will be started on molerat,
burrowww, blesmol, and bobac, when they are ready to join. These
are different machines that share the filespace through NFS so one
doesn't need to worry about distributing (deploying) the code around.
But the machines have distinct network identity so when we start the
programs they are loaded in distinct locations of the network as well.
So here's how we start the clients:
burrowww% java ClientImplementation larry tucotuco.cs.indiana.edu 36091 theServer
So here's how we start the clients:
burrowww% java ClientImplementation larry tucotuco.cs.indiana.edu 36091 theServer
blesmol% java ClientImplementation michael tucotuco.cs.indiana.edu 36091 theServer
So here's how we start the clients:
burrowww% java ClientImplementation larry tucotuco.cs.indiana.edu 36091 theServer
blesmol% java ClientImplementation michael tucotuco.cs.indiana.edu 36091 theServer
bobac% java ClientImplementation toni tucotuco.cs.indiana.edu 36091 theServer
So here's how we start the clients:
burrowww% java ClientImplementation larry tucotuco.cs.indiana.edu 36091 theServer
blesmol% java ClientImplementation michael tucotuco.cs.indiana.edu 36091 theServer
bobac% java ClientImplementation toni tucotuco.cs.indiana.edu 36091 theServer
molerat% java ClientImplementation richard tucotuco.cs.indiana.edu 36091 theServer
And the LocalSetup still works as before.
And the LocalSetup still works as before.
So one can (and should) use this pattern from the outset.
Object-oriented programming is really about distributed programming.
Object-oriented programming is really about distributed programming.
And it appears to have been like this from the beginning: "In 1961
[Alan] Kay worked on the problem of transporting data files and
procedures from one Air Force air training installation to another and
discovered that some unknown programmer had figured out a clever
method of doing the job. The idea was to send the data bundled
along with its procedures, so that the program at the new installation
could use the procedures directly, even without knowing the format of
the data files. The procedures themselves could find the information
they needed from the data files. The idea that a program could use
procedures without knowing how the data was represented struck
Kay as a good one. It formed the basis for his later ideas about
objects." (Dennis Shasha, Cathy Lazere, Out of Their Minds [...],
Copernicus, Springer Verlag 1995)
Object-oriented programming is really about distributed programming.
And it appears to have been like this from the beginning: "In 1961
[Alan] Kay worked on the problem of transporting data files and
procedures from one Air Force air training installation to another and
discovered that some unknown programmer had figured out a clever
method of doing the job. The idea was to send the data bundled
along with its procedures, so that the program at the new installation
could use the procedures directly, even without knowing the format of
the data files. The procedures themselves could find the information
they needed from the data files. The idea that a program could use
procedures without knowing how the data was represented struck
Kay as a good one. It formed the basis for his later ideas about
objects." (Dennis Shasha, Cathy Lazere, Out of Their Minds [...],
Copernicus, Springer Verlag 1995)
Object-oriented programming is really about distributed programming.
And it appears to have been like this from the beginning: "In 1961
[Alan] Kay worked on the problem of transporting data files and
procedures from one Air Force air training installation to another and
discovered that some unknown programmer had figured out a clever
method of doing the job. The idea was to send the data bundled
along with its procedures, so that the program at the new installation
could use the procedures directly, even without knowing the format of
the data files. The procedures themselves could find the information
they needed from the data files. The idea that a program could use
procedures without knowing how the data was represented struck
Kay as a good one. It formed the basis for his later ideas about
objects." (Dennis Shasha, Cathy Lazere, Out of Their Minds [...],
Copernicus, Springer Verlag 1995)
Object-oriented programming is really about distributed programming.
And it appears to have been like this from the beginning: "In 1961
[Alan] Kay worked on the problem of transporting data files and
procedures from one Air Force air training installation to another and
discovered that some unknown programmer had figured out a clever
method of doing the job. The idea was to send the data bundled
along with its procedures, so that the program at the new installation
could use the procedures directly, even without knowing the format of
the data files. The procedures themselves could find the information
they needed from the data files. The idea that a program could use
procedures without knowing how the data was represented struck
Kay as a good one. It formed the basis for his later ideas about
objects." (Dennis Shasha, Cathy Lazere, Out of Their Minds [...],
Copernicus, Springer Verlag 1995)
Object-oriented programming is really about distributed programming.
And it appears to have been like this from the beginning: "In 1961
[Alan] Kay worked on the problem of transporting data files and
procedures from one Air Force air training installation to another and
discovered that some unknown programmer had figured out a clever
method of doing the job. The idea was to send the data bundled
along with its procedures, so that the program at the new installation
could use the procedures directly, even without knowing the format of
the data files. The procedures themselves could find the information
they needed from the data files. The idea that a program could use
procedures without knowing how the data was represented struck
Kay as a good one. It formed the basis for his later ideas about
objects." (Dennis Shasha, Cathy Lazere, Out of Their Minds [...],
Copernicus, Springer Verlag 1995)
Object-oriented programming is really about distributed programming.
That's why we didn't say anything about static members.
But local and distributed computing present major differences:
The major differences between the two concern the areas of:
• latency
• memory access
• partial failure, and
• concurrency
One can identify these differences in the pattern presented.
But local and distributed computing present major differences:
The major differences between the two concern the areas of:
• latency
• memory access
• partial failure, and
• concurrency
One can identify these differences in the pattern presented.
But local and distributed computing present major differences:
The major differences between the two concern the areas of:
• latency
• memory access
• partial failure, and
• concurrency
One can identify these differences in the pattern presented.
But local and distributed computing present major differences:
The major differences between the two concern the areas of:
• latency
• memory access
• partial failure, and
• concurrency
One can identify these differences in the pattern presented.
But local and distributed computing present major differences:
The major differences between the two concern the areas of:
• latency
• memory access
• partial failure, and
• concurrency
One can identify these differences in the pattern presented.
But local and distributed computing present major differences:
The major differences between the two concern the areas of:
• latency
• memory access
• partial failure, and
• concurrency
One can identify these differences in the pattern presented.
1. Latency
Objects sent back and forth need to be Serializable.
1. Latency
Objects sent back and forth need to be Serializable.
2. Memory Access
Replace the pointers with object references.
1. Latency
Objects sent back and forth need to be Serializable.
2. Memory Access
Replace the pointers with object references.
3. Partial Failure
Enforce the need to throws java.rmi.RemoteExceptions
1. Latency
Objects sent back and forth need to be Serializable.
2. Memory Access
Replace the pointers with object references.
3. Partial Failure
Enforce the need to throws java.rmi.RemoteExceptions
4. Synchronization
The local model must be realistic. It must reflect the truly
asynchronous operation in a distributed environment. The only
synchronization mechanism we have used is local, at the level of the
object. Objects are the only critical regions.
1. Latency
Objects sent back and forth need to be Serializable.
2. Memory Access
Replace the pointers with object references.
3. Partial Failure
Enforce the need to throws java.rmi.RemoteExceptions
4. Synchronization
The local model must be realistic. It must reflect the truly
asynchronous operation in a distributed environment. The only
synchronization mechanism we have used is local, at the level of the
object. Objects are the only critical regions.
1. Latency
Objects sent back and forth need to be Serializable.
2. Memory Access
Replace the pointers with object references.
3. Partial Failure
Enforce the need to throws java.rmi.RemoteExceptions
4. Synchronization
The local model must be realistic. It must reflect the truly
asynchronous operation in a distributed environment. The only
synchronization mechanism we have used is local, at the level of the
object. Objects are the only critical regions.
1. Latency
Objects sent back and forth need to be Serializable.
2. Memory Access
Replace the pointers with object references.
3. Partial Failure
Enforce the need to throws java.rmi.RemoteExceptions
4. Synchronization
The local model must be realistic. It must reflect the truly
asynchronous operation in a distributed environment. The only
synchronization mechanism we have used is local, at the level of the
object. Objects are the only critical regions.
A non-distributed system (even multi-threaded) is layered on
top of a single operating system which can be used to determine and
aid in synchronization and in the recovery of failure. A distributed
system, on the other hand, has no single point of resource allocation,
or failure recovery, and thus is conceptually very different.
1. Latency
Objects sent back and forth need to be Serializable.
2. Memory Access
Replace the pointers with object references.
3. Partial Failure
Enforce the need to throws java.rmi.RemoteExceptions
4. Synchronization
The local model must be realistic. It must reflect the truly
asynchronous operation in a distributed environment. The only
synchronization mechanism we have used is local, at the level of the
object. Objects are the only critical regions.
A non-distributed system (even multi-threaded) is layered on
top of a single operating system which can be used to determine and
aid in synchronization and in the recovery of failure. A distributed
system, on the other hand, has no single point of resource allocation,
or failure recovery, and thus is conceptually very different.
1. Latency
Objects sent back and forth need to be Serializable.
2. Memory Access
Replace the pointers with object references.
3. Partial Failure
Enforce the need to throws java.rmi.RemoteExceptions
4. Synchronization
The local model must be realistic. It must reflect the truly
asynchronous operation in a distributed environment. The only
synchronization mechanism we have used is local, at the level of the
object. Objects are the only critical regions.
A non-distributed system (even multi-threaded) is layered on
top of a single operating system which can be used to determine and
aid in synchronization and in the recovery of failure. A distributed
system, on the other hand, has no single point of resource allocation,
or failure recovery, and thus is conceptually very different.
(see Waldo et al., A Note on Distributed Computing, SMLI TR-94-29)
1. Latency
Objects sent back and forth need to be Serializable.
2. Memory Access
Replace the pointers with object references.
3. Partial Failure
Enforce the need to throws java.rmi.RemoteExceptions
4. Synchronization
The local model must be realistic. It must reflect the truly
asynchronous operation in a distributed environment. The only
synchronization mechanism we have used is local, at the level of the
object. Objects are the only critical regions.
A non-distributed system (even multi-threaded) is layered on
top of a single operating system which can be used to determine and
aid in synchronization and in the recovery of failure. A distributed
system, on the other hand, has no single point of resource allocation,
or failure recovery, and thus is conceptually very different.
(see Waldo et al., A Note on Distributed Computing, SMLI TR-94-29)
So what we are presenting here is just a discipline of programming.
A style.
A technique.
"The class of locally distributed objects also forms a group that can
lead to significant gains in software modularity. Applications made up
of collections of such objects would have the advantageof forced and
guaranteed separation between the interface to an object and the
implementation of that object, and would allow the replacement of
one implementation with another without affecting other parts of the
system." (Waldo et al., A Note on Distributed Computing).
So cell phones are useful.
Even though when we use them we are inherently dealing with
specific issues of latency, (memory) addressing, partial failure and
concurrency. But for the most part they're by and large transparent.
So what we are presenting here is just a discipline of programming.
A style.
A technique.
"The class of locally distributed objects also forms a group that can
lead to significant gains in software modularity. Applications made up
of collections of such objects would have the advantageof forced and
guaranteed separation between the interface to an object and the
implementation of that object, and would allow the replacement of
one implementation with another without affecting other parts of the
system." (Waldo et al., A Note on Distributed Computing).
So cell phones are useful.
Even though when we use them we are inherently dealing with
specific issues of latency, (memory) addressing, partial failure and
concurrency. But for the most part they're by and large transparent.
So what we are presenting here is just a discipline of programming.
A style.
A technique.
"The class of locally distributed objects also forms a group that can
lead to significant gains in software modularity. Applications made up
of collections of such objects would have the advantageof forced and
guaranteed separation between the interface to an object and the
implementation of that object, and would allow the replacement of
one implementation with another without affecting other parts of the
system." (Waldo et al., A Note on Distributed Computing).
So cell phones are useful.
Even though when we use them we are inherently dealing with
specific issues of latency, (memory) addressing, partial failure and
concurrency. But for the most part they're by and large transparent.
So what we are presenting here is just a discipline of programming.
A style.
A technique.
"The class of locally distributed objects also forms a group that can
lead to significant gains in software modularity. Applications made up
of collections of such objects would have the advantage of forced and
guaranteed separation between the interface to an object and the
implementation of that object, and would allow the replacement of
one implementation with another without affecting other parts of the
system." (Waldo et al., A Note on Distributed Computing).
So cell phones are useful.
Even though when we use them we are inherently dealing with
specific issues of latency, (memory) addressing, partial failure and
concurrency. But for the most part they're by and large transparent.
So what we are presenting here is just a discipline of programming.
A style.
A technique.
"The class of locally distributed objects also forms a group that can
lead to significant gains in software modularity. Applications made up
of collections of such objects would have the advantage of forced and
guaranteed separation between the interface to an object and the
implementation of that object, and would allow the replacement of
one implementation with another without affecting other parts of the
system." (Waldo et al., A Note on Distributed Computing).
So cell phones are useful.
Even though when we use them we are inherently dealing with
specific issues of latency, (memory) addressing, partial failure and
concurrency. But for the most part they're by and large transparent.
So what we are presenting here is just a discipline of programming.
A style.
A technique.
"The class of locally distributed objects also forms a group that can
lead to significant gains in software modularity. Applications made up
of collections of such objects would have the advantage of forced and
guaranteed separation between the interface to an object and the
implementation of that object, and would allow the replacement of
one implementation with another without affecting other parts of the
system." (Waldo et al., A Note on Distributed Computing).
So cell phones are useful.
Even though when we use them we are inherently dealing with
specific issues of latency, (memory) addressing, partial failure and
concurrency. But for the most part they're by and large transparent.
Conclusions
1. One can take advantage of what was presented if one follows the
pattern of development, based on simple object-oriented principles.
2. Once developed the code can be tested locally, in a controlled, and
significantly more predictable environment.
3. Increased separation of roles (if the pattern is followed then
obtaining the distributed version of it amounts only to marking
interfaces as remote and decorating the methods signature with the
remote exceptions that now might be thrown, plus serializability)
4. Because of this using RMI for networking is essentially equivalent
to using try/catch blocks for exception handling: the impact on
productivity should (or could) be significant.
5. The pattern only uses simple inheritance and interfaces.
Conclusions
1. One can take advantage of what was presented if one follows the
pattern of development, based on simple object-oriented principles.
2. Once developed the code can be tested locally, in a controlled, and
significantly more predictable environment.
3. Increased separation of roles (if the pattern is followed then
obtaining the distributed version of it amounts only to marking
interfaces as remote and decorating the methods signature with the
remote exceptions that now might be thrown, plus serializability)
4. Because of this using RMI for networking is essentially equivalent
to using try/catch blocks for exception handling: the impact on
productivity should (or could) be significant.
5. The pattern only uses simple inheritance and interfaces.
Conclusions
1. One can take advantage of what was presented if one follows the
pattern of development, based on simple object-oriented principles.
2. Once developed the code can be tested locally, in a controlled, and
significantly more predictable environment.
3. Increased separation of roles (if the pattern is followed then
obtaining the distributed version of it amounts only to marking
interfaces as remote and decorating the methods signature with the
remote exceptions that now might be thrown, plus serializability)
4. Because of this using RMI for networking is essentially equivalent
to using try/catch blocks for exception handling: the impact on
productivity should (or could) be significant.
5. The pattern only uses simple inheritance and interfaces.
Conclusions
1. One can take advantage of what was presented if one follows the
pattern of development, based on simple object-oriented principles.
2. Once developed the code can be tested locally, in a controlled, and
significantly more predictable environment.
3. Increased separation of roles (if the pattern is followed then
obtaining the distributed version of it amounts only to marking
interfaces as remote and decorating the methods signature with the
remote exceptions that now might be thrown, plus serializability)
4. Because of this using RMI for networking is essentially equivalent
to using try/catch blocks for exception handling: the impact on
productivity should (or could) be significant.
5. The pattern only uses simple inheritance and interfaces.
Conclusions
1. One can take advantage of what was presented if one follows the
pattern of development, based on simple object-oriented principles.
2. Once developed the code can be tested locally, in a controlled, and
significantly more predictable environment.
3. Increased separation of roles (if the pattern is followed then
obtaining the distributed version of it amounts only to marking
interfaces as remote and decorating the methods signature with the
remote exceptions that now might be thrown, plus serializability)
4. Because of this using RMI for networking is essentially equivalent
to using try/catch blocks for exception handling: the impact on
productivity should (or could) be significant.
5. The pattern only uses simple inheritance and interfaces.
Bottom Line
The network is the computer.
Bottom Line
The network is the computer.
Bottom Line
The network is the computer.