Distributed Systems

Distributed Systems

Week 7: Naming and Trading Dr. Wolfgang Emmerich Dept. of Computer Science The City University

© City University, Dept. of Computer Science

Distributed Systems / 7 - 1

•Last week we have discussed genericity and interoperability in the CORBA framework. •This week we are going to look at the question: How can we find distributed components in a location transparent way? •We are going to review naming and trading, two well-known techniques. •Naming is concerned with defining external names for components so that the components can be identified by a name server by means of the external name. This approach is very much the same as the identification of participants of the telephone network by means of the white pages. In the white pages a telephone number (an identifier for the network participant) can be looked up given the name of a person or company. In order to do so, network participants have to register themselves in the directory. •Trading is concerned with locating components based on the services the component has to offer. This approach is very much the same as the identification of company phone numbers based on the yellow pages. In there the phone numbers of companies are organised around the services that the companies have to offer. In order to do so, companies have to register themselves with the yellow page publisher.

City University, Dept. of Computer Science, Distributed Systems

7-1

Outline 1 Location Transparency 2 Naming 3 Trading 4 Summary



•In this week´s lecture, we are going to start with a review of location transparency. •We are then going to review different name services, such as directories in the network file system, the internet domain service and the X.400 directory service. We are then going to discuss the CORBA name service in more detail. •In the third part, we shall discuss trading as a technique to register and identify components by the set of services they offer. •As usual, a summary indicates what you should remember from this week´s lecture and gives a list of references to background reading.


7-2

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



•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. •This means that we have to avoid using physical locations for identifying components. •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. If a client posesses a reference to a server object, the client is able to invoke any operations from the server. •Naming supports the definition of external names for components. Then clients of a component that know the external name can locate the component. •Trading supports the definition of service characteristics for a component with a trader. Then clients can ask the trader to identify those components that provide the type of service the client is interested in.


7-3

2 Naming

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



•For the discussion of naming, we are going to review a number of name servers that you almost certainly have used already. These are the network file system, the X.400 directory service (which your bank will use) and the Internet domain service. •We are then going to destill the common characteristics of these name servers. Knowledge of these characteristics will prove very useful for the design and the assessment of any naming service. •After that we are going to review the CORBA Naming Service. It supports the definition of external names for object references within certain contexts. •The assessment of the CORBA Naming Service reveals a number of limitations, which motivate the need for the trading service as another service that is used for identifying components.


7-4

2.1 NFS Directories home

bin

lpr

ww w

tea ch ing

inetd

rlogin

rs pape

web


sbin

gespan

h ric e m em

usr


•A naming service that every student taking this course has already used is part of the network file system (NFS). This slide presents a subset of the departmental NFS. •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 they are used to identify the file or the directory they refer to. •Names can be composed to path names by delimiting the name components using a '/'. These composite path names identify files or directories in exactly the same way as simple names. •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. •A file or directory can have more than one name. An example is the directory that is shared by users 'emmerich' and 'gespan'. In emmerich's home directory that directory has the name 'web' while user gespan 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. •Location is only visible for administrators, who have to mount partitions of the file system from remote servers. While doing so, they attach these remote partitions to local directories. City University, Dept. of Computer Science, Distributed Systems

7-5

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)

... ...

Wolfgang Emmerich (person) ...



•The X.500 Directory Service is an recommendation of the International Telecommunication Union (ITU) formerly known as CCITT) and X.500 is heavily used by the telecommunication industry. •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. The attributes explicitly define the roles components play. 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.


7-6

2.1 Internet Domain Name Service dns.germany.eu.net (de)

ns.nasa.gov (root)

uni-dortmund.de uni-paderborn.de

uni-paderborn.de (uni-paderborn.de) *.uni-paderborn.de © City University, Dept. of Computer Science

de ac.uk

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


•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. The name server for academic sites in the UK is a server operated by the University College in London and that would know the different name servers serving the different local area networks of universities in the UK. As such it would have an entry for City´s server that is operated by the Computing Services Department. This name server would then know all machines in this university. •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. The root would know the name server for the domain '.de' and ask that name server for the name server of the subdomain 'uni-paderborn.de'. •The power of DNS lies in the fact that it performs replication and caching of name bindings. Thus once a name binding is found, it will be cached on all name servers that were involved in the search. In most cases, therefore, the root name server would not be involved since local name servers already know to which name servers to talk to in order to resolve a name binding. City University, Dept. of Computer Science, Distributed Systems

7-7

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.



•All the naming services we looked at include the concept of external names that can be defined for distributed for 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.


7-8

2.2 Common Characteristics Qualities of service: ♦ Distribution of name spaces ♦ Performance profile » Caching » Replication

♦ Transaction properties of naming operations



•The implementation of the different naming services also have to choose from a common portfolio of qualities of services. •The naming services can be regarded as distributed systems themselves and a such they are subject to the various properties and principles that we have discussed in the first week's session. •In order to avoid slowing down applications, the naming services have to achieve a decent performance profile. This is usually done by trading the performance of the bind and resolve operations against each other. In some naming services, such as the Internet DNS or the X.500 service, it does not happen very often that a new component is given a name. The performance of bind is, therefore, less important and is often traded against an improvement of the lookup performance. In these cases caching and replication may be used to speed up the lookup. •Finally, it has to be decided whether the lookup and bind operations have all or some of the transaction properties so that are atomic and/or isolated against concurrent naming operations.


7-9

2.3 CORBA Naming Service

Application Objects

CORBA facilities

Object Request Broker

Naming

CORBA services



•We are now going to study the CORBA Naming service in detail in order to review how these common characteristics are applied in the CORBA framework. •The CORBA Naming service was defined in 1993 as the very first CORBAservice. •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.


7-10

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.



•The CORBA naming service supports binding names to CORBA object references. •The name bindings included in the naming service may well be for objects that are served by different servers. The name service thus supports location transparency since different servers can create bindings on a common name server and all distributed objects resolve names using that server. •Names are hierarchically organised in so called naming contexts. Name bindings have to be unique within the context. •Aliasing is supported by the naming service since 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 (see below). •Using the CORBA Query or Relationship services (not further considered in this module).


7-11

2.3 Naming Contexts UEFA

QPR

M Un an ited

1. Ka FC ise rsl au ter n

Boc hum

ea els Ch

1. Li ga


Fir st

d En uth So ited Un

Manchester United

tern Lau

n yer Ba

BV B

Cup rs e Winn

2. Lig a

Premier

Engla nd

ny Germa


•This slide displays how the CORBA naming service is deployed to obtain references of teams representing soccer teams (that might be used in the soccer team management application we discussed in the fifth week. •The grey circles represent hierarchically organised naming contexts representing different national and european leagues. These naming contexts are included in a naming context for the european soccer organisation UEFA. •The white circles represent different teams playing in the leagues. Note that some teams play in more than one league. Manchester United, for instance, is playing in the Cup Winners Cup and in the English Premiership. •Names in this example are given as annotation to the arrows that indicate in which naming context a certain name binding is defined.


7-12

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.



•Names in the CORBA naming service are sequences of simple names. They are composed in a similar way as path names in NFS are sequences of a number of directory names and a file name. •A simple name is a (name, kind) tuple. •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 BV Borussia Dortmund within the context of the UEFA would consist of: {("Germany","Leage"),"BVB","Club")}.


7-13

2.3. IDL Types for Names module CosNaming { typedef string Istring; struct NameComponent { Istring id; Istring kind; }; typedef sequence Name; ... }; © City University, Dept. of Computer Science


•This slide shows the IDL type definition for names. •A name is a sequence of name components. •Each name component is a record consisting of an id and a kind attribute. •The types of these attributes are strings.


7-14

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. © City University, Dept. of Computer Science


•The Naming service includes two IDL interfaces: NamingContext and BindingIterator. •The two main operations provided by interface NamingContext facilitate the binding of names to objects and the resolution of name bindings to obtain the objects they refer to. •The Naming service also supports the enumeration of names within a given context. For this purpose the iterator design pattern identified in [GHJV94] is used. 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. The Naming service includes the BindingIterator interface that iterates successively over the name bindings included in a particular naming context.


7-15

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); }; © City University, Dept. of Computer Science


•This slide shows some operations defined in the NamingContext interface. •Operation bind creates 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 resolve returns 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 unbind deletes the name binding identified by the executing naming context and name n. •Operations new_context and bind_new_context create 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.


7-16

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



•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. •It is interesting to review why the binding iterator provides the operation next_n, while every binding could be obtained thrugh next_one as well. The motivation lies in the distributed nature of these name binding operations. They are still remote operations whose execution is rather expensive. The execution of next_n will take more or less the same time as the execution of next_one while next_n enables the client to obtain multiple name bindings. Hence this is an example where the distributed setting in which the naming service will be used had an influence on the design of the interfaces to the naming context.


7-17

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(); © City University, Dept. of Computer Science


•Let us now review how a client would use the naming service to obtain an object reference. This slide shows a client that is constructed using the C++ language binding. •The example displays how a client uses the naming service to obtain the object reference of the object representing the Arsenal soccer team. •The first statement obtains an object reference to the root naming context by means of the initialisation operations provided by the basic object adapter. This operation provides an object reference of type Object and we have to use a narrow operation in order to achieve a safe type cast to NamingContext. •We then create a new name object. It will be a list with four elements and we initialise the id attributes of the name components of that list with the name components on the path from the root naming context to the naming context for the premiership. The last name component is the name of the Arsenal soccer team. •After that we can use the resolve operation to obtain an object reference to the arsenal team object. Again this object reference will be of type Object and we will have to cast it using the narrow operation. •Finallly, we can use the print operation that is defined for team objects in order to obtain a printed representation of the team members.


7-18

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.



•With naming, we have now seen one technique by means of which client components can identify server components. •Naming is useful if the client component exactly knows from which server component it wants to invoke a certain service. •Naming, however, is not appropriate if a client knows which type of service it wants to use but does not know (and does not have to know) the server component. There are various examples of these situations: •A distributed cinema ticketing system with which clients specify which movie they want to see with which quality of service (area of cinema, size of screen, Dolby Surround etc.) but the detailed cinema or even the seats are not necessarily important. •A video on demand server where clients specify the film they want to rent but do not care from which video provider they obtain the films. •An electronic commerce system that supports trade in shares where clients specify which shares to sell or buy but do not care about the stock exchange selected for the deal. •In all these situations clients do not need to know the server component that provides the service, but only negotiate with a trader component that operates on the clients' behalf. •We are now going to look at a trading service, that has been specified to be useful in the situations sketched above.


7-19

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



•To discuss trading, we are going to review the common characteristics of trading systems first. •We then explain these characteristics on the basis of an example, a video on demand server. •Finally, we are going to have a closer look at the trading approach supported by CORBA.


7-20

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. © City University, Dept. of Computer Science


•Trading is another primitive to locate components in a location transparent way. •The principle idea of a trading service is to have a mediator that acts as a broker between clients and servers. •This broker enables clients to change its perspective when it tries to locate a server component from locating individual server components (who is the server that can help me?) to the set of services the client is interested in (what server offers the services that I need?). •The broker then selects a suitable service provider on behalf of the client. •The idea is not restricted to distributed systems, but is found as well in other (non computerised) systems. A good example are the yellow pages. Service providers, such as plumbers or lawyers, register with the publisher of the yellow pages. Clients who wish to use a particular service can then lookup the yellow pages by service providers to find a provider that offers the required service. •Other examples similar to the yellow pages are stock brokers and insurance brokers.


7-21

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.



•There has to be a language for expressing types of services that both client and server understand. •This language has to be expressive enough to define the different types of services that a server offers or that a client may wish to use. •Moreover, the language has to be expressive enough so that clients can ask for certain degrees of quality of a service, such as performance, reliability or privacy. Servers would use the expressiveness of the language in order to advertise the quality of their services. •In order to enable a trading service to act as a broker between clients and servers, the servers have to register the services they offer with the trader. They use the above language to declare the types of services they offer and their qualities during the registration. •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 enquire about the quality when a client needs to know it.


7-22

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



•After servers have registered the types of services they offer with the trader, the trader is in a position to respond to service enquiries from clients. The situation is similar to that the yellow pages have been published. •A Client would then use the 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. •The trader then reacts to such an enquiry of clients in different ways. 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. This technique is known as service matching. •The trader may also compile a list of those servers that offer a service which matches the clients request. The trader would then return that list to the client in order to enable the client to select the most appropriate server itself. This technique is known as service shopping.


7-23

3.2 Example ♦ Distributed system for video-on-demand: Server MGM Warner

Video-ondemand provider

User

Trader

Independent



•As an example, let us consider a distributed system for video-on-demand. •Users in such a system would be interested in watching certain films on video. Users are not interested in which company has published a film and where they can obtain an electronic copy they want to watch. Users would therefore use a client component that connects to a trader running on a machine of a video-on-demand provider. •Film publishers, such as MGM and Warner, as well as independent companies would run video server components where electronic copies of films in different formats are stored to be downloaded. The different formats imply different qualities of service. High-resolution formats take longer to download but are nicer to watch. •The video server components would register the titles they offer as different service types with the trader of the video-on-demand server. They would specify resolution and size (aka download time) as quality of service information. •When a user wants to watch a particular video, the respective client component on the user´s workstation would enquire at the video-ondemand server for video servers that keep an electronic copy of that video. The client may add a quality of service specification to identify a certain resolution (say 1024x768 and 256 colours). •With service matching, the video-on-demand server would return the identification of a server that provides the video in the required resolution. With service shopping, the video-on-demand server would return a list of servers that have the video in the requested (or a better) resolution. City University, Dept. of Computer Science, Distributed Systems

7-24

3.3 CORBA Trading Service

Application Objects

CORBA facilities

Object Request Broker

Trading

CORBA services



•We are now going to study the CORBA Trading service in detail in order to review how these common characteristics are applied in the CORBA framework. •The CORBA Trading service was defined in 1996 as one of the last CORBAservices. To date, there are hardly any implementations for it and it will take two or three years before implementations will be widely available. •The purpose of the CORBA Trading service is to provide a basic mechanism by means of which CORBA objects references can be found based on the services the object offers.


7-25

3.3 OMG Trading Service Trader

(2)

(2a )M on ito r

p ku o Lo

(1) Re gis ter Qo S

Client (3) Application


Server


•There are three principle components involved in the application of the CORBA trading service: server, client and trader. These components participate in three steps during trading. •In the first step, the server registers its services with the trader using a registration interface exported by the trader. While doing so it specifies the services and the properties of these services. •After that, clients can lookup services using a lookup interface offered by the trader. If qualities of services are specified dynamically by the server the trader will invoke operations from the server to monitor the quality of services at run-time. •Once the client has obtained an object reference of a server from the trader, the client can use the object reference to apply the server´s services.


7-26

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; }; © City University, Dept. of Computer Science


•This slide shows a number of IDL types that are used to specify properties, i.e. qualities of services. •A property is a name value paper, 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 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. •Note, how clients and servers use a common language to agree on properties. The trading only works if both clients and server have the same understanding on the semantics of the different properties.


7-27

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 (...); }; © City University, Dept. of Computer Science


•This slide shows the interface the trader offers to enable server components to register their services. •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 (usually a reference to the server object itself), 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 refering 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.


7-28

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 (...); }; © City University, Dept. of Computer Science


•An excerpt of the Lookup interface of the trader that clients use to enquire about a certain service is displayed in this slide. •The most important parameter of the query operation displayed above is the name of the service the clients is interested in. Parameter pref identifies whether the clients wants the trader to match the service or whether the client wants to shop for the servers implementing the desired 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.


7-29

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. © City University, Dept. of Computer Science


•In summary we have seen that location transparency requires other forms of identifying components than physical addresses. We have seen two basic techniques to locate servers: naming and trading. •Naming services, such as the Internet Domain Name Service, the X.500 directory service or the CORBA Naming service map hierarchically organised names to component identifications such as IP addresses or CORBA object references. •Trading services provide an even higher level of abstraction than naming in that they use a common language between servers and clients to describe service types and their qualities. Servers register the services they offer with a trader and clients use the trader to enquire about services. Once the trader has matched a client enquiry with a service offer, clients and servers communicate privately without involvement of the trader. Hence traders usually do not impose any overhead on the communication between clients and servers, they just enable clients to find a most suitable server. •Background reading: [CDK94]

Chapter 9. Name Services.

[GHJV94]

E. Gamma, R. Helm, R. Johnson, J. Vlissides: Design Patterns - Elements of Reuseable Object-Oriented Software. Addison-Wesley. 1994.

[OMG96a]

Object Management Group: The Naming Service. http://www.omg.org/corbserv/corbser.htm#nam . 1996.

[OMG96b]

Object Management Group: The Trading Object Service Submission. OMG Document orbos/96-05-06. City University, Dept. of Computer 1996 . Science, Distributed Systems

7-30

Distributed Systems

Distributed Systems

Suggest Documents

Introduction to Distributed Systems - Distributed Systems Sistemi ...