Distributed Systems

1
Distributed Systems

• Session 7 Naming and Trading
• Christos Kloukinas
• Dept. of Computing
• City University London

2
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

3
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

4
Outline

• 1 Location Transparency A reminder
• 2 Naming
• 3 Trading
• 4 Summary

5
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 objects location. Plus,
• Naming supports the definition of external names
  for components.
• Trading supports the definition of service
  characteristics for a component with a trader.

6
2 Naming

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

7
2.1 NFS Directories
home
usr
jam
bin
ed
sbin
lpr
web
rlogin
teaching
www
papers
inetd
8
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.

9
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)
...
...
Michael Schroeder (person)
George Spanoudakis (person)
...
...
10
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.

11
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)
12
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 Citys
  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.

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

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

16
2.3 Naming Contexts Leafsobject names,
non-leafscontext 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
17
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").

18
2.3. IDL Types for Names

• module CosNaming
• typedef string Istring
• struct NameComponent
• Istring id
• Istring kind
• typedef sequence ltNameComponentgt Name
• ...

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

20
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()
• NamingContext bind_new_context(in Name n)
• raises (NotFound, ...)
• void list(in unsigned long how_many,
• out BindingList bl,
• out BindingIterator bi)

21
2.3. Naming Context (ctd.)

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

22
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()

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

24
Client/Server Naming Scenario
Namespace
2. Name Server
ltName_1,object1gt
ltName_2,object2gt
ltName_N,object_Ngt
Client
Server
3. resolve(name)
1. bind(name,object_ref)
4. Invoke Service
25
Server Side Creating A Name Space
26
2.3 Naming Contexts Leafsobject names,
non-leafscontext 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
27
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
28
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 tTeamHelper.narrow(root.resolve(name))
• 4. t.print()

Casting
29
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
30
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.

31
3 Trading

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

32
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

33
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 quality of services 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.

34
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.
• Service matching 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.
• Service shopping The trader returns the list to
  the client. Client selects the most appropriate
  server.

35
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
36
3.3 CORBA Trading Service
Application Objects
CORBAfacilities
Object Request Broker
CORBAservices
Trading
37
3.3 OMG Trading Service
(2) Lookup
(2a) Monitor QoS
(1) Register
(3) Application
38
3.3 Properties

• Specify qualities of service
• typedef Istring PropertyName
• typedef sequenceltPropertyNamegt PropertyNameSeq
• typedef any PropertyValue
• struct Property
• PropertyName name
• PropertyValue value
• typedef sequenceltPropertygt PropertySeq
• enum HowManyProps none, some, all
• union SpecifiedProps switch (HowManyProps)
• case some PropertyNameSeq prop_names

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

40
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 (...)

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

42
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 (...)

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

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

45
Reading

• Emmerich Chapter 8
• CDK94 Chapter 9. Name Services.
• OMG96a Object Management Group The Naming
  Service.
• OMG96b Object Management Group The Trading
  Object Service.