1. Presentation 3: Designing Distributed Objects

2. Ingeniørhøjskolen i Århus Slide 2 af 14 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. Ingeniørhøjskolen i Århus Slide 4 af 14 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. Ingeniørhøjskolen i Århus Slide 5 af 14 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. Ingeniørhøjskolen i Århus Slide 6 af 14 Object Lifecycle If we look at local vs distributed objects lifecycles we see that: –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. Ingeniørhøjskolen i Århus Slide 7 af 14 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. Ingeniørhøjskolen i Århus Slide 8 af 14 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. Ingeniørhøjskolen i Århus Slide 9 af 14 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. Ingeniørhøjskolen i Århus Slide 10 af 14 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. Ingeniørhøjskolen i Århus Slide 11 af 14 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. Ingeniørhøjskolen i Århus Slide 12 af 14 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. Ingeniørhøjskolen i Århus Slide 13 af 14 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