cracking a research paper

1. X.500 More Than a Global Directory.
Introduction:-
Naming:-
A fundamental facility in any computing system is the naming service--the means by which names
are associated with objects and objects are found based on their names. When using almost any
computer program or system, you are always naming one object or another. For example, when
you use an electronic mail system, you must provide the name of the recipient to whom you want
to send mail. To access a file in the computer, you must supply its name. A naming service allows
you to look up an object given its name.
A naming service's primary function is to map people-friendly names to objects, such as addresses,
identifiers, or objects typically used by computer programs. For example, the Internet Domain
Name System (DNS) maps machine names (such as www.sun.com) to IP addresses (such as
192.9.48.5). A file system maps a filename (for example, c:binautoexec.bat) to a file handle that a
program can use to access the contents of the file. These two examples also illustrate the wide
range of scale at which naming services exist--from naming an object on the Internet to naming a
file on the local file system.
DNS Hierarchy and the Internet
The domain hierarchy shown in the following figure is a “leaf” of the huge DNS namespace
supported on the global Internet.
It consists of the root directory, represented as a dot (.), and two top level domain hierarchies, one
organizational and one geographical. Note that the com domain introduced in this figure is one of a
number of top-level organizational domains in existence on the Internet.
Hierarchy of Internet Domains
At the present time, the organizational hierarchy divides its namespace into the top-level domains
listed shown in the following table. It is probable that additional top-level organizational domains
will be added in the future.
Internet Organizational Domains
Domain Purpose

2. com Commercial organizations
edu Educational institutions
gov Government institutions
mil Military groups
net Major network support centers
org Nonprofit organizations and others
int International organizations
The geographic hierarchy assigns each country in the world a two or three-letter identifier and
provides official names for the geographic regions within each country.
For example, domains in Britain are subdomains of the uk top-level domain, Japanese domains
are subdomains of jp, and so on.
Fully Qualified Domain Names (FQDNs)
A domain name is said to be fully-qualified when it includes the names of every DNS domain from
the local domain on up to “.”, the DNS root domain. Conceptually, the fully qualified domain name
indicates the path to the root, as does the absolute path name of a UNIX file. However, fully
qualified domain names are read from lowest, on the left, to highest, on the right. Therefore, a
fully-qualified domain name has the following syntax.
 X.500 directory service.
 The X.500 directory service is a global directory service.
 Its components cooperate to manage information about objects such as countries,
organizations, people, machines, and so on in a worldwide scope.
 It provides the capability to look up information by name (a white-pages service) and to
browse and search for information (a yellow-pages service).
 The information is held in a directory information base (DIB).
 Entries in the DIB are arranged in a tree structure called the directory information tree
(DIT).
 Each entry is a named object and consists of a set of attributes.
 Each attribute has a defined attribute type and one or more values.
 The directory schema defines the mandatory and optional attributes for each class of object
(called the object class).
 Each named object may have one or more object classes associated with it.
 The X.500 namespace is hierarchical. An entry is unambiguously identified by a
distinguished name (DN).
 A distinguished name is the concatenation of selected attributes from each entry, called the
relative distinguished name (RDN), in the tree along a path leading from the root down to
the named entry.

3.  Users of the X.500 directory may (subject to access control) interrogate and modify the
entries and attributes in the DIB.
 Naming Convention
 Although the concepts of distinguished names and relative distinguished names are core to
the X.500 model, the X.500 standard itself does not define any string representation for
names.
 String names are never communicated between different implementations. Instead, they are
necessary only for interaction with end-users. For that purpose, the standard allows any
representation, not necessarily only string representations.
 Systems that are based on the X.500, such as the LDAP define its own string representation.
 For example, in the LDAP, a DN's RDNs are arranged right to left, separated by the comma
character (","). Here's an example of a name that starts with "c=us" at the top and leads to
"cn=Rosanna Lee" at the leaf.
 cn=Rosanna Lee, ou=People, o=Sun, c=us
Features:-
First feature is that it is literally global in its scope.
The second key feature is its powerful search operation.
Users access the directory through directory user agents (DUA), program which implement the
appropriate communications protocol.
Mechanism for ensuring that only authorized user access information, charged for the
information they access, and that information is secure from unauthorized change all are necessary
in any practical and global information base; the x.500 directory standards address these issues.

4. Finally, the directory adapts well to storing a variety of information about entities other than
people, and provides satisfactory performance when pressed into such services.
Some directory services provide no protection, allowing anyone to see the information. LDAP
provides a mechanism for a client to authenticate, or prove its identity to a directory server, paying
the way for rich access control to protect the information the server contains. LDAP also supports
data security (integrity and confidentiality) services.
LDAP stands for Lightweight Directory Access Protocol. As the name suggests, it is a lightweight
protocol for accessing directory services, specifically X.500-based directory services.
 Overview of x.500
X.500 specifies a directory services that provides and manages information about entities
 The entities can be people name, organization etc.
 Act as An electronic replacement for paper telephone directories.
The Directory: a collection of open systems cooperating to provide directory services;
DUA: - The client software that accesses the X.500 directory on behalf of the user. DUAs can
perform such actions as searching, reading, updating, and deleting information in the directory,
depending on the level of functionality of the client and the level of access granted to the user.

5. Fig: the basic directory service model.
 The information held by the directory is the directory information base (DIB).
 The DIB consists of entries that contain information about entities.
 Each entry consists of a set of attributes, each with a type and one or more values.
 The types of attributes that are present at each entry are dependent on the class of entities
that the entry describes.
 Class can be both predefined and user defined.
 Entries in the DIB are placed in the DIT according to the organizational relationship
between the entities that they represent.
 The x.500 abstract service definition defines abstract ports and operations that provide the
user functionality for
 Retrieving
 Searching and
 Modify directory information.
These operations from the directory access protocol (DAP). The current x.500 standard supports
the
 Read
 Compare list
 Search and
 Abandon interrogation function and
 The basic add
 Remove
 Modify entry manipulation function.
Data within the X.500 architecture is stored in Objects and Attributes. This is analogous to Tables
and Columns in database parlance or Records and Fields in file parlance.
Objects are identified by unique identification numbers called Object Ids or OIDs. Attributes are
contained within objects and represent specific data elements, such as name, address, etc
The data is accessed via a Directory Information Tree (DIT).
A DIT is a hierarchal structure that consists of a root with many nodes or branches (similar to a file
directory structure).
For example, a telephone DIT would consist of a root with nodes for each country that contains
nodes for each area code that contains nodes for each phone number.
User
Directory
DUA
The
Directory

6.  LDAP defines operations for interrogating and updating the directory.
 Operations are provided for
 Adding
 Deleting an entry from the directory
 Changing an existing entry
 Changing the name of an entry
 Search for information in the directory.
 The LDAP search operation allows some portion of the directory to be searched for entries
that match some criteria specified by a search filter. Information can be requested from each entry
that matches the criteria.
 Data is updated (added, changed or deleted) by transactions described by the protocol.
 Steps to add entries:-
Perform the following steps to add a user entry to the directory server:
1) Ensure that the X.500 directory server is running
2) Start the LDAP Browser, as follows:
 If you installed the standalone version of Apache Directory Studio, double-click the
relevant icon to launch the application.
 If you installed the LDAP Browser plug-in into an existing Eclipse IDE, start Eclipse
and open the LDAP perspective. To open the LDAP perspective, select Window|Open
Perspective|Other and in the Open Perspective dialog, select LDAP and click OK.
3) Open a connection to the directory server. Right-click inside the Connections view in the lower
left corner and select New Connection. The New LDAP Connection wizard opens.
4) Specify the network parameters for the new connection. In the Connection name field, enter
Apache Directory Server. In the Hostname field enter the name of the host where the Apache
Directory Server is running. In the Port field, enter the IP port of the directory server (for the
default instance of the Apache directory server, this is 10389). Click Next.
5) Enter the parameters for simple authentication. In the Bind DN or user field, enter the DN of
the administrator's account on the directory server (for the default instance of the Apache
directory server, this is uid=admin,ou=system). In the Bind password field, enter the
administrator's password (for the default instance of the Apache directory server, the
administrator's password is secret). Click Finish.
Root
Country
Phone no.

7. 6) If the connection is successfully established, you should see an outline of the Directory
Information Tree (DIT) in the LDAP Browser view. In the LDAP Browser view, drill down to the
ou=users node, as shown.
7) Right-click on the ou=users node and select New Entry. The New Entry wizard appears.
8) In the Entry Creation Method pane, you do not need to change any settings. Click Next.
9) In the Object Classes pane, select inetOrgPerson from the list of Available object classes on the
left and then click Add to populate the list of Selected object classes. Click Next.
Fig:New Entry Wizard
10) In the Distinguished Name pane, complete the RDN field, putting uid in front and jdoe after
the equals sign. Click Next.
Figure:Distinguished Name Step of New Entry Wizard

8. 11) Now fill in the remaining mandatory attributes in the Attributes pane. Set the cn (common
name) attribute to John Doe and the sn (surname) attribute to Doe. Click Finish.
Figure: Attributes Step of New Entry Wizard
12) Add a userPassword attribute to the user entry. In the LDAP Browser view, you should now
be able to see a new node, uid=jdoe. Select the uid=jdoe node. Now, right-click in the Entry
Editor view and select New Attribute. The New Attribute wizard appears.
13) From the Attribute type drop-down list, select userPassword. Click Finish.

9. 14) The Password Editor dialog appears. In the Enter New Password field, enter the password,
secret. Click Ok.
15) To add more users, repeat steps 7 to 14.
A directory service is the collection of software and processes that store information about your
enterprise, subscribers, or both.
An example is the Domain Name System (DNS)
The following table lists the operations defined in the LDAP v2.
Operations Description
Search Used to search the directory. The client specifies the starting point (base object)
of the search, the search scope (the object only, its children, or the subtree
rooted at the object).
Modify Used to modify an existing entry. The client specifies the name of the entry to
be modified and a list of modifications. Whether its values are to be added,
deleted, or replaced.
Add Used to add a new entry. The client specifies the name of the new entry and a
set of attributes for the new entry.
Delete Used to remove an existing entry. The client specifies the name of the entry to
remove.
compare Used to test whether an entry has an attribute/value pair. The client specifies the
name of the entry and the name and value to check.
Abandon Used to terminate an outstanding request.
LDAP Search Filter Operators
Operator Definition Description Example
= Equality Attribute must exactly
match value.
cn=Jean Smith
=<string>*<stri
ng>
Substring(s) Substring attribute must
contain substring(s)
provided. The asterisk
(*) matches zero or
more characters.
=<string>*<string> Substring(s)
Substring attribute must
contain substring(s) provided. The
asterisk (*) matches zero or more
characters.
>= Greater than
or equal to
Attribute must be
greater than or equal to
value.
age>=30
<= Less than or
equal to
Attribute must be less
than or equal to value.
roomnumber<=3999
=* Presence
matches
Entry has attributed of
specified name.
(objectclass=*)
~= Approximate Usually implemented as
a "sounds like"
algorithm. Attribute
must be "approximately
equal" to value.
cn~=Jean Smits

10. & Boolean
AND
All filters must be true. (&(sn=Smith)(ou=Reservations))
| Boolean OR Any of the filters might
be true.
(|(manager=cn=Jean
Smith,ou=Reservations,o=Alphalit
e Airways,c=US)(ou=Marketing))
! Boolean
NOT
None of the filters might
be true.
(&(!(ou=Maintenance)(!(ou=Finan
ce))))
 Access Control
The OpenLDAP server keeps the access control lists in the configuration file and uses regular
expressions for the comparison of ACL targets (what is being secured) and subjects (who is being
allowed access) while iPlanet (previously Netscape) and IBM keep the access control information
in the directory tree as an attribute of the entries. A user may be allowed access to attributes on his
own entry that no one else has access to, such as the USERPASSWORD attribute.
 The directory service is distributed over physically separated entities that are directory
system agent (DSA). This distribution is transparent to user.
 Each user or user process is represented by a directory user agent (DUA) that interacts with
directory.
 It is assumed that a service is provided regardless of network partitioning resulting from
events such as non-local site failures. This is achieved by the distributed nature of DSAs
and replication of directory information.
 Caching is also recommended to increase the performance of the directory service but it
is a local issue: the x.500 standards does not provide caching algorithm and it is up to the
implementer of the local DSA to do so.
 Cache:-Whenever we need data from some page of the main memory, we must bring it into
a smaller section of fast memory called the cache.
 The goal of a caching algorithm is to evict pages from the cache in a way that minimizes
the number of cache misses.
 Cache miss: When a program accesses a memory location that is not in the cache, it is
called a cache miss.
 The X.500 protocol provides for database replication. This means that directory data can be
replicated or copies distributed to multiple servers for the purpose of load distribution and
system contingency.
 Directory Information Base (DIB): the set of information managed by the Directory is
typically used to facilitate communication between, with or about objects such as
application entities, people, terminals and distribution lists.
 (Directory) user: the end user of the Directory, i.e. the entity or person which accesses the
Directory.
 ARCHITECTURE:-
 X.500 directory consists of a Client-Server communicating
 The Client is called the Directory User Agent (DUA)
 The Server is called the Directory System Agent (DSA).
 DSA:-A particular server that maintains a subset of the DIB and provides an access point to
the directory for DUAs to connect.
 There are two sub-protocols used to communicate between systems:-

11.  The communication protocol between a DUA (Client) and a DSA (Server) is called the
Directory Access Protocol (DAP).
 The communication protocol between one DSA (Server) and another DSA is called the
Directory System Protocol (DSP).
 The X.500 uses the DSP sub-protocol to give a “distributed” and “global view” of the data.
 That is, not all the data is stored on one server but distributed among multiple servers.
 When a client accesses a X.500 system via DAP, the data is gathered from one or several servers
Using DSP and presented as one global view of the data

 Global directory
 x.500 has the potential to create the infrastructure not only for global telephone directories,
but for global postal directories, global organization directories.
 The directory consists of a number of DSAs interacting with each other to service
information requests.
 A global directory would consist of hundreds or thousands of DSAs running throughout the
world, with one or more DSAs per country.
 The fig shows a hierarchical structure for a global directory.
 Each node in the tree represents a DSA.
The Directory
DUA
DUA
DUA
DSA
DSA
DSA
DSA

12.  There is a root DSA somewhere in the world, which has the knowledge (e.g. DSA name
and address) about its children, the root DSAs for all the countries in the world.
 Each country’s root DSA would, in turn, have knowledge about its child DSAs (e.g. state
and province DSAs), which would, in turn, have knoeledge about DSAs representing cities
in their states, and so on.
 Each DSA must maintain the knowledge at least about its parent and children DSAs.
 This is essential in order to chain request and information, or to refer to other DSAs.
 However, a specific DSA does not need to maintain knowledge about the thousands of
other DSA in the world.
 An important concern in such a hierarchical structure is the vulnerability of higher level
DSAs.
 If a higher level DSA fails, the child DSAs in its subtree will be disconnected from the rest
of the world.
 Some fault-tolerent measure, such as installing backup DSAs for critical DSAs, would be
required. Another concern Is performance.
 Measures such as replication and caching of directory information may need to be
implemented to avoid excessive time-consuming network traffic.
For instance:-Assume that a university professor in china named Mao is looking for
information on a computer scientist named James Hong who lives in London, Ontario,
Canada.Using a program (DUA), professor Mao would query the local DAS in china. If professor
Mao knows exactly where Hong lives, he will provide the distinguished name(country=Canada,
province=Ontario, city=London, name=James Hong) as an argument to Directory read operation.
In this case, the local DSA would contact its parent DSA, which would contact its parent DSA all
the way up to the root DSA, world, to forward the read request. The DSA world would then contact
the DSA london to read the information on hong. The information would in reverse direction back
to professor Mao in china.if professor Mao knows that james hong lives in canada but does not
knows in which City, he could request the search base to be set to canada and search for hong with
the relative distinguished name, (name=james hong). This search would retrive information on all
instances of james hong in canada. Proffesor Mao would then have to browse through the available
hongs to determine which is the one he is really looking for. If mao knew other information about
Hong, e.g. that he works for a Computer Science Department of a university in the province of
Ontario, he would constrain his search further. It should be noted that the search capabilities of the
x.500 directory give it a power that traditional paper telephone directories cannot match.
World
Ontario
Canada
London
ParentDSA
China
Mao

13. WORLD
CANADA USA UK CHINA
ONTARI
O
TORONT
O
QUEBEC
BC NS
OTTAW
A
LONDO
N
SARNIA

14. The data is accessed via a Directory Information Tree (DIT).
A DIT is a hierarchal structure that consists of a root with many nodes or branches (similar to a file
directory structure). For example, a telephone DIT would consist of a root with nodes for each
country that contains nodes for each area code that contains nodes for each phone number.

 Attributes and object classes
 All information within a directory entry is stored as attribute-value pairs. The set of
attributes that can appear in a given entry is set by its objectclass.
 New object classes can also be added to permit the new attributes to appear in entries.
 The standards already define a very wide range of attributes, so an important part of the
schema design process is to decide which ones will actually be used. This section proposes
a reasonable subset to start with.
 The common attributes divide into several broad groups:
Naming attributes: these hold the actual names of the real-world object being represented, and are
commonly used for searching.
 Descriptive attributes: photos, textual descriptions.
 Postal attributes: these deals with physical location and the delivery of physical objects.
 Telecommunication attributes: phone numbers, e-mail addresses etc.
 Authentication attributes: usernames, passwords, unique identifiers, and data for Samba
and Kerberos, X.509 certificates.
Root
Country
State

15.  Kerberos: -is an authentication service
 X.509 certificates: - VeriSign issues X.509 certificates with the product name VeriSign
Digital ID
 Management attributes: owners, managers, access-control lists.
1) Naming attributes
Most of these are derived from the generic name attribute type. This gives them a length limit
of 32768 characters, the UTF-8 character set, and a set of case-insensitive matching
operations.
UTF-8 character set:-A character in UTF8 can be from 1 to 4 bytes long. UTF-8 can represent
any character in the Unicode standard.UTF-8 is the preferred encoding for e-mail and web
pages.
String
Representation
X.500 Attribute Type Size of Data Equivalent OID
C CountryName 2 2.5.4.6
O organizationName 1…64 2.5.4.10
OU organizationalUnitName 1...64 2.5.4.11
CN commonName 1...64 2.5.4.3
ST stateOrProvinceName 1...64 2.5.4.8
L localityName 1...64 2.5.4.7
STREET streetAddress
DC domainComponent
UID userid
2) Authentication and authorization
Networked applications frequently use LDAP to support authentication. In the simplest form, they
present the username and password.
Authorization can be more complex: this is the job of working out what the user is permitted to do
once they have proved their identity. Most applications define a set of roles, each with permission.
suppose our Example Organization has a web portal with a content management system. This
supports several levels of access:
 Read-only access to public data
 Read-only access to data in certain defined categories

16.  Author access to create new content
 Editor access to modify content created by others
 Manager: can set access permissions for others
dc=authorization,dc=portal,dc=apps,dc=ds,dc=example,dc=org
An application wishing to check whether a user has some particular permission now performs these
operations:
1) Find the user's DN: this will normally be done during the authentication phase
2) Derive the DN of the relevant permission entry from the permission name. This is usually a
simple string concatenation.
3) Perform a “base object” search on that DN using the assertion that the user's DN is in the
member attribute. If the search returns a result, then the user has the permission being tested.
4) Performance issues
The layout of the DIT and the contents of entries can have an effect on the performance of the
LDAP server. It is important to consider how the data will be used, and to design efficient
searches. For example, if a client program needs to find a Unix-using person whose surname is
Jones it is best to base the search at the root of the dc=people tree and to include suitable object
classes in the search string:
1) (&(sn=Jones)(objectClass=person)(numericUid=*))
2) (&(mail=*)(|(mail=andrew*)(|(cn=andrew*)(sn=andrew*))
3) (displayName=andrew*)(sn=andrew*)))
Where performance of particular applications is critical, it may be necessary to replicate some or
all of the DIT to dedicated servers with optimized indexing. The DIT layout proposed here allows
for several variations of this idea.

17.  Current and Future use of the X.500 Directory
1) Network Management: -
Architecture: -
 The directory services provide a repository for information.
 The directory is distributed and replicated for increased availability, performance and
reliability. The fact that there may exits multiple DSAs distributed over the network or the
fact that some (or all) information is replicated is transparent to the user.
 What the directory provides to the user is the ability to
 insert
 remove
 update and
 Search information entries.
 The NM DUA (Network Management Directory User Agent) is required as an interface
between the NM tools and directory.
 Management information that is to be stored in the Directory is passed from a management
entity (Either NMS or NE) to the NM DUA, which then communicates with an
appropriate DSA in the Directory Service to complete the task.
 The Directory access protocol is used between NM DUA and DSA.
 The NM DUA must at least support the operations to add, update and retrieve
information entries.
 Management information for the directory
 They have classified management information into three groups 1) static 2) dynamic and 3)
semi dynamic MIB.
 Static management information should be stored in the directory for various management
applications.
 Static MIB information is updated infrequently but will mainly be retrieved for look up
purpose. The dynamic MIB information which is constantly being updated is not quite
suitable for being stored in the directory because of its update frequencies.
 The dynamic MIB information is usually updated every few microseconds or
milliseconds. The rate of update frequency to the directory is, in general, expected to be
more than what the directory service can handle.
 The semi-dynamic MIB information which is in general updated a lot less frequently
than the dynamic MIB, however, should also be suitable for being stored in the directory.
 Typically the semi-dynamic MIB information contains historic data or data that is updated
every few minutes or hours.
 This rate of update frequency should be adequately handled by the directory services.
 In order to store MIB information in the directory, MIB objects and attributes must be
defined in the directory services.
Network
Management Tool NM-DUA The directory
services.

18.  The directory services allows the user to define the objects and attributes of information
which is to be stored in the directory.
 A prototype implementation of the of the integrated network management architecture
Network management tool:-
 The network management tool used is a network traffic load monitoring system which uses
the aggregate agent concept.
 The tool has been designed and implemented to overcome two major problems that arise
when managing large heterogeneous interconnected networks.
 The first problem deals with communication between two or more NMSs involved in
networks management.
 When managing a group of subnets, some of the data collected by an individual NMS will
need to be made accessible to other NMS managing nearby subnets and to NMS responsible
for groups of subnets.
 The second problem arises from the desire to impose a hierarchical structure on the flow of
management information.
 This hierarchical structure allows a central authority that is responsible for overall network
management to monitor changes occurring in various subnets and take appropriate action.
 In this hierarchical scenario, any intermediate level NMS could be monitoring and
controlling groups of subnets.
 On this way, departmental or regional network administrators not only have direct access to
their networks for management but also participate in the overall management hierarchy by
passing their subnet information to higher levels.
Fig: An example of hierarchical network traffic load monitoring system
 The systembasically works as follows:-
 An NMS manages a number of NEs, each of which monitors network traffic information
from its interface.
AANMS
AA
NMS
NMS 1
Host
Host
Host
Host
Gateway
Gateway

19.  The number of packets that have been sent to the network from the device and the number of
packets that have been read from the network from the device are examples of such traffic
information.
 An NMS periodically polls each NE and collects the traffic information.
 The collected traffic information is then averaged out (per second) and then passed to the
aggregate agent (AA) who collects network load information from one or more NMSs.
 Aggregate agents (AA) are then polled by higher level manager called aggregate agent
manager (AANMS).
 In this way, the network load information can be passedup hierarchically all the way
up to the root of the hierarchy.
 Domain Object: - a domain is a logical entity within an interconnected network, and consists
of a set of NEs.
 The hostList attribute contains the names of NEs in the domain. In our prototype
implementation, a domain is the basic unit that an NMS manages.
 The network load information for this particular domain for some time interval is stored in
the netload attribute which can be retrieved by other applications for various uses.eg:-
overall network load of an entire departmental or campus entire network can be
analyzed.
 Only the netload attribute is a semi-dynamic MIB; the others are static.
 The applications attribute contains the name of application that a particular network element
can run.
 It also tells where the application programs can be found. E.g. it contains the file path of
the agent program that collects network traffic information.
 This is where NMS fetches the file paths of the agents when activating them.
 The network element object definition consists of static MIB information only. Dynamic
information is best kept locally within each device.
 System Management:-
Similar study was performed to investigate possibility of using the directory services for supporting
system management. They concentrate only on system load monitoring
A heterogeneous distributed computing environment, such as departments consists of a number of
computer and disk servers and client workstations from a variety of computer vendors such as IBM,
DEC, SUN, MIPS, nCUBE, APPLE.
1. WHEN A User logs onto the system.
1.1 A system “punter” program running on a server machine access workstation load
information of all available workstation from the directory.
2. The least loaded workstation is selected.
3. User automatically logged into that workstation instead server.(To balance system load)
4. A small agent program exists on individual workstations.
5. The agent program periodically determines its workstation’s load and stores it in the
directory
6. Determine the least loaded one and assigns the user to that workstation.
Although system load related classes and attribute had to be newly defined, most of class and
attribute definitions defined for network management information were reused for the system
load monitoring application. System load monitoring is only a small aspect of system management;
however, this study showed that the x.500 directory has the potential to be used in managing
distributed system.
Currently, they are looking at supporting other aspects of systems management using the directory.

20.  Resource informationmanagement
Resource information management in heterogeneous distributed departmental computing
environment using the directory. Resource information in such an environment includes information
about devices such as computers, printers, the networks they belong to and their connectivity. There
exists a real problem in our department that keeping track of and updating such resource
information requires a coordinated effort among a number of group of people, such as System
managers, departmental administrators, professors and teaching assistant
• System manager: -
Systems manager is responsible for the computer systems within a company, overseeing
installation, ensuring backup systems operate effectively, purchasing hardware and software,
for an organization and contributing to organizational policy regarding quality standards and
strategic planning.
Information systems managers work in every size of organization in the industry and the service
sector, usually with a staff of technicians, programmers and database administrators reporting to
them.
1) Keep a track of hardware and software resource information.
2) At the beginning and end of the term he can create and delete hundreds of students’ accounts
respectively.
• Departmental administrator: - Keep track of personnel information of professors and staff.
• Professor: Keep track of class lists.
• Teaching assistant: - Keep track of student marks using class list.
 Overview of the ODP Trader
 The ODP (Open Distributed Processing) is a set of draft standard documents that are aimed
at a variety of architectures, networks, and operating systems to provide an open
distributed processing environment.
 The Trader’s purpose is to provide a matchmaking facility between ODP objects.
 The Trader allows ODP objects to be configured into an ODP environment without prior
knowledge of the services or service providers within that environment by acting as a third
party that enables the dynamic service selection and the linking of clients and
 The ODP Trader deal specifically with trading policies, security requirements, accounting
requirements, transfer requirements, quality of service, and federation.
 At the core of the ODP Trader system are the interactions among four different types of
objects: traders, importers, exporters, and services.
 An exporter is an ODP term for a service provider. It is an object with a service that it
wishes to make available to other objects. Providing a service is accomplished by exporting
the service to the Trader. An exporter is also able to later withdraw (e.g., make unavailable)
the service.

21.  In ODP terminology, a requester of services is known as an importer.
 The expectation is that importers in the ODP environment can operate without any prior
knowledge of where the required services are or which object provides them.
 To find these services the importer must make a service request to the Trader.
 The Trader then returns to the importer the details of the services matching the service
request if any exist.
 A service is a function provided by an exporter for use by other ODP objects. A service may
be one of the following
 Types:
 An atomic operation (e.g., write),
 A sequence of Operations (e.g., open, write, close), or
 A set of operations (e.g., read, write, open, close).
 Functional Architecture
 A certain level of functionality will be needed to exist within the TBRM (Trader-Based
Resource Management System) to adequately respond to client requests.
 The TBRMS will need components to communicate with the clients, parse their requests,
and provide a means through which resource information may be stored, retrieved,
updated, and deleted.
 The TBRMS should also offer some means of assuring the status of resources for which it is
responsible and a method of controlling client access to the resource information.
 The TBRMS architecture should be clean, extensible, and modularized.
 Resource Information Repository
 The very nature of the TBRMS requires that a resource information repository that stores
resource information form a crucial element of our TBRMS design.
 Some of the necessary characteristics of the resource information repository are: extensible
data modeling capabilities, general naming scheme, distributed service, heterogeneous data
sources, good performance, and security.
 TBRMS Architecture
 TBRMS architecture defines the major components that interact to function as the TBRMS.
 These components are TBRMS Coordinator, Request Parser, Access Control, Inventory
Control, Matcher, Resource Information Maintainer, and Federator.
 TBRMS Coordinator: This component coordinates activities within the TBRMS and acts
as a front end to the TBRMS. As client requests are received by the TBRMS, the
Coordinator acts upon them by interacting with the other TBRMS components. It
coordinates the activities within the TBRMS to produce timely responses to client requests.
 Request Parser: This component takes the client requests and translates them into an
internal format which will later be translated into requests of the type understood by the
Resource Information Repository.
 Access Control: This component is used to determine the extent to which clients may make
use of the TBRMS. For example, an importer must be registered with the TBRMS before it
may request resources, and a client must be the owner (exporter) of a resource to modify or
withdraw it.
 Inventory Control: This component is used to interact with resources to enquire about their
status, including determining whether a resource is still up and running.
 Resource Information Maintenance: This component exists to provide an interface to the
Resource Information Repository. It provides the functionality that allows the TBRMS to
_add new information on resources delete information on resources _modify information on
resources list available resources _search for specific resources

22. Matcher: This component queries the Resource Information Repository for resources. The queries
are generated by the Request Parser component based on the resource requests of a client. The
Matcher returns all resources matching the original request.
Federator: To be effective in a distributed environment the TBRMS should not be a centralized
service but should instead be distributed in some manner. The Federator component provides the
means by which two TBRMSs could communicate to share the resources each manages with the
other. The Federator component in part determines which resources may be shared with another
TBRMS. The ODP Trader document describes the federation (or interworking) of Traders which
other work has examined.
 TBRMS Service Interfaces
The service interfaces of the TBRMS system represent points of interactions between the TBRMS
and its clients. These interfaces have been grouped by function, namely client, importer, and
exporter. The details of the interface specifications can be found in.
 Client
 Before any client (importer or exporter) may make use of the TBRMS we require that the
client first register with the TBRMS. Accordingly, when a client is finished making use of
the TBRMS, we require that the client deregister itself. Although strictly speaking this set of
interfaces is not necessary for a working TBRMS, we felt that there should exist some
method by which the TBRMS could keep track of its clients. Forcing clients to register
before using the TBRMS allows the TBRMS to have knowledge of its clients. This will
become more important with security extensions to the TBRMS.
 Register: The operation called register allows a client to register itself with a TBRMS.
Since a client may use the TBRMS to both import and export resources there is no need for
the client to state what use it will make of the TBRMS.
 Deregister: The operation called deregisters allows a client to deregister itself from a
TBRMS.
 Importer

23.  Importers are TBRMS clients which have resource requirements that need to be fulfilled.
The set of importer operations provide a method that allows a client to do some resource
discovery and eventually provide the information necessary to reference a particular
resource.
 Search: The operation called search can be used by an importer to discover the resources
matching a set of resource requirements.
 List: The operation called list is used by an importer to retrieve the details of a particular
resource.
 A client may use the list operation on a variety of resources to select the most appropriate
resource to fulfill its resource needs. An importer client uses the previously acquired
resource identifier for the resource of interest.
 Select: The operation called select is used by an importer client to retrieve the interface to a
resource.
 The client must supply a previously obtained resource identifier.
 Exporter
Exporters are TBRMS clients which have resources they are willing to make available to other
clients in the distributed system. Although the exporter allows other processes to use its resources,
the exporter maintains control of the resource and may change or withdraw the resource at its
convenience.
 Export: The operation called export is used by an exporter wishing to make a resource
available through the TBRMS. The exporting client supplies to the TBRMS the resource
properties for a resource. The resource properties are expressed as a list of assertions about
the resource.
 Withdraw: the operations called withdraw is used by an exporter which, after previously
exporting a resource, now wishes to remove the reference of the resource from the TBRMS..
 Update: The operation called update is used by an exporter which, after previously exporting
a resource, now wishes to update some or all values associated with that resource; for
example an exporter may want to change the values associated with the attributes
queueLength and costPerPage for an exported printer resource.
 Status Responses
It is a basic assumption of the TBRMS system that the clients may rely on the TBRMS being in
good working order. This is true because clients might depend on the TBRMS to provide essential
services. Therefore it is important that the clients receive from the TBRMS messages indicating the
status of their operations on the TBRMS interfaces. Examples of status responses would be
Ok, clientUnknown and resourceNotFound.
Unfortunately, managing most of resource information is currently done manually.
And they felt that an online resource information management systemwas desperately needed
to reduce the time and effort devoted to keep track of such information by the people involved.
Thus, they are investigating the development of a departmental resource information management
system using directory.
They have implemented a prototype system which consists of a number of user friendly tools that
interact with the directory to store, retrieve & update information on resources. The prototype shows
that it is certainly feasible to support managing various departmental resources information.
Definition:-

24. Img: Sun Desktop Img: Sun Cpu
Sun sparc: - SPARC is a registered trademark of SPARC International, Inc., an organization
established in 1989 to promote the SPARC architecture, manage SPARC trademarks, and provide
conformance testing. Implementations of the original 32-bit SPARC architecture were initially
designed and used in Sun's Sun-4 workstation and server systems, replacing their earlier Sun-3
systems based on the Motorola 68000 family of processors. Later, SPARC processors were used in
SMP and CC-NUMA servers produced by Sun Microsystems and designed for 64-bit operation.
Sun 3:- Sun-3 was the name given to a series of UNIX computer workstations and servers
produced by Sun Microsystems.
Img: Pseries
IBM RS6000:-The System p, formerly known as RS/6000, was IBM's RISC/UNIX-based
server and workstation product line.
MIP (million instructions per second):- is a measure of a computer's processor speed.
 TBRMS Prototype Implementation
 A prototype Trader-Based Resource Management System has been developed to
demonstrate that the TBRMS provides a viable means where by resources may be managed
in a distributed computing environment.
 Work with the prototype has taken place within the UWOCSD Systems Lab. This lab is
comprised of a network of heterogeneous computers consisting of Sun Sparc, Sun 3, IBM
RS6000 and MIPS workstations as well as a 10-processor Sequent Symmetry

25.  The prototype TBRMS server runs on one of the Sun Sparc workstations. Clients running on
all system lab machines have successfully interacted with the prototype TBRMS server.
 The prototype relies on the X.500 Directory Service as its resource information repository.
 The X.500 Directory Service possesses some essential properties that satisfy the
requirements of our resource information repository, in particular its powerful information
modeling capability, global naming scheme, distributed service, and simple access interface.
 TheX.500Directory contains entries (or objects) which describe information about entities
(e.g., resources).
 The ISODE software more formally the ISO Development Environment, was an
implementation of the OSI upper layer protocols, from transport layer to application layer,
which was used in the Internet research community to experiment with implementation and
deployment of OSI
 An object oriented approach is used for modeling directory information objects and allows
the users to define any information object class by either extending existing classes or
defining entirely new classes.
 The prototype TBRMS uses the ISODE Quipu 8.0 implementation of X.500 and a directory
service agent (DSA) running on a second Sun Sparc workstation within the lab.
 The TBRMS accesses the DSA through the light-weight directory access protocol (LDAP).
 At present, the prototype TBRMS only does a weak form of access control.
 Each client and resource is assigned a unique identifier which is used in any subsequent
interaction with the TBRMS.
 Authentication is performed using this identifier to ensure a client has the ability to perform
its requested actions.
 For example a check is made before a client is allowed to update or withdraw a resource.
Currently all authentication is carried out by performing search and read operations on the
X.500 directory information.
 That is, when a client makes a request the TBRMS uses the identifier provided by the client
to search the directory.
 If an entry with a matching identifier is found the client is assumed to be valid.
 Similarly if the request involves either withdrawing or updating a resource then the
operation is allowed only if the directory entry contains both the client’s and resource’s
identifiers.
 The actual resource types were implemented using X.500’s object classes.
 This provides a good method of ensuring type checking on resource definitions.
 When a resource is exported one of its attributes must be a resource Type. The value
associated with the resource type is used as part of the X.500 object class
 They are currently in the process of completing the development of the resource information
management system.
 Distributed applications management
 In general it consists of multiple cooperating processes running on one or more machines.
 Their study investigates the use of the directory for managing distributed applications.
 Objective of managing distributed application is to ensure correct, reliable and efficient
operation.
 Further management tools may be able to provide ways to prevent possible problems as well
as to improve the performance of the application.
 Management tools may be able to provide ways to prevent possible problems as well as to
improve the performance of the application.
 CORDS MDBS
 The goal is to provide users and applications with a uniform, integrated view of a collection
of distributed, autonomous, heterogeneous data source.

26.  The data source supports different data models.
 Application interacts with the MDBS via library of interface functions called a MDBS
client.
 Client connects to MDBS server which performs DBMS function.
 Such as query processing and optimization, transaction management and security at the
global level. An MDBS server connects to a component data source (CDS) through its
normal application program interface, and then translated the response into the form
expected by the MDBS.
 The MDBS catalog is a central repository for metadata needed by the multidatabase system.
 Three classes of metadata are required: schema, mapping and description of CDSs. The
common data model used in cord MDBS is the relational model.
 So schema defines a collection of data in terms of relational tables and their columns and
any application constraint.
 Three types of schemas are export, MDBS and application schemas.
 An export schema defines: - data made available to the MDBS from CDs,
 MDBS schema defines: - collection of data at the MDBS level which are drawn from the
exported data.
 Application schema defines: - application specific view of MDBS level data.
 Mappings are needed to transform export schema object into application scheme objects. W
also need to store descriptions of CDSs which include parameters such as processing
capabilities, relative processing speeds, available resources and communication links and
speeds.

27. This fig portrats some of the major entities and relationships in the catalog information used
by the MDBS.
 There are number of MDBS servers. Each server provides service o applications and
accesses a number of sites.
 Each sites holds one or more CDSs.
 Access of an application to the data is through an MDBS schema which specifies tables and
column, and constraint definition.
 Request against a MDBS schema may be compiled and stored in the form of access plans for
subsequent execution.
 Any errors detected by a CDS during the processing of a request must be reported in terms
of the error set of the MDBS.
 The data available from a CDS is defined in terms of one or more export schema. Each
export schema contains definitions of the available tables, columns and constraints and
indexes.
 The mapping between corresponding MDBS schema objects and export schema object are
provided by the database integration process.

28.  Some relations such as the MappedTo relation are represented by attribute of an object class.
For instance, the MappedTo relationship between MDBS column and Export Column is
represented by an attribute sourceColumnOid of class AppColumn in the x.500 schema. This
attribute is a list of export column identifiers which define the MDBS view column.
 Cords Information Repository
 This approach is used in the CORDS MDBS to store the catalog information is to use a
separate information repository service within the CORDS services Environment.
 This is a unique approach to catalog storage and management and was chosen for two main
reasons:
1) Discussion with other research groups in CORDS in particular the group working in the area of
system management – there was a common need to store and manage global information and
sharing of information could be exploited by both groups.
2) In order to provide scalability and reasonable performance, the MDBS must consist of
multiple MDBS servers distributed about the network.
 Each server will have to be able to provide access to all CDS. This requires MDBS catalog,
while logically centralized, is physically distributed and at least partially replicated.
 Most commonly used for locating objects and services by name, it is effectively a distributed
database, which can potentially be used to store any type It satisfies the main requirements
which include:
1. A data model rich enough to model the entities and relationship present in the catalog
information.
2. The ability to store and manage a number of different types of data including text, large data
structures and functions.
3. The ability to efficiently support both static and dynamic data.
4. Support for name resolution.
5. Access language and methods to support both querying and browsing.
6. Support for distributed and replicated data and distributed transactions.
• The directory can be used to Store application level management information of the
application such as names of executable images on which machines and directories they reside and
so on. In earlier studies on the use of the directory for network and system management,
The names of manager and agent programs and where they are physically located were stored in the
directory.
• Such information was retrieved from the directory when starting up the managers and agents.
• Use to store run time management information such as process identifiers, their
communication ports, communication channels between 2 communicating processes, on which
machines the processes are executing and so on
• Performance related information of individual process such as 1) queue length 2) buffers
available 3) the number of messages received and sent can also be maintained in the directory.

29.  SUPPORTING MDBS
The goal of the MDBS is to provide a uniform, integrated view of autonomous, distributed,
heterogeneous database.
A multidatabase is a virtual database. As such, it requires support for the storage and retrieval of its
operational data. That is, is requires the equivalent of the data dictionary or catalogue found in
traditional relational database.
This is a joint work with Queen’s university at Kingston, Ontario, Canada. The objective of this
work is to integrate the MDBS with the Directory service based upon the use of the directory to
integrate the MDBS with the directory service based upon the use of the directory to store the
MDBS catalogue. The MDBS catalogue contains all the information necessary to operate the
MDBS. It is analogous to the catalogue or data dictionary of traditional relational DBMSs.
Component Data Source

30. The MDBS Catalogue is a set of cover routines for the Information Repository. All MDBS access to
the Information Repository is performed via the Catalogue. Thus, the Catalogue has no data
requirements of its own on the repository; it provides routines to service the data requirements of the
other functional units.
They have analyzed the requirements of the MDBS catalogue: expected components, expected types
and frequencies of access, security and performance.
They have defined a set of X.500 directory class and attribute definitions for the MDBS catalogue
information.
They are currently in the process of implementing a prototype.
 Other uses:-
A recent world wide survey revealed a number of other experimental uses of the X.500 Standard
some quite far removed from its original “white pages” paradigm.
The intension of survey was: - to show how various organizations are using X.500 in ways which
extend the view of X.500 as a ’White Pages’ service.
Some of the projects: -
1) An experiment in zurich, switzerland, is concerned with using the directory to integrate time
table information services for public transport providers.
In their scheme – time table information is stored in a common format in locally-managed DSAs. A
specialized DUA then accepts source-destination user request, and then explores time table
information in the directory tree to respond to the users ‘queries.
2) Electronic document interchange (EDI) is a means by which companies can transmit forms
such as purchase orders and invoices electronically.
Before EDI can take place, potential partners must come to an agreement regarding address,
preferences, and EDI capabilities.
A project in Ireland aims to solve this “first-order” problem by storing product catalogues and EDI-
readiness information about trading partners in the X.500 directory.
3) The soft pages project in Japan makes use of the directory to find the “best” copy of a file
wanted by a user.
Electronic archives of information exist worldwide, and it is not uncommon for one file or program
to be stored in many sites. Finding an archive site with a desired file that is “close” to the user
benefits the user and the networks, by minimizing network traffic. Based on the user’s location,
the locations of the desired file, and network configuration information, the soft pages user agent
finds the lowest-cost copy for the user to retrieve.
4) X-Tel services Inc. proposes using the directory as a rendezvous(assemble point) for a multi-
user adventure game, where each room will be a different entry and modify entry operations
implement action such as “pick up” and ”put down”
A project underway at Xerox Corporation involves a two-step plan to bring X.500 DSA access to
the corporation’s clearinghouse information.
The clearinghouse protocol is a component of the XNS protocol suite and is similar in nature
to X.500.
XNS: - The Xerox Network Systems (XNS) protocols provide routing capability and support for
both sequenced and connectionless packet delivery.

31. The first step of the project is to transfer the existing clearinghouse data into a relational database.
• The second step would be the implementation of an x.500 DSA interface to the relational
clearinghouse implementation.
• This would allow X.500 DUAs access to the clearinghouse data.
 Future work.
One of the most important ongoing X.500 project is Internet directory service initiative. Goal of
project is to provide X.500 directory service on the internet. Once these efforts have been
completed, some time in future, the implications of a global directory service, combined with the
global connectivity of the internet, may give rise to application that we cannot yet even imagine.
Areas that intend to investigate the use of the directory to provide a location service for application
in distributed systems. Currently in their environment, certain applications run on specific server
machines; when a server fails, The application dies with it. Users wishing to use the application
must implement manual work around until the server comes back on line. By using the directory to
track applications and servers, we hope to be able to automate the recovery process, providing an
enhanced, transparent computing environment for our users. Communication network bandwidth
has traditionally been the bottleneck in distributed systems, with the time required to transmit
information between nodes and the time required for processing information at nodes. Advance in
network technology may soon reverse this situation.
Currently investigate the impact of high speed networks on distributed applications such as
the X.500 directory services.
 Concluding Remarks.
Here they examined the X.500 directory for possible use in providing global telephone, postal and
organization directories. They also examined its use in a wide variety of application domains
includes Network management, System management, Resource information management,
Distributed applications management, Multidatabase system. And It is clear that x.500 adapts
well to use as an information repository for all these domains, and appears to provide
adequate performance.
It is also important to not underestimate the power of the standardization process.
By virtue of its place as the only directory standard that is international in scope, and its
promulgation by national PTT organization, X.500 is becoming widely accepted throughout the
world. Reports of its use show that it is gaining popularity and becoming an essential service in
many distributed applications. They believe that the X.500 directory will be an important
component in future distributed computing environments supporting the use of information
as a global commodity.