Distributed Objects Exercises in

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 IOR’s? With RMI OR’s? Exercises with Java RMI: a remote bank Your project status

Interface Exercises (1) Interface Address { setStreet(String); setHouseNumber(String); setCity(String); set ZipCode(String); } Is this interface design problematic? When?

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?

Interface Exercises (2) Interface Foo { init(); doIt(String); reset(); } Is this interface design understandable? Problems?

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?

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.

Why is activation so important? client Servant Passivate() Activate() persitent storage Servant Passivate() Activate() Servant Passivate() Activate() Servant Passivate() Activate() Servant Passivate() Activate() 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.

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.

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?

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.

Resources The remote bank example from David Flanagan’s Java by Example