Presentation 3: Designing Distributed Objects

1. Presentation 3:Designing Distributed Objects

2. Outline • Assumed students are knowledgeable about OOP principles and UML … • Local vs. Distributed Objects • How do local and distributed objects differ

3. Local versus Distributed Objects

4. Motivation • You all have experience with designing local objects that reside in the run-time environment of an OO programming language such as: • C++ • C# • Java • Designing distributed objects is different! • In the next section we will • Explain the differences. • Try to avoid some serious pitfalls

5. Local vs. distributed Objects • Differences between local and distributed objects in: • Life cycle • References (to objects) • Activation/Deactivation • Migration • Persistence • Latency of Requests • Concurrency • Communication • Security

6. Object Lifecycle • Local vs distributed objects lifecycle differences: • OOPL objects reside in one virtual machine. • From creation to deletion • Distributed objects might be created on a different machines • Not possible to use OOPL’s creation operators • Need to design features for it • Should be independent of server location • Distributed objects might be copied or moved (migrated) from one machine to another • To avoid overloading of a server • This will not happen with local objects • Deletion by garbage collection does not work in a distributed setting. • Too difficult to maintain referential integrity • Lifecycle needs attention during the design of distributed objects.

7. Object References • References to objects in OOPL are usually pointers to memory addresses • sometimes pointers can be turned into references (C++) • sometimes they cannot (Smalltalk,Java) • References to distributed objects are more complex • Location information (which server, how to communicate) • Security information (now not anymore a protected process) • References to object types (might differ – which server is in control – adminstrators forgetting to synchronize) • References to distributed objects are bigger (e.g 40 bytes with Orbix small footprint – 304 with Sun’s ORB) – • As opposed to 4 bytes for 32 bit references on OOPL VM’s • But often ranging from 300-700 (depending on features) • Too virtual memory consuming for clients holding references

8. Latency of Requests • Performing a local method call requires a couple of hundred nanoseconds. • An network object request requires between 0.1 and 10 milliseconds. • And possible more depending on the network • And the size of the objects • Interfaces of distributed objects need to be designed in a way that • operations perform coarse-grained tasks • do not have to be requested frequently • Therefore: • Be vary of turning everything into objects • Use Façade patterns instead – and decouple

9. Activation/Deactivation • Objects in OOPL are in virtual memory between creation and destruction. • This might be inappropriate for distributed objects • They are bigger than local objects (take up more space) • Combined with sheer number of objects … • Results in problems with capacity of server (virtual memory) • Also: objects might not be used for a long time • And: some hosts might have to be shut down without stopping all applications • Distributed object implementations are • brought into main memory (activation) • discarded from main memory (deactivation)

10. Activation/Deactivation (cont’d) • Several questions arise • Explicit vs. implicit activation (transparent for the programmer) • When to deactivate objects • Need to persist the state • Association between objects and processes • How to treat concurrent requests • Even across servers • Who decides answers to these questions? • Designer • Programmer • Administrator • Middleware – but designer must provide persistence facilities

11. Persistence • Stateless vs. statefull objects • Statefull objects have to save their state between • object deactivation and • object activation onto persistent storage • Can be achieved by • externalization into file system • mapping to relational database • object database • To be considered during object design • Statefull objects are more expensive to make redundant • Need to replicate more between servers • More of this in volume 2

12. Communication • Method invocations of OOPL objects most often synchronous • Because it is fast, efficient and intuitive for the programmer • Blocks calling object • Alternatives for distributed objects: • synchronous requests • Nice – but not always performant due to latency • Blocks the calling object for to long • oneway requests • deferred synchronous requests • asynchronous requests • Who decides on request • Designer of server? • Designer of client? • More on this at a later point

13. Failures • Distributed object requests are more likely to fail than local method calls • More points of failures • Server(s) • Client • Network • Different request reliabilities are available for distributed objects • Exactly-once semantics are too demanding on latency • Instead: At-most-once • only makes the call once – but inform of some failing (Exception) • (the call may have succeed, but the line is cut before an ack is received) • CORBA and RMI uses “At-most-once” but may use “maybe” • Others may be implemented, which we shall look at later • Clients have an obligation to validate that servers have executed request • Meaning: has to check for exceptions • Need to use transactions (all or nothing) – with roll back capabilities • More on this later