Distributed Systems

Distributed Systems Session 7: Naming and Trading Christos Kloukinas Dept. of Computing City University London

0.0 Last session • TWO Practical Aspects to developing Applications in CORBA • Programming language bindings e.g JAVA/IDL • Why Standardisations of bindings is important • Facilitate Portability, • Decreases the learning curve of developers • CORBA Lifecycle Service • Introduced the problem distributed object lifecycle and noted that component creation is complicated in distributed systems • Talked about Factory objects, and how the create object and hence facilitate location transparency • Factory finders, and CORBA FactoryFinder interface

0.1 Last session Cont.. • Costly to create Factory interface for each object type • Motivated the need for generic factory • CORBA GenericFactory to support object creation • LifecycleObject interface supports object • Duplication,Deletion, Migration • Noted that (Standard) Replication support is Missing in CORBA • Would be desirable for Load balancing and fault tolerance

Outline 1 Location Transparency: A reminder 2 Naming 3 Trading 4 Summary

1 Location Transparency • The location transparency principle suggests to keep the physical location of components transparent for both, the component itself and all clients of the component. Only then can the component be migrated to other servers without having to change the components or its clients. • In the CORBA framework, location transparency is already supported by the fact that objects are identified by object references, which are independent of the object’s location. Plus, • Naming supports the definition of external names for components. • Trading supports the definition of service characteristics for a component with a trader.

2 Naming 1 Naming Service Examples 2 Common Characteristics 3 CORBA Naming Service 4 Limitations

2.1 NFS Directories home usr jam bin ed sbin lpr web rlogin teaching www papers inetd

2.1 NFS Directories (ctd.) • NFS is based on directories. Directories include a number of name bindings, each of which maps a name to a file or a subdirectory. • Names are unique within the scope of the directory and can be composed to path names by delimiting the name components using a '/'. • Every file or directory of the file system must have at least one entry in some directory. If the last binding is removed the file or the directory ceases to exist. NO NAME, NO LIFE! • A file or directory can have more than one name. An example is the directory that is shared by users ‘ed’ and ‘jam’. In ‘ed’ home directory that directory has the name 'web' while user ‘jam’ has given it the name 'www'. • The naming scheme for files in the NFS supports location transparency because now files can be identified using pathnames rather than physical addresses (such as the hard-disk drive names C:) or the IP address of the server machine to which a partition of the file system is connected.

2.1 X.500 Directory Service X.500 Service (root) Germany (country) United Kingdom (country) Greece (country) ... ... ... British Airways Plc. (organization) City University (organization) ... ... SOI (organizationalUnit) SOE (organizationalUnit) ... ... CSR (organizationalUnit) CS (organizationalUnit) ... ... George Spanoudakis (person) Michael Schroeder (person) ...

2.1 X.500 Directory Service • The X.500 Directory Service is an recommendation of the International Telecommunication Union (ITU) formerly known as CCITT. • X.500 defines a global name space and it is therefore the basis for component identification in wide area networks, while the network file system is merely used in local area network. • X.500 defines a directory tree and components can have only one name. Having a name is not existential for a component and there may well be subordinate components that are not named but can be identified otherwise. • X.500 directory service entries not only have a name, but also a role attribute, given in brackets. In file systems these roles are sometimes indicated informally by using file name extensions, such as '.cc' for a C++ file or '.doc' for a word processor document.

de ac.uk uni-dortmund.de uni-paderborn.de ic.ac.uk qmw.ac.uk city.ac.uk *.uni-paderborn.de *.city.ac.uk 2.1 Internet Domain Name Service ns.nasa.gov (root) dns.germany.eu.net (de) ns1.cs.ucl.ac.uk (ac.uk) nameserv.city.ac.uk (city.ac.uk) uni-paderborn.de (uni-paderborn.de)

2.1 Internet Domain Name Service • Another global name service that has become very prominent recently is the Internet Domain Name Service (DNS). The root of DNS is maintained by a machine called ns.nasa.gov that is operated by the US space agency NASA. • Each DNS node maintains a table with domains of which it knows the name servers. The root node, for instance would have entries identifying the domains '.de' and '.ac.uk' representing Germany and all academic sites in the UK. • A name lookup performed by a machine of City’s local network of a machine in the network of 'uni-paderborn.de' would then first be performed by nameserv.city.ac.uk. If that name server could not resolve the binding, it would ask the next higher level name server and so on until it gets to the root.

2.2 Common Characteristics • All the naming services we looked at include the concept of external names that can be defined for distributed components, be they file names, names of organizations or Internet domain names. • All names are defined within the scope of hierarchically organised name spaces. These are directories in NFS or the X.500 directory tree or name servers in the Internet. • All naming services provide two fundamental operations to define and lookup names. The operation that defines a new name is usually referred to as 'bind', while the operation that searches for a component is commonly denoted as 'resolve'. • Moreover, the name bindings are stored persistently by the name servers. Directory and file names are stored as part of the file system on disks. Directory entries in X.500 are stored persistently by the respective servers and the Internet domain name servers store name bindings persistently in configuration databases.

2.3 CORBA Naming Service Application Objects CORBAfacilities Object Request Broker CORBAservices Naming The CORBA Naming service was defined in 1993 as the very first CORBA service. The purpose of the CORBA Naming service is to provide a basic mechanism by means of which external names can be defined for CORBA objects references.

2.3 Introduction • Names are hierarchically organised in so called naming contexts. Name bindings have to be unique within the context (i.e., no other name binding with the same name occurs in the context) . However, one object can have different names in the same context or even the same name within different contexts. • Note, that it is not necessary to bind a name to every CORBA object, thus name bindings are not existential for CORBA objects (opposed to file names in NFS). Other ways how objects can be located include: • Accesses of attributes whose type is a subtype of Object. • Executing operations whose result is a subtype of Object. • Using the CORBA Trading service. • Using CORBA Query or Relationship facilities.

2.3 Naming Contexts Leafs=object names, non-leafs=context names UEFA England Spain Cup Winners First 2. Liga 1. Liga Premier Madrid Manchester United Eibar Alaves QPR South End United Man United Bilbao 1.FC Alaves Chelsea

2.3. CORBA Names • Names in the CORBA naming service are sequences of simple names. They are composed in a similar way as path names in NFS, as sequences of a number of directory names and a file name. • A simple name is a (value, kind) tuple. (à la X.500) • Only the value component is used for resolving the name. • The kind attribute is used to store and provide additional information about the role that an object or naming context has. • A simple name in the above example would be ("Chelsea","Club") or ("England","League"), while the composite name identifying Athletic Bilbao within the context of the UEFA would consist of: {(”Spain",”1. Liga"),”Bilbao","Club")}.

2.3. IDL Types for Names moduleCosNaming { typedef string Istring; struct NameComponent { Istring id; Istring kind; }; typedef sequence <NameComponent> Name; ... };

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. • BindingInterator defines operations to iterate over a set of names defined in a naming context. An iterator is an object that can be used to enumerate over a collection of objects and visit single elements or chunks of these objects successively.

2.3. Naming Context 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(); NamingContextbind_new_context(in Name n) raises (NotFound, ...) void list(in unsigned long how_many, out BindingList bl, out BindingIterator bi); };

2.3. Naming Context (ctd.) • Operation bindcreates a name binding in the naming context identified by the naming context that executes the operation and all name components but the last included in the first parameter n. In that naming context bind inserts a name that equals the last name component and associates it to obj. • Operation resolvereturns the object that is identified by the naming context by the executing naming context and the name n. If there is no such name binding in that context, exception NotFound will be raised. • Operation unbinddeletes the name binding identified by the executing naming context and name n. • Operations new_context and bind_new_contextcreate new naming context objects. the latter operation also creates a name binding as identified by the name n. • Operation list is used to obtain all name bindings in the naming context. Parameter how_many obtains an upper bound for the number of name bindings that are to be included in the out parameter bl. If there are more bindings than how_many in the naming context a binding iterator will be created and returned as out parameter bi.

2.3. Binding Iterator interface BindingIterator { boolean next_one(out Binding b); boolean next_n(in unsigned long how_many, out BindingList bl); void destroy(); }

2.3. Binding Iterator (ctd.) • Operations provided by BindingIterator will be used after list has been executed on a naming context. They will then provide successive bindings that were not included in the BindingList returned by list. • Operation next_one returns just one binding while operation next_n returns as many bindings as the client requests through the in parameter how_many. • Both operations have a return value that indicates whether there are further bindings available in the context that have not yet been obtained.

ORB ORB ORB Client/Server Naming Scenario Namespace 2. Name Server <Name_1,object1> <Name_2,object2> <Name_N,object_N> Client Server 3. resolve(name) 1. bind(name,object_ref) 4. Invoke Service

ORB ORB.init(args,null); 1. org.omg.CORBA.Object objRef= org.omg.CORBA.resolve_initial_references("NameService"); NamingContext rootContext= NamingContextHelper.narrow(objRef); NameComponent comp1[]={new NameComponent(“UEFA”,”ORG”)} 2. NamingContext uefaContext = rootContext.bind_new_context(comp1); NameComponent comp2[]={new NameComponent(“England”,”Country”)}; 3. NamingContext englandContext= uefaContext.bind_new_context(comp2); NameComponent comp3[]={new NameComponent(“Premier”,”League”)}; 4. NamingContext premierContext = englandContext.bind_new_context(comp3); NameComponent name[0]={new NameComponent(“Arsenal”,”Club”)} 5. premierContext.bind(name,arsenalRef); Server Side: Creating A Name Space

2.3 Naming Contexts Leafs=object names, non-leafs=context names UEFA England Spain Cup Winners First 2. Liga 1. Liga Premier Madrid Manchester United Eibar Alaves QPR South End United Man United Bilbao 1.FC Alaves Chelsea

Creating Name Space Scenario Application RootContext ORB uefaContext 1. Resolve_initial_references englandContext 2. Bind_new_context premierContext 3. Bind_new_context Arsenal 4. Bind_new_context 5. Bind Server Application Name Server

2.3. Example: Client Finding Objects ORB ORB.init(args,null); 1. org.omg.CORBA.Object objRef= org.omg.CORBA.resolve_initial_references ("NameService"); CosNaming.NamingContext root= CosNaming.NamingContextHelper.narrow(objRef); 2. CosNaming.NameComponent name[] = { new NameComponent(“UEFA”,”ORG”), new NameComponent(“England”,”Country”), new NameComponent(“Premier”,”League”), new NameComponent(“Arsenal”,”Club”)} 3. Team t=TeamHelper.narrow(root.resolve(name)); 4. t.print(); Casting

Client: Finding Objects Scenario Root Client ORB Arsenal 1. Resolve_initial_references 2.Create name 3. Resolve Object Reference 4.Invoke method Client Premier Server Name Server

2.4 Limitations • Limitation of Naming: Client always has to identify the server by name. White Pages • Inappropriate if client just wants to use a service at a certain quality but does not know from whom: • Automatic cinema ticketing; • Video on demand; • Electronic commerce.

3 Trading 1 Characteristics 2 Example 3 OMG/CORBA Trading Service

3.1 Trading Characteristics • The principle idea of a trading service: Have a mediator that acts as a broker between clients and servers. • This broker enables a client to change its perspective when it tries to locate a server component from: • locating individual server components (`WHO` is the server that you are interested in? – i.e., White Pages) • to the set of services the client is interested in (`WHAT` are the services that you need? – i.e., Yellow Pages). • The broker then selects a suitable service provider on behalf of the client. • Other examples: yellow pages, insurance & stock Brokers

3.1 Trading Characteristics • Language for expressing types of services that both client and server understand. • Language expressive enough to define the different types and qualityofservices that a server offers or that a client may wish to use • performance, reliability or privacy. • The quality of service may be defined statically or dynamically. • A static definition is appropriate (because it is simpler) if the quality of service is independent of the state of the server. • This might be the case for qualities such as precision, privacy or reliability. • For qualities such as performance, however, the server may not be able to ensure a particular quality of service statically at the time it registers the service with the trader. • Then a dynamic definition of the quality would be used that would make the trading service inquire about the quality when a client needs to know it.

3.1 Trading Characteristics: Steps 1. SERVERS have to register the services they offer with the trader. • trader is then in a position to respond to service inquiries from clients. 2. CLIENTS then use common language to ask the trader for a server that provides the type of service the client is interested in. • Clients may or may not include specifications of the quality of service that they expect the server to provide. 3.a TRADER then reacts to such an inquiry of clients in different ways. • Servicematching: The trader may itself attempt to match the clients request with the best offer and just return the identification of a single server that provides the service with the intended quality. 3.b TRADER may also compile a list of those servers that offer a service which matches the clients request. • Serviceshopping: The trader returns the list to the client. Client selects the most appropriate server.

MGM Warner Trader Independent 3.2 Example • Distributed system for video-on-demand: Server Video-on- demand provider Lookup(“matrix, 1024x768) User Register(Title, Qos) Films of different formats, resolutions, size

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

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

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; };

3.3 Properties (ctd.) • A property is a name value structure, where a property name is a string and a property value can be any type. • The type Property could be used to specify, for instance, response time by setting the name to the string response_time and the value to 0.1 (seconds). • As services usually have more than one property, the type PropertySeq can be used to declare all the properties that a service has. • Type SpecifiedProps is a variant record (union) that is used by clients to tell the trader about those properties they expect a service to have. If the discriminator of the variant is set to none the clients does not care about the properties a service has, if it is set to all the client expects the service to meet all properties and if it is set to some the component prop_names specifies a sequence of properties that the client is expecting.

3.3 Register Trader interface for servers: interface Register { OfferId export(in Object reference, in ServiceTypeName type, in PropertySeq properties) raises(...); OfferId withdraw(in OfferId id) raises(...); void modify(in OfferId id, in PropertyNameSeq del_list, in PropertySeq modify_list) raises (...); };

3.3 Register (ctd.) • The operation export is used by the server to make a new service known to the trader. As arguments it passes an object reference to the object that implements the service, a string denoting the service name and the properties defining the qualities of that service. The export operation returns a unique identifier for the offer which is used for referring to the offer in other operations. • By invoking operation withdraw a server deletes the service identified by the offer identifier. • Using operation modify, the server can dynamically change the qualities of service the trader advertises. Again the service is identified by the offer identifier passed as the first parameter. The properties named in the second parameter are deleted and the properties identified in the last parameter change their value.

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

3.3 Lookup (ctd.) • The most important parameter of the query operation is the name of the service the clients is interested in. Parameter pref identifies whether the clients want the trader to do service matching or whether the clients want to do service shopping for the servers implementing some service. Parameter desired_props identifies the qualities of service the client wants the server to guarantee. The usual iterator pattern is applied to pass the matching servers through the out parameter offers.

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

Reading [Emmerich] Chapter 8 [CDK94] Chapter 9. Name Services. [OMG96a] Object Management Group: The Naming Service. [OMG96b] Object Management Group: The Trading Object Service.

Distributed Systems