Distributed Objects

1. Distributed Objects • Objective • Understand the difference between local and distributed objects and how to correctly use them • Outline • Object Model • Local versus Distributed Objects Designing Distributed Objects

2. Object Types • Object types specify the common characteristic of similar objects • Object types define a contract that binds the interaction between client and server objects • Object types are specified through interfaces that determine the operations that clients can request. • Operation visibility: public, private, etc. • Signature of an operation: name, list of formal parameters, and the result with type information • Non-Object Types • Atomic types: boolean, char, int, etc, • Values • No identity • Cannot be referenced Designing Distributed Objects

3. Objects • Object • Unique identifier • Multiple references • Attributes • public • Private • Name and a type • Class or static variables (not for distributed objects) • Operations • Object Identity vs Equality • Identical  equal • Equal ! identical Designing Distributed Objects

4. Requests • An object request is made by a client object in order to request execution of an operation from a server object. • Object reference • Operation • List of actual parameters • Request vs method invocation • Resolve data heterogeneity • Synchronization between client and server objects • Communication through network • … Designing Distributed Objects

5. Exceptions • Exceptions are a mechanism for notifying clients about failures that occur during the execution of an object request. • Data structures carrying details about failures • Part of the contract between client and sever objects • Raised by a server object • Raised by middleware (system exception) • Transferred via network from server to client Designing Distributed Objects

6. Types and Distributed Objects • Attributes, operations and exceptions are properties objects may export to other objects. • Multiple objects may export the same properties. • Only define the properties once! • Attributes and operations, and exceptions are defined in object types. Designing Distributed Objects

7. Attributes • Attributes have a name and a type. • Type can be an object type or a non-object type. • Attributes are readable by other components. • Attributes may or may not be modifiable by other components. • Attributes correspond to one or two operations (set/get). Designing Distributed Objects

8. Exceptions • Service requests in a distributed system may not be properly executed. • Exceptions are used to explain reason of failure to requester of operation execution. • Operation execution failures may be • generic or • specific. • Specific failures may be explained in specific exceptions. Designing Distributed Objects

9. Operations • Operations have a signature that consists of • a name, • a list of in, out, or inout parameters, • a return value type, and • a list of exceptions that the operation can raise. Designing Distributed Objects

10. Object Type Example <<interface>> Player -name:string; -role:Position; -Number:int; +void book(in Date d) raises (AlreadyBooked); Designing Distributed Objects

11. Operation Execution Requests • A client object can request an operation execution from a server object. • Operation request is expressed by sending a message (operation name) to server object. • Server objects are identified by object references. • Clients have to react to exceptions that the operation may raise. Designing Distributed Objects

12. Subtyping • Properties shared by several types should be defined only once. • Object types are organised in a type hierarchy. • Subtypes inherit attributes, exceptions and operations from their supertypes. • Subtypes can add more specific properties. • Subtypes can redefine inherited properties. Designing Distributed Objects

13. Multiple Inheritance • Means that one object type can be subtype of more than one super type • Not supported by all middleware • May lead to ambiguities Designing Distributed Objects

14. Multiple Inheritance Example <<interface>> Player <<interface>> Trainer -name:string; -role:Position; -Number:int; -salary:int; +next_game():Date +void book(in Date d) raises (AlreadyBooked); +next_game():Date <<interface>> PlayerTrainer Designing Distributed Objects

15. Polymorphism • Object models may be statically typed. • Static type of a variable restricts the dynamic type of objects that can be assigned to it. • Polymorphism denotes the possibility of assignments of objects that are instances of the static type and all its subtypes. Designing Distributed Objects

16. Polymorphism Example chelsea:Team name = “Chelsea” v:PlayerTrainer d:Player name = “Gianluca Vialli” role = Forward Number = 10 salary=1000000 name = “Marcel Desailly” role=Defender Number=5 z:Player name = “Gianfranco Zola” role=Forward Number=3 Designing Distributed Objects

17. Motivation • Many will have experience with designing local objects that reside in the run-time environment of an OO programming lang. • Designing distributed objects is different! • Explain the differences. • Avoid some serious pitfalls Designing Distributed Objects

18. Local vs. distributed Objects • References • Activation/Deactivation • Migration • Persistence • Latency of Requests • Concurrency • Communication • Security • Several Pitfalls are lurking here Designing Distributed Objects

19. Object Lifecycle • OOPL objects reside in one virtual machine. • Distributed objects might be created on a different machine. • Distributed objects might be copied or moved (migrated) from one machine to another. • Deletion by garbage collection does not work in a distributed setting. • Lifecycle needs attention during the design of distributed objects. Designing Distributed Objects

20. 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 • Security information • References to object types • References to distributed objects are bigger (e.g 40 bytes with Orbix). Designing Distributed Objects

21. Latency of Requests • Performing a local method call requires a couple of hundred nanoseconds. • An object request requires between 0.1 and 10 milliseconds. • Interfaces of distributed objects need to be designed in a way that • operations perform coarse-grained tasks • do not have to be requested frequently Designing Distributed Objects

22. Java Distributed Objects Vector List +size():int +elementAt(i:int):Object ... +long list (in how_many:long, out l:sequence<object>, out bi:Iterator i) Iterator +next_one(out o:Object): boolean +next_n(in how_many:long, out l:sequence<object>):boolean Example: Iteration over a Sequence Designing Distributed Objects

23. Activation/Deactivation • Objects in OOPL are in virtual memory between creation and destruction. • This might be inappropriate for distributed objects • sheer number of objects • objects might not be used for a long time • 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) Designing Distributed Objects

24. Activation/Deactivation (cont’d) Tony:Trainer BvB:Team bookGoalies object activated object deactivation Designing Distributed Objects

25. Activation/Deactivation (cont’d) • Several questions arise • Repository for implementations • Association between objects and processes • Explicit vs. implicit activation • When to deactivate objects • How to treat concurrent requests • Who decides answers to these questions? • Designer • Programmer • Administrator • How to document decisions? Designing Distributed Objects

26. 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 Designing Distributed Objects

27. Parallelism • Execution of OOPL objects is often • sequential • concurrent (with multi-threading) • Distributed objects execute in parallel • Can be used to accelerate computations Designing Distributed Objects

28. Communication • Method invocations of OOPL objects are synchronous • Alternatives for distributed objects: • synchronous requests • oneway requests • deferred synchronous requests • asynchronous requests • Who decides on request • Designer of server? • Designer of client? • How documented? Designing Distributed Objects

29. Failures • Distributed object requests are more likely to fail than local method calls • Different request reliabilities are available for distributed objects • Clients have an obligation to validate that servers have executed request Designing Distributed Objects

30. Security • Security in OO applications can be dealt with at session level. • OOPL Objects do not have to be written in a particular way. • For distributed objects: • Who is requesting an operation execution? • How can we know that subject is who it claims to be? • How do we decide whether or not to grant that subject the right to execute the service? • How can we prove that we have delivered a service so as to make the requester pay Designing Distributed Objects

31. Key Points • Distributed objects evolved from research and development in object-oriented programming languages and distribution middleware • The Unified Modeling Language can be used to design distributed objects • Meta object models determine the characteristics of distributed objects • Designers need to be aware of differences between local and distributed objects Designing Distributed Objects