CS551 Object Oriented Middleware (VI) Advanced Topics (Chap. 8-10 of EDO)

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 CS551 - Lecture 17

2. 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 CS551 - Lecture 17

3. 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 CS551 - Lecture 17

4. 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 CS551 - Lecture 17

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

6. 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 CS551 - Lecture 17

7. 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. CS551 - Lecture 17

8. 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 CS551 - Lecture 17

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

10. 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 CS551 - Lecture 17

11. 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) CS551 - Lecture 17

12. 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 CS551 - Lecture 17

13. 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 CS551 - Lecture 17

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

15. 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. CS551 - Lecture 17

16. 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 CS551 - Lecture 17

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 CS551 - Lecture 17

18. 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 CS551 - Lecture 17

19. 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 CS551 - Lecture 17

20. 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 • 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 CS551 - Lecture 17

21. 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 CS551 - Lecture 17

22. 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 CS551 - Lecture 17

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

24. 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? CS551 - Lecture 17

25. 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 CS551 - Lecture 17

26. 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 CS551 - Lecture 17

27. 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 CS551 - Lecture 17

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