Designing 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 > 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 > Player -name:string; -role:Position; -Number:int; +void book(in Date d) raises (AlreadyBooked); +next_game():Date > Trainer -salary:int; +next_game():Date > 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 name = “Gianluca Vialli” role = Forward Number = 10 salary= z:Player name = “Gianfranco Zola” role=Forward Number=3 d:Player name = “Marcel Desailly” role=Defender Number=5

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 Example: Iteration over a Sequence  Java Vector +size():int +elementAt(i:int):Object...  Distributed Objects List +long list (in how_many:long, out l:sequence, out bi:Iterator i) Iterator +next_one(out o:Object): boolean +next_n(in how_many:long, out l:sequence ):boolean

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) BvB:Team bookGoalies Tony:Trainer object activated object activated object deactivation 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