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

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

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

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

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

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

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

© Chinese University, CSE Dept. Distributed Systems / 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 uid lyu mail roomNumber Engineering Building 927 userClass Professor

© Chinese University, CSE Dept. Distributed Systems / 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 (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 (cse.cuhk.edu.hk)

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

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

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

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

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

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

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

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

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

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

© Chinese University, CSE Dept. Distributed Systems / 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(); }

© Chinese University, CSE Dept. Distributed Systems / 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();

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

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

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

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

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

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

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

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

© Chinese University, CSE Dept. Distributed Systems / 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; };

© Chinese University, CSE Dept. Distributed Systems / 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 (...); };

© Chinese University, CSE Dept. Distributed Systems / 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 (...); };

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

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

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

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

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

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

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

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

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

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

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

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