1 / 44

Distributed Systems

Distributed Systems. Topic 8: Naming, Trading and Lifecycle Services Computer Science & Engineering Department The Chinese University. Outline. 1 Location Transparency 2 Naming 3 Trading 4 Object Lifecycle 5 Summary. 1 Location Transparency.

cleave
Télécharger la présentation

Distributed Systems

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

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

  2. Outline 1 Location Transparency 2 Naming 3 Trading 4 Object Lifecycle 5 Summary

  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. 2 Naming 1 Naming Service Examples 2 Common Characteristics 3 CORBA Naming Service 4 Limitations

  5. uac usr lec cprj bin lyu sbin csc5110 ls rlogin teaching www web inetd 2.1 NFS Directories

  6. DUA DSA DSA DSA DUA DSA DSA DUA DSA 2.1 X.500 Service Architecture

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

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

  9. a.root-servers.net (root) ns1.cuhk.edu.hk 137.189.6.1 (edu.hk) ns1.cs.ucl.ac.uk (ac.uk) edu.hk ac.uk ie.cuhk.edu.hk cse.cuhk.edu.hk ic.ac.uk qmw.ac.uk city.ac.uk beryl.cuhk.edu.hk 137.189.91.187 (cse.cuhk.edu.hk) nameserv.city.ac.uk (city.ac.uk) *.city.ac.uk *.cse.cuhk.edu.hk 2.1 Internet Domain Name Service

  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. 2.2 Common Characteristics Qualities of service: • Distribution of name spaces • Performance profile • Caching • Replication • Transaction properties of naming operations

  12. Application Objects CORBAfacilities Object Request Broker CORBAservices 2.3 CORBA Architecture

  13. Application Objects CORBAfacilities Object Request Broker CORBAservices Naming 2.3 CORBA Naming Service

  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. UEFA England Germany Cup Winners First 2. Liga 1. Liga Premier Lautern Manchester United Bochum QPR South End United 1.FC Kaiserslautern Man United Bayern BVB Chelsea 2.3 Naming Contexts

  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. 2.3. IDL Types for Names moduleCosNaming { typedef string Istring; struct NameComponent { Istring id; Istring kind; }; typedef sequence <NameComponent> Name; ... };

  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. 2.3. Excerpt of IDL Interface 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); };

  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. 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 << t->print();

  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. 3 Trading 1 Characteristics 2 Example 3 OMG/CORBA Trading Service

  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. 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. 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. Server Video-on- demand provider MGM User Warner Trader Independent 3.2 Example • Distributed system for video-on-demand:

  28. Application Objects CORBAfacilities Object Request Broker CORBAservices Trading 3.3 CORBA Trading Service

  29. Trader (2) Lookup (2a) Monitor QoS (1) Register Client Server (3) Application 3.3 OMG Trading Service

  30. 3.3 Properties Specify qualities of service: typedef Istring PropertyName; typedef sequence<PropertyName> PropertyNameSeq; typedef any PropertyValue; struct Property { PropertyName name; PropertyValue value; }; typedef sequence<Property> PropertySeq; enum HowManyProps {none, some, all}; union SpecifiedProps switch (HowManyProps) { case some : PropertyNameSeq prop_names; };

  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. 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. 4 CORBA Lifecycle Service Application Objects CORBAfacilities Object Request Broker CORBAservices Lifecycle

  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. 4.1 The Object Lifecycle copy move available unavailable create delete

  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. 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. 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. 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. 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. 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. 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. 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. 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.

More Related