1. © Chinese University, CSE Dept. Distributed Systems / 8 - 1 Distributed Systems Topic 8: Naming, Trading and Lifecycle Services Computer Science & Engineering Department The Chinese University

2. © Chinese University, CSE Dept. Distributed Systems / 8 - 2 Outline 1 Location Transparency 2 Naming 3 Trading 4 Object Lifecycle 5 Summary

3. © Chinese University, CSE Dept. Distributed Systems / 8 - 3 1 Location Transparency  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

4. © Chinese University, CSE Dept. Distributed Systems / 8 - 4 2 Naming 1 Naming Service Examples 2 Common Characteristics 3 CORBA Naming Service 4 Limitations

5. © Chinese University, CSE Dept. Distributed Systems / 8 - 5 2.1 NFS Directories lec lyu teaching web www usr sbin bin inetd ls rlogin uac csc5110 cprj

6. © Chinese University, CSE Dept. Distributed Systems / 8 - 6 2.1 X.500 Service Architecture DSA DUA

7. © Chinese University, CSE Dept. Distributed Systems / 8 - 7 2.1 X.500 Directory Service X.500 Service (root) China (country)Hong Kong (country)Singapore (country) Hang Seng Bank. (organization)... Chinese University (organization)... Engineering (organizationalUnit) Personnel (organizationalUnit)... IE (organizationalUnit)CSE (organizationalUnit) Michael Lyu (person)CSC5110 (class account)...

8. © Chinese University, CSE Dept. Distributed Systems / 8 - 8 2.1 An X.500 DIB Entry info Michael Lyu, Departmental Teaching Staff, Computer Science & Engineering Department, Chinese University of Hong Kong commonName Michael R. Lyu Rung-Tsong Lyu R.T. Lyu M.R. Lyu surname Lyu telephoneNumber +852 26098429 uid lyu mail lyu@cse.cuhk.edu.hk Michael_Lyu@cuhk.edu.hk roomNumber Engineering Building 927 userClass Professor

9. © Chinese University, CSE Dept. Distributed Systems / 8 - 9 2.1 Internet Domain Name Service a.root-servers.net (root) edu.hk ac.uk ie.cuhk.edu.hk cse.cuhk.edu.hk ns1.cuhk.edu.hk 137.189.6.1 (edu.hk) ns1.cs.ucl.ac.uk (ac.uk) ic.ac.uk qmw.ac.uk city.ac.uk nameserv.city.ac.uk (city.ac.uk) *.city.ac.uk *.cse.cuhk.edu.hk beryl.cuhk.edu.hk 137.189.91.187 (cse.cuhk.edu.hk)

10. © Chinese University, CSE Dept. Distributed Systems / 8 - 10 2.2 Common Characteristics Concerns to be addressed by a naming service:  Names.  Namespaces.  Naming service provides operations for –defining names of components (bind). –lookup components by name (resolve).  Persistence of bindings. NFS – file system X.500 – server Internet DNS – configuration database

11. © Chinese University, CSE Dept. Distributed Systems / 8 - 11 2.2 Common Characteristics Qualities of service:  Distribution of name spaces  Performance profile –Caching –Replication  Transaction properties of naming operations

12. © Chinese University, CSE Dept. Distributed Systems / 8 - 12 2.3 CORBA Architecture Application Objects CORBA facilities CORBA services Object Request Broker

13. © Chinese University, CSE Dept. Distributed Systems / 8 - 13 2.3 CORBA Naming Service Application Objects CORBA facilities CORBA services Object Request Broker Naming

14. © Chinese University, CSE Dept. Distributed Systems / 8 - 14 2.3 Introduction  Supports bindings of names to CORBA object references.  Names are scoped in naming contexts.  Multiple names can be defined for object references.  Not all object references need names.

15. © Chinese University, CSE Dept. Distributed Systems / 8 - 15 2.3 Naming Contexts Cup Winners 1.FC Kaiserslautern Premier First Man United Chelsea QPR South End United England Germany 1. Liga 2. Liga BVB Bayern Bochum Lautern UEFA Manchester United

16. © Chinese University, CSE Dept. Distributed Systems / 8 - 16 2.3. CORBA Names  Names are composed of simple names.  Simple names are value-kind pairs.  Value attribute is used for resolving names.  Kind attribute is used to provide information about the role of the object.

17. © Chinese University, CSE Dept. Distributed Systems / 8 - 17 module CosNaming { typedef string Istring; struct NameComponent { Istring id; Istring kind; }; typedef sequence Name;... }; 2.3. IDL Types for Names

18. © Chinese University, CSE Dept. Distributed Systems / 8 - 18 2.3. The IDL Interfaces  Naming Service is specified by two IDL interfaces: –NamingContext defines operations to bind objects to names and resolve name bindings. –BindingIterator defines operations to iterate over a set of names defined in a naming context.

19. © Chinese University, CSE Dept. Distributed Systems / 8 - 19 interface NamingContext { void bind(in Name n, in Object obj) raises (NotFound,...); Object resolve(in Name n) raises (NotFound,CannotProceed,...); void unbind (in Name n) raises (NotFound, CannotProceed...); NamingContext new_context(); NamingContext bind_new_context(in Name n) raises (NotFound,...) void list(in unsigned long how_many, out BindingList bl, out BindingIterator bi); }; 2.3. Excerpt of IDL Interface

20. © Chinese University, CSE Dept. Distributed Systems / 8 - 20 2.3. Excerpt of IDL Interface (cont´d) interface BindingIterator { boolean next_one(out Binding b); boolean next_n(in unsigned long how_many, out BindingList bl); void destroy(); }

21. © Chinese University, CSE Dept. Distributed Systems / 8 - 21 2.3. C++ Example CORBA::Object *obj; CosNaming::NamingContext *root; Soccer::Team *t; CosNaming::Name* name; obj=CORBA::BOA.resolve_initial_references ("NameService"); root=CosNaming::NamingContext::_narrow(obj); name=new CosNaming::Name(4); name[0].id=CORBA::string_dupl("UEFA"); name[1].id=CORBA::string_dupl("England"); name[2].id=CORBA::string_dupl("Premier"); name[3].id=CORBA::string_dupl("Arsenal"); t=Soccer::Team::_narrow(root->resolve(name)); cout print();

22. © Chinese University, CSE Dept. Distributed Systems / 8 - 22 2.4 Limitations  Limitation of Naming: 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.

23. © Chinese University, CSE Dept. Distributed Systems / 8 - 23 3 Trading 1 Characteristics 2 Example 3 OMG/CORBA Trading Service

24. © Chinese University, CSE Dept. Distributed Systems / 8 - 24 3.1 Trading Characteristics  Trader operates as broker between client and server.  Enables client to change perspective from ´who?´ to ´what?´  Selection between multiple service providers.  Similar ideas in: –yellow pages –insurance broker –stock brokerage.

25. © Chinese University, CSE Dept. Distributed Systems / 8 - 25 3.1 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.

26. © Chinese University, CSE Dept. Distributed Systems / 8 - 26 3.1 Trading Characteristics  Clients ask trader for –a service of a certain type –at a certain level of quality  Trader supports –service matching –service shopping

27. © Chinese University, CSE Dept. Distributed Systems / 8 - 27 3.2 Example  Distributed system for video-on-demand: Trader Video-on- demand provider MGM Warner Independent User Server

28. © Chinese University, CSE Dept. Distributed Systems / 8 - 28 3.3 CORBA Trading Service Application Objects CORBA facilities CORBA services Object Request Broker Trading

29. © Chinese University, CSE Dept. Distributed Systems / 8 - 29 3.3 OMG Trading Service Trader Client Server (1) Register (2) Lookup (2a) Monitor QoS (3) Application

30. © Chinese University, CSE Dept. Distributed Systems / 8 - 30 3.3 Properties Specify qualities of service: typedef Istring PropertyName; typedef sequence PropertyNameSeq; typedef any PropertyValue; struct Property { PropertyName name; PropertyValue value; }; typedef sequence PropertySeq; enum HowManyProps {none, some, all}; union SpecifiedProps switch (HowManyProps) { case some : PropertyNameSeq prop_names; };

31. © Chinese University, CSE Dept. Distributed Systems / 8 - 31 3.3 Register Trader interface for servers: interface Register { OfferId export(in Object reference, in ServiceTypeName type, in PropertySeq properties) raises(...); void withdraw(in OfferId id) raises(...); void modify(in OfferId id, in PropertyNameSeq del_list, in PropertySeq modify_list) raises (...); };

32. © Chinese University, CSE Dept. Distributed Systems / 8 - 32 3.3 Lookup Trader interface for clients: interface Lookup { void query(in ServiceTypeName type, in Constraint const, in Preference pref, in PolicySeq policies, in SpecifiedProps desired_props, in unsigned long how_many, out OfferSeq offers, out OfferIterator offer_itr, out PolicyNameSeq Limits_applied) raises (...); };

33. © Chinese University, CSE Dept. Distributed Systems / 8 - 33 4 CORBA Lifecycle Service Application Objects CORBA facilities CORBA services Object Request Broker Lifecycle

34. © Chinese University, CSE Dept. Distributed Systems / 8 - 34 4.1 Introduction  Component creation in a distributed system: –Location for component has to be identified. –Identification of location must be transparent for component and its clients.  Component duplication: –Location has to be identified. –Heterogeneity between source and target platform.  Component deletion: –Garbage collection techniques not applicable. –Referential integrity

35. © Chinese University, CSE Dept. Distributed Systems / 8 - 35 4.1 The Object Lifecycle unavailable copy move create delete available

36. © Chinese University, CSE Dept. Distributed Systems / 8 - 36 4.2 Object Creation  Factory Objects: –have operations that create and return references to new objects. –new objects ´inherit´ location from factory object.  Example: interface personFactory { person createPerson(); };  Problem of location transparency is reduced to finding factory objects.

37. © Chinese University, CSE Dept. Distributed Systems / 8 - 37 4.2 Object Creation  Factory location supported by: interface FactoryFinder { Factories find_factories (in Key factory_key) raises (NoFactory); };  Factories register with factory finder using a private protocol.  Factory finder objects are proxies for a location.  Factory finder objects can be located by other means (e.g. naming or trading).

38. © Chinese University, CSE Dept. Distributed Systems / 8 - 38 4.2 Object Creation  LifeCycle Service includes generic factory: interface GenericFactory { boolean supports(in Key k); Object create_object(in Key k) raises (NoFactory, InvalidCriteria, CannotMeetCriteria); };  Advantage: does not require type specific factories.  Disadvantage: No specific initializations.

39. © Chinese University, CSE Dept. Distributed Systems / 8 - 39 4.3 Object Duplication  Duplication defined in: interface LifeCycleObject { LifeCycleObject copy (in FactoryFinder there) raises (NoFactory,...);... };  Most object types are subtypes of LifeCycleObject.  Subtypes must redefine copy.

40. © Chinese University, CSE Dept. Distributed Systems / 8 - 40 4.3 Object Duplication  Redefinition uses factory finder to obtain factory reference on target machine.  Factory is used to create new object on target machine.  Attribute values are transferred.  Reference to newly created object is returned.

41. © Chinese University, CSE Dept. Distributed Systems / 8 - 41 4.4 Object Deletion  Deletion is defined in LifeCycleObject interface: interface LifeCycleObject { void remove() raises (NotRemovable); };  Subtypes redefine remove to free memory occupied by type specific attributes.  Referential integrity is not preserved.  Standard exception is raised if object has been removed.

42. © Chinese University, CSE Dept. Distributed Systems / 8 - 42 4.5 Object Migration  Migration is the transition of an object from one server to another one.  Interface defined in LifeCycleObject : interface LifeCycleObject { void move(in FactoryFinder there) raises(NoFactory,NotMovable); };  Subtypes must redefine move.

43. © Chinese University, CSE Dept. Distributed Systems / 8 - 43 4.6 What´s Missing: Replication  Copies made by life cycle service are seperate and do not evolve together.  Life cycle service cannot be used for replication.  Replicated objects reflect each other´s state changes and hence evolve together.  Replication used for –load balancing –fault-tolerance.

44. © Chinese University, CSE Dept. Distributed Systems / 8 - 44 5 Summary  Location Transparency requires other forms of identification than physical addresses.  Naming services provide facilities to give external names to components.  Trading services match service types requested by clients to servers that can satisfy them.  Object lifecycle services define a number of abstract interfaces that can be redefined for the object lifecycle.