Distributed Objects

1
Distributed Objects

• Exercises in

2
Overview

• Interface Exercises
• How does an Object Reference look? How long
  can/should a client store one?
• How do you tell an idle client from a crashed
  client?
• What happens if you downloaded a stub to a client
  and the implementation gets changed afterwards?
• Why is activation so important? (think about
  state on the server)
• Design problem Singleton proxy
• Load Balancing with CORBA IORs? With RMI ORs?
• Exercises with Java RMI a remote bank
• Your project status

3
Interface Exercises (1)
Interface Address setStreet(String) setHouse
Number(String) setCity(String) set
ZipCode(String)
Is this interface design problematic? When?
4
Interface Exercises (1)

• If two clients would use an instance of such a
  remote object concurrently (like e.g. one trying
  to read everything while the other one tries to
  perform a change of address there is a high
  chance of the reader to read inconsistent data.
• How would a server instantiate such an object?
  Would it create an empty object and hope that the
  client will fill everything in?

5
Interface Exercises (2)
Interface Foo init() doIt(String) reset()

Is this interface design understandable? Problems?
6
Interface Exercises (2)

• Init() this is an example of the
  half-baked-object anti-pattern. An object is
  created only by half and then returned to an
  unsuspecting client which will hopefully
  perform the rest of the initialization by calling
  init()
• init(), doIt(), reset() what is the order of
  usage here? After calling doIt(), do I need to
  call reset()? Or after calling reset(), do I need
  to do init() again?

7
How long can you store an IOR?
Since the IOR contains a host and port
combination it will be invalidated if host/port
changes If the IOR would contain longer lasting
keys (like foreign keys in a database, then a
mechanism could be defined that would reconnect
to the proper remote object even if the servant
changed to a different host.
8
Why is activation so important?
Servant Passivate() Activate()
Servant Passivate() Activate()
Servant Passivate() Activate()
Servant Passivate() Activate()
Servant Passivate() Activate()
client
persitent storage
client
client
client
client
If a server can transparently store servant state
on persistent storage and re-create the servant
on demand, then it is able to control its
resources against memory exhaustion and
performane degradation.
9
Implementation changes consequences

• In RMI you will need to restart the registry.
  This invalidates all outstanding remote object
  references from this registry. You will need to
  restart the clients too.

10
A remote bank (Flanagan example)

• Look at the method implementations Why do some
  methods have a synchronized outside AND inside?
• Make a performance guess how many clients will
  the server be able to serve? What are the
  problems?

11
A remote bank (Flanagan example)

• synchronized twice? Yes, the first one locks the
  method against concurrent access, the second one
  an internally used object (member) of the class.
  The last one locks the object against all calls
  that do a synchronize (object).
• The most methods are synchronized from the
  outside. Inside (meaning inside a synchronized
  area) they perform some operations (like
  allocations) that should happen outside.
• If there is only one server object for this bank
  there will be a performance problem because of
  over-synchronization.

12
Resources

• The remote bank example from David Flanagans
  Java by Example