Title: Distributed Systems
1Distributed Systems
- Session 7 Naming and Trading
- Christos Kloukinas
- Dept. of Computing
- City University London
20.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
30.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
4Outline
- 1 Location Transparency A reminder
- 2 Naming
- 3 Trading
- 4 Summary
51 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.
62 Naming
- 1 Naming Service Examples
- 2 Common Characteristics
- 3 CORBA Naming Service
- 4 Limitations
72.1 NFS Directories
home
usr
jam
bin
ed
sbin
lpr
web
rlogin
teaching
www
papers
inetd
82.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.
92.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)
...
...
102.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.
112.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)
122.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.
132.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.
142.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.
152.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.
162.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
172.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").
182.3. IDL Types for Names
- module CosNaming
- typedef string Istring
- struct NameComponent
- Istring id
- Istring kind
-
- typedef sequence ltNameComponentgt Name
- ...
192.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.
202.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)
212.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.
222.3. Binding Iterator
- interface BindingIterator
- boolean next_one(out Binding b)
- boolean next_n(in unsigned long how_many,
- out BindingList bl)
- void destroy()
232.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.
24Client/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
25Server Side Creating A Name Space
262.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
27Creating 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
282.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
29Client 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
302.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.
313 Trading
- 1 Characteristics
- 2 Example
- 3 OMG/CORBA Trading Service
323.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
333.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.
343.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.
353.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
363.3 CORBA Trading Service
Application Objects
CORBAfacilities
Object Request Broker
CORBAservices
Trading
373.3 OMG Trading Service
(2) Lookup
(2a) Monitor QoS
(1) Register
(3) Application
383.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
-
393.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.
403.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 (...)
-
-
413.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.
423.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 (...)
-
433.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.
444 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.
45Reading
- Emmerich Chapter 8
- CDK94 Chapter 9. Name Services.
- OMG96a Object Management Group The Naming
Service. - OMG96b Object Management Group The Trading
Object Service.