1. CS551 - Lecture 17 1 CS551 Object Oriented Middleware (VI) Advanced Topics (Chap. 8-10 of EDO) Yugi Lee STB #555 (816) 235-5932 yugi@cstp.umkc.edu www.cstp.umkc.edu/~yugi

2. 2 CS551 - Lecture 17 Locating Distributed Objects (chap 8) Avoid using physical locations for locating components! Naming: –Locating components by external names –Similar to white pages Trading: –Locating components by service characteristics –Similar to yellow pages Avoid using physical locations for locating components! Naming: –Locating components by external names –Similar to white pages Trading: –Locating components by service characteristics –Similar to yellow pages

3. 3 CS551 - Lecture 17 Location: Common Principles Object-oriented middleware uses object references to address server objects We need to find a way to get hold of these object references without assuming physical locations A name is a sequence of character strings that can be bound to an object reference A name binding can be resolved to obtain the object reference Object-oriented middleware uses object references to address server objects We need to find a way to get hold of these object references without assuming physical locations A name is a sequence of character strings that can be bound to an object reference A name binding can be resolved to obtain the object reference

4. 4 CS551 - Lecture 17 Location: Common Principles There may be many server objects in a distributed object system Server objects may have several names Leads to large number of name bindings Name space has to be arranged in a hierarchy to avoid –Name clashes –Poor performance when binding/resolving names Hierarchy achieved by naming contexts There may be many server objects in a distributed object system Server objects may have several names Leads to large number of name bindings Name space has to be arranged in a hierarchy to avoid –Name clashes –Poor performance when binding/resolving names Hierarchy achieved by naming contexts

5. 5 CS551 - Lecture 17 Cup Winners Cup Winners 1.FC Kaiserslautern 1.FC Kaiserslautern Premier First Man United Chelsea QPR South End United South End United England Germany 1. Liga 2. Liga BVB Bayern Bochum Lautern UEFA Manchester United Manchester United Common Principles: Naming Contexts

6. 6 CS551 - Lecture 17 Common Principles: Name Server Behaviour Name bindings are managed by name servers Not every server object needs a name Server objects may have several names (aliases) Name servers must store bindings persistently Name servers should be tuned towards efficiently resolving name bindings Name server may itself be distributed Name bindings are managed by name servers Not every server object needs a name Server objects may have several names (aliases) Name servers must store bindings persistently Name servers should be tuned towards efficiently resolving name bindings Name server may itself be distributed

7. 7 CS551 - Lecture 17 Limitations of Naming Limitation of Naming in all approaches: Client always has to identify the server by name. Inappropriate if client just wants to use a service at a certain quality but does not know from who: –Automatic cinema ticketing, –Video on demand, –Electronic commerce. Limitation of Naming in all approaches: Client always has to identify the server by name. Inappropriate if client just wants to use a service at a certain quality but does not know from who: –Automatic cinema ticketing, –Video on demand, –Electronic commerce.

8. 8 CS551 - Lecture 17 Trading Locating objects in location transparent way Naming simple but may not be suitable when –clients do not know server –there are multiple servers to choose from Trading supports locating servers based on service functionality and quality Naming  White pages Trading  Yellow Pages Locating objects in location transparent way Naming simple but may not be suitable when –clients do not know server –there are multiple servers to choose from Trading supports locating servers based on service functionality and quality Naming  White pages Trading  Yellow Pages

9. 9 CS551 - Lecture 17 Trading Characteristics Trader operates as broker between client and server. Enables client to change perspective from ´who?´ to ´what?´ Trader operates as broker between client and server. Enables client to change perspective from ´who?´ to ´what?´ Similar ideas in: –mortgage broker –insurance broker –stock brokerage Similar ideas in: –mortgage broker –insurance broker –stock brokerage Exporter Trader Importer 1:export 2:query 3:invoke

10. 10 CS551 - Lecture 17 Trading Characteristics Common language between client and server: –Service types, Qualities of service Server registers service with trader. –Server defines assured quality of service: Static QoS definition Dynamic QoS definition. Clients ask trader for –a service of a certain type, at a certain level of quality Trader supports –service matching –service shopping Common language between client and server: –Service types, Qualities of service Server registers service with trader. –Server defines assured quality of service: Static QoS definition Dynamic QoS definition. Clients ask trader for –a service of a certain type, at a certain level of quality Trader supports –service matching –service shopping

11. 11 CS551 - Lecture 17 Trading Policies Depending on constraint and available services, a large set of offer might be returned by a query. Trading policies are used to restrict the size of the matched offers –Specification of an upper limit –Restriction on service replacements –Restriction on modifiable properties (these might change between match making and service requests) Depending on constraint and available services, a large set of offer might be returned by a query. Trading policies are used to restrict the size of the matched offers –Specification of an upper limit –Restriction on service replacements –Restriction on modifiable properties (these might change between match making and service requests)

12. 12 CS551 - Lecture 17 Federated Traders Scalability demands federation of traders A trader participating in a federation –offers the services it knows about to other traders –forwards queries it cannot satisfy to other traders Problems –Non-termination of import –Duplication of matched offers Scalability demands federation of traders A trader participating in a federation –offers the services it knows about to other traders –forwards queries it cannot satisfy to other traders Problems –Non-termination of import –Duplication of matched offers

13. 13 CS551 - Lecture 17 Distributed Object Life Cycle (Chap 9) Distributed object life cycle different from local object life cycle Creation: –Where to create an object Migration: –Where to copy/move an object to –How to resolve heterogeneity in data and object code representation Deletion: –Garbage collection does not work Distributed object life cycle different from local object life cycle Creation: –Where to create an object Migration: –Where to copy/move an object to –How to resolve heterogeneity in data and object code representation Deletion: –Garbage collection does not work

14. 14 CS551 - Lecture 17 The Lifecycle unavailable copy move create delete available

15. 15 CS551 - Lecture 17 Creation: Client Programmer’s View Clients might wish to create objects on remote machines –Achieved by factories –Factory is an object that creates other objects –Abstract factory hides creation details Remote machines have to be identified in a location transparent way –Achieved by factory finders –Administrators should be able to decide where to create new objects –Policies are implemented using FactoryFinder objects. Clients might wish to create objects on remote machines –Achieved by factories –Factory is an object that creates other objects –Abstract factory hides creation details Remote machines have to be identified in a location transparent way –Achieved by factory finders –Administrators should be able to decide where to create new objects –Policies are implemented using FactoryFinder objects.

16. 16 CS551 - Lecture 17 Creation: Server Programmer’s View Server Programmer implements factories Factories need to register objects with object-oriented middleware through middleware interface –CORBA ORB Interface –COM’s SCM –Java RMI/Registry Type-specific factory –determines activation policy –may wrap generic factory Server Programmer implements factories Factories need to register objects with object-oriented middleware through middleware interface –CORBA ORB Interface –COM’s SCM –Java RMI/Registry Type-specific factory –determines activation policy –may wrap generic factory

17. 17 CS551 - Lecture 17 Creation: Administrator’s View Administrators need to provide factory finders that implement creation policies Factory finders need to be locatable by –Naming or –Trading Factory and factory finder implementations registered with middleware, e.g. –CORBA: Implementation Repository –COM: Windows Registry –Java/RMI: RMI Registry Administrators need to provide factory finders that implement creation policies Factory finders need to be locatable by –Naming or –Trading Factory and factory finder implementations registered with middleware, e.g. –CORBA: Implementation Repository –COM: Windows Registry –Java/RMI: RMI Registry

18. 18 CS551 - Lecture 17 Migration Objects may have to be moved or copied to other hosts because of –Discontinuation of hosts –Load balancing Migration –transparent to client programmer –not transparent to server programmer because of need to inherit from LifeCycleObject, implement copy/move operations Objects may have to be moved or copied to other hosts because of –Discontinuation of hosts –Load balancing Migration –transparent to client programmer –not transparent to server programmer because of need to inherit from LifeCycleObject, implement copy/move operations

19. 19 CS551 - Lecture 17 Migration: Administrator’s View Migration operations are often initiated by administrators Request of copy/move operation through some administration tool Administrator needs to take same responsibilities as for object creation, i.e. –Provide factory finder –Make factory finder locatable –Register factories and factory finder with middleware Migration operations are often initiated by administrators Request of copy/move operation through some administration tool Administrator needs to take same responsibilities as for object creation, i.e. –Provide factory finder –Make factory finder locatable –Register factories and factory finder with middleware

20. 20 CS551 - Lecture 17 Deletion: Client Programmer’s View Implicit deletion –Deletion is performed by garbage collector when object is not referenced –More expensive due to reference counting –Cannot be used if reference counting is not possible –Can ensure referential integrity to some extent Implicit deletion –Deletion is performed by garbage collector when object is not referenced –More expensive due to reference counting –Cannot be used if reference counting is not possible –Can ensure referential integrity to some extent Explicit Deletion –Deletion is requested by some client object when client assumes object is obsolete –No overhead for reference management –Can be used when reference counting cannot be performed –No guarantees about referential integrity can be made Explicit Deletion –Deletion is requested by some client object when client assumes object is obsolete –No overhead for reference management –Can be used when reference counting cannot be performed –No guarantees about referential integrity can be made

21. 21 CS551 - Lecture 17 Deletion: Administrator’s View Deletion of instances vs. deletion of types Instances: –Remove reference from location service –May trigger garbage collection if location service held last reference Types: –Remove factory finders from location service –Remove object, factory and factory finder from implementation repositories/registries –Remove object and factory type definition of from interface repository/type library Deletion of instances vs. deletion of types Instances: –Remove reference from location service –May trigger garbage collection if location service held last reference Types: –Remove factory finders from location service –Remove object, factory and factory finder from implementation repositories/registries –Remove object and factory type definition of from interface repository/type library

22. 22 CS551 - Lecture 17 What´s Missing: Replication Copies made by life cycle service are separate and do not evolve together Life cycle service cannot be used for replication of stateful server objects Replicated objects reflect each other´s state changes and hence evolve together Replication used for –load balancing –fault-tolerance Copies made by life cycle service are separate and do not evolve together Life cycle service cannot be used for replication of stateful server objects Replicated objects reflect each other´s state changes and hence evolve together Replication used for –load balancing –fault-tolerance

23. 23 CS551 - Lecture 17 Composite Objects: Design Consist of atomic objects Control life cycle of atomic objects Use UML class diagrams for modelling of composite objects: Consist of atomic objects Control life cycle of atomic objects Use UML class diagrams for modelling of composite objects: ClubTeamPlayer 1 * 1 * 11 consists of >has > Game

24. 24 CS551 - Lecture 17 When is Composition? The following questions can be used to validate an object composition model: –If a composite object migrates, can all its components migrate, too? –If a composite object is deleted, is it ok to remove all its components? –Can this component object migrate without deleting the composition relationship? The following questions can be used to validate an object composition model: –If a composite object migrates, can all its components migrate, too? –If a composite object is deleted, is it ok to remove all its components? –Can this component object migrate without deleting the composition relationship?

25. 25 CS551 - Lecture 17 Composite Object Lifecycle Apply lifecycle operations to root nodes All nodes that are in transitive closure of containment relationship will be copied/moved/deleted All relationships internal to that closure will be copied/moved/deleted All objects that are connected to these nodes will be copied/moved/deleted Apply lifecycle operations to root nodes All nodes that are in transitive closure of containment relationship will be copied/moved/deleted All relationships internal to that closure will be copied/moved/deleted All objects that are connected to these nodes will be copied/moved/deleted

26. 26 CS551 - Lecture 17 Object Persistence (Chap 10) Persistence is the ability of an object to survive the lifetime of the process in which it resides. Persistence is relevant for stateful server objects. The state needs to be retained between object deactivation and object activation Persistence is the ability of an object to survive the lifetime of the process in which it resides. Persistence is relevant for stateful server objects. The state needs to be retained between object deactivation and object activation

27. 27 CS551 - Lecture 17 How to achieve Persistence? Storing object state on persistent datastore before de-activation Upon activation, load object state from persistent datastore Persistent storage can be –File system –Relational Database –Object-Database –Flash-RAM Storing object state on persistent datastore before de-activation Upon activation, load object state from persistent datastore Persistent storage can be –File system –Relational Database –Object-Database –Flash-RAM

28. 28 CS551 - Lecture 17 Transparency of Persistence Persistence should be transparent to users and designers of client objects (Using a Persistent State Service) Client Objects Server Objects Datastore Objects Client Interface Persistence Interface