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?

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: public interface Client { public void setID(Integer index); public void register(Integer index, Client client); } (that the server knows)

This changes the client business card a little: public interface Client { public void setID(Integer index); public void register(Integer index, Client client); } (that the server knows) 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.

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() * )); 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:

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.

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. Setting the availability and returning the current balance are advertised by the clients.

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?

// 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 Broadcasting is just a little bit more complicated but other than that, that’s it.

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 clients do? This addition however has significant ramifications.

public interface Server extends java.rmi.Remote { public void register(Client client); } First, the server needs to match the type. And, if started, what do clients do? This addition however has significant ramifications.

class ClientImplementation implements Client, Runnable {... public void run() { while (true) { try { Thread.sleep((int)(Math.random() * )); 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() * )); if (this.available.booleanValue()) this.initiateTransfer(); } catch (Exception e) { } } In addition to that clients need to be described in their active behaviour. So that's what clients typically do: wait, then initiate a transfer.

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() * ), 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() * ), Math.random() > 0.5 ? "sent" : "requested")); } Initiating a transfer has the following description:

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; } A description of process() and Transaction follows: Transactions are passive, but they could easily be turned into visitors.

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 } Processing is not very complicated:

public interface Client {... public int process(Transaction transaction); } And process() must be added to a Client 's business card: So our application has been developed now.

public interface Client {... public int process(Transaction transaction); } And process() must be added to a Client 's business card: 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?

Perhaps so, but this approach is a bit more general, since we could have more than one kind of server.

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 } 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. Now we will show how we distribute the program without touching the application logic developed thus far. That is, we could easily rewrite startAsClientOf as follows:

public abstract class NetworkPeer implements java.rmi.Remote { } Let's introduce this abstraction:

public abstract class NetworkPeer implements java.rmi.Remote { public void exportMethods() throws java.rmi.RemoteException { java.rmi.server.UnicastRemoteObject.exportObject(this); } It provides tools for creating proxies used for remote access:

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 the ability to locate a peer server (by its external address):

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 startAsNetworkClient()

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? } 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.

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 } First for the server:

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 then for the client:

public class Transaction implements java.io.Serializable { // everything else exactly the same } And there's one last change we need to make:

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 {... } } However, additional decoration will be required for networking:

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 we need to take care of the ClientImplementation as well:

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 {... }... } And the decorations propagate one last step: So, as we can see, the code we developed originally has not been touched, and is being used unchanged.

tucotuco% javac *.java tucotuco% rmic ServerImplementation tucotuco% rmic ClientIimplementation tucotuco% java ServerImplementation theServer Server is ready... Now we can start the programs in distributed fashion: In this example the server is started on tucotuco.cs.indiana.edu as theServer on port 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.

tucotuco% javac *.java tucotuco% rmic ServerImplementation tucotuco% rmic ClientIimplementation tucotuco% java ServerImplementation theServer Server is ready... Now we can start the programs in distributed fashion: In this example the server is started on tucotuco.cs.indiana.edu as theServer on port 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.

tucotuco% javac *.java tucotuco% rmic ServerImplementation tucotuco% rmic ClientIimplementation tucotuco% java ServerImplementation theServer Server is ready... Now we can start the programs in distributed fashion: In this example the server is started on tucotuco.cs.indiana.edu as theServer on port 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.

tucotuco% javac *.java tucotuco% rmic ServerImplementation tucotuco% rmic ClientIimplementation tucotuco% java ServerImplementation theServer Server is ready... Now we can start the programs in distributed fashion: In this example the server is started on tucotuco.cs.indiana.edu as theServer on port 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.

burrowww% java ClientImplementation larry tucotuco.cs.indiana.edu theServer So here's how we start the clients:

burrowww% java ClientImplementation larry tucotuco.cs.indiana.edu theServer So here's how we start the clients: blesmol% java ClientImplementation michael tucotuco.cs.indiana.edu theServer

burrowww% java ClientImplementation larry tucotuco.cs.indiana.edu theServer So here's how we start the clients: blesmol% java ClientImplementation michael tucotuco.cs.indiana.edu theServer bobac% java ClientImplementation toni tucotuco.cs.indiana.edu theServer

burrowww% java ClientImplementation larry tucotuco.cs.indiana.edu theServer So here's how we start the clients: blesmol% java ClientImplementation michael tucotuco.cs.indiana.edu theServer bobac% java ClientImplementation toni tucotuco.cs.indiana.edu theServer molerat% java ClientImplementation richard tucotuco.cs.indiana.edu theServer

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.

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.

One can identify these differences in the pattern presented. The major differences between the two concern the areas of: latency memory access partial failure, and concurrency But local and distributed computing present major differences:

One can identify these differences in the pattern presented. The major differences between the two concern the areas of: latency memory access partial failure, and concurrency But local and distributed computing present major differences:

One can identify these differences in the pattern presented. The major differences between the two concern the areas of: latency memory access partial failure, and concurrency But local and distributed computing present major differences:

One can identify these differences in the pattern presented. The major differences between the two concern the areas of: latency memory access partial failure, and concurrency But local and distributed computing present major differences:

One can identify these differences in the pattern presented. The major differences between the two concern the areas of: latency memory access partial failure, and concurrency But local and distributed computing present major differences:

One can identify these differences in the pattern presented. The major differences between the two concern the areas of: latency memory access partial failure, and concurrency But local and distributed computing present major differences:

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.RemoteException s

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.RemoteException s 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.RemoteException s 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.RemoteException s 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.RemoteException s 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.RemoteException s 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.RemoteException s 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.RemoteException s 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.

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

Bottom Line The network is the computer.