The Net Worth of an ObjectOriented Pattern

1
The Net Worth of an Object-Oriented Pattern

• Practical Implications of the Java RMI

Adrian German Lecturer, Computer Science
Department Indiana University Bloomington
2
There will be a server, implemented as follows

• class ServerImplementation

3
There will be many clients, implemented as
follows

• class ClientImplementation

4
The server has a business card

• public interface Server

5
And it implements it

• class ServerImplementation implements Server

6
The client also has a business card

• public interface Client

7
And, like the server, it makes a promise to
fulfill it

• class ClientImplementation implements Client

8
The server keeps track of clients

• class ServerImplementation implements Server
• Client clients new Client100
• int index -1

9
The server keeps track of clients

• class ServerImplementation implements Server
• Client clients new Client100
• int index -1

The index of the most recently allocated cell is
-1 if the array is empty.
10
The server keeps track of clients

• class ServerImplementation implements Server
• Client clients new Client100
• 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
11
The server keeps track of clients

• class ServerImplementation implements Server
• Client clients new Client100
• 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
12
What else does the server do?
13
What else does the server do?

• public interface Server
• public void register(Client client)

14
What else does the server do?

• public interface Server
• public void register(Client client)

It allows clients to register with it, whatever
that means.
15
Although that, in this case, amounts to

• synchronized public void register(Client client)
  
• clientsthis.index client
• client.setID(new Integer(this.index))
• for (int i 0 i lt this.index i)
• clientsi.register(new Integer(this.index),
  client)
• client.register(new Integer(i),
  clientsi)

16
Although that, in this case, amounts to

• synchronized public void register(Client client)
  
• clientsthis.index client
• client.setID(new Integer(this.index))
• for (int i 0 i lt this.index i)
• clientsi.register(new Integer(this.index),
  client)
• client.register(new Integer(i),
  clientsi)

So we see that, apparently, a client can
set its ID (through/during registration with the
server,)
17
Although that, in this case, amounts to

• synchronized public void register(Client client)
  
• clientsthis.index client
• client.setID(new Integer(this.index))
• for (int i 0 i lt this.index i)
• clientsi.register(new Integer(this.index),
  client)
• client.register(new Integer(i),
  clientsi)

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)
18
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)

19
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)

Lets see how these promises can be fulfiled.
20
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()

21
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 Client100
• int index -1
• synchronized public void register(Integer
  index, Client client)
• this.index index.intValue()
• this.peerthis.index client

22
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 Client100
• int index -1
• synchronized public void register(Integer
  index, Client client)
• this.index index.intValue()
• this.peerthis.index client

23
Lets go back to the server.
24
Lets go back to the server.
How does it get started and what does it do?
25
Lets go back to the server.
How does it get started and what does it do?
The server has no constructor.
26
Lets 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.
27
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)

28
Broadcasting amounts to the following

• synchronized public void broadcast()
• for (int i 0 i lt this.index i)
• clientsi.setAvailable(new Boolean(false))
• for (int i 0, check 0 i lt this.index
  i)
• check clientsi.getBalance()
• for (int i 0 i lt this.index i)
• clientsi.setAvailable(new Boolean(true))

29
Broadcasting amounts to the following

• synchronized public void broadcast()
• for (int i 0 i lt this.index i)
• clientsi.setAvailable(new Boolean(false))
• for (int i 0, check 0 i lt this.index
  i)
• check clientsi.getBalance()
• for (int i 0 i lt this.index i)
• clientsi.setAvailable(new Boolean(true))

30
Broadcasting amounts to the following

• synchronized public void broadcast()
• for (int i 0 i lt this.index i)
• clientsi.setAvailable(new Boolean(false))
• for (int i 0, check 0 i lt this.index
  i)
• check clientsi.getBalance()
• for (int i 0 i lt this.index i)
• clientsi.setAvailable(new Boolean(true))

31
During broadcasting
32

• During broadcasting
• clients are first shut down
• (by setting their availability to false)

33

• 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

34

• 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

35

• 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

Heres how we accomplish these steps.
36
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()

37
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.
38

• Boolean available new Boolean(true)
• synchronized public void setAvailable(Boolean
  availability)
• this.available availability
• int balance
• public int getBalance()
• return this.balance

39

• 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?
40
Broadcasting is just a little bit more
complicated but other than that, thats it.

• // after turning the clients off
• String report , calculation
• int check 0
• for (int i 0 i lt this.index i)
• report clientsi.report() "\n"
• calculation "(" clientsi.getBalance()
  ").."
• check clientsi.getBalance()
• System.out.println("Server sees " report)
• System.out.println(calculation " ---gt "
  check)
• // now turn the clients back on

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

42
Implementation for this extra feature is
immediate, as well

• class ClientImplementation implements Client
• ...
• String name
• public String report()
• return this.name " " this.balance

43
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?
44
The server provides a method for that

• class ServerImplementation implements Server,
  Runnable
• ...
• public void startAsLocalServer()
• new Thread(this).start()

45
If we were to try this program out we'd do
something like this

• class LocalSetup
• public static void main(String args)

46
A server needs to be created, then started

• class LocalSetup
• public static void main(String args)
• ServerImplementation server new
  ServerImplementation()
• server.startAsLocalServer()

47
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.
48
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?
49

• class ClientImplementation implements Client
• ...
• public ClientImplementation(String name)
• this.name name

We need some clients, too. But how does one
create a client?
50
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 lt 6 i)
• ClientImplementation dealer
• new ClientImplementation("Dealer_" i)
• dealer.startAsClientOf(server)

51
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

52

• 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

53

• 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.
54
And, if started, what do clients do?
This addition however has significant
ramifications.
55
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.
56
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)

57
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.
58

Initiating a transfer has the following
description

• class ClientImplementation implements Client,
  Runnable
• ...
• synchronized private void initiateTransfer()
• if (this.index gt 0)
• int chosen (int) (Math.random()
  (this.index 1))
• if (chosen this.id // always deal with
  someone else
• peerchosen null) return
• this.balance peerchosen.process(
• new Transaction(this.name, this.id,
• (int) (Math.random() 10 1),
• Math.random() gt 0.5 ? "sent"
  "requested"))

59
Initiating a transfer has the following
description

• class ClientImplementation implements Client,
  Runnable
• ...
• synchronized private void initiateTransfer()
• if (this.index gt 0)
• int chosen (int) (Math.random()
  (this.index 1))
• if (chosen this.id // always deal with
  someone else
• peerchosen null) return
• this.balance peerchosen.process(
• new Transaction(this.name, this.id,
• (int) (Math.random() 10 1),
• Math.random() gt 0.5 ? "sent"
  "requested"))

60
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

61
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.
62
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

63
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.
64
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.
65
Is it possible to have avoided using
java.rmi.Remote at all?
66
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.
67
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

68
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.
69
Let's introduce this abstraction

• public abstract class NetworkPeer implements
  java.rmi.Remote

70
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.exportOb
  ject(this)

71
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
• )

72
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(peerH
  ost, peerPort,
• 
  peerName)
• this.startAsClientOf(peer) // see below
  ...

73
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.R
  emote peer)
• throws
  java.rmi.RemoteException

74
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.createRegistr
  y(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?

75
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.createRegistr
  y(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?

76
First for the server

• class ServerImplementation extends NetworkPeer
• 
  implements Server, Runnable
• ...
• public static void main(String args)
• String portNumber args0, ownName
  args1
• 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

77
And then for the client

• class ClientImplementation extends NetworkPeer
• implements Client, Runnable
• ...
• public static void main(String args) throws
  Exception
• String ownName args0, serverHostName
  args1,
• serverPortNumber args2,
  serverName args3
• 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 ...

78
And there's one last change we need to make

• public class Transaction implements
  java.io.Serializable
• // everything else exactly the same

79
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 ...

80
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 ...

81
And the decorations propagate one last step

• class ServerImplementation extends ... implements
  ...
• ...
• synchronized public void broadcast() throws
  java.rmi.RemoteException ...
• ...

82
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.
83
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.
84
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.
85
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.
86
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.
87
So here's how we start the clients

• burrowww java ClientImplementation larry
  tucotuco.cs.indiana.edu 36091 theServer

88
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
89
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
90
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
91
And the LocalSetup still works as before.
92
And the LocalSetup still works as before.
So one can (and should) use this pattern from the
outset.
93
Object-oriented programming is really about
distributed programming.
94
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)
95
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)
96
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)
97
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)
98
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)
99
Object-oriented programming is really about
distributed programming.
That's why we didn't say anything about static
members.
100
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.
101
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.
102
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.
103
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.
104
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.
105
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.
106
1. Latency Objects sent back and forth need to
be Serializable.
107
1. Latency Objects sent back and forth need to
be Serializable.
2. Memory Access Replace the pointers with
object references.
108
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
109
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.
110
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.
111
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.
112
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.
113
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.
114
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)
115
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)
116
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.
117
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.
118
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.
119
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.
120
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.
121
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.
122
Conclusions1. 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.
123
Conclusions1. 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.
124
Conclusions1. 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.
125
Conclusions1. 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.
126
Conclusions1. 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.
127
Bottom Line The network is the computer.

128
Bottom Line The network is the computer.

129
Bottom Line The network is the computer.