Registry

1
Registry Directory Infrastructure at Stanford
Jeff Hodges Stanford University 30 April 1998

• Note! This talk was superseded by..
• Registry Directory Infrastructure A Case
  History
• ..as of 31-Mar-1999

2
Registry/Directory InfrastructureOverall Problem
Statement

• Highly decentralized enterprise with multiple,
  virtually autonomous systems of record
• Common, shared business objects, e.g. People
• Personnels system faculty staff
• Registrars system students
• Affiliated enterprises systems SLAC, Hospital
• Non-trivial number of variously-affiliated people
  who arent in any system
• Other objects Groups, (network) Services

3
Registry/Directory InfrastructureOverall Problem
Statement, contd

• Directories, as a class, are subtly different
  than general-purpose relational databases
  (RDBMSs)
• RDBMS properties
• strongly typed data
• can represent complex relationships
• transaction support
• support on-the-fly data view generation
• find all the people whose managers are located
  in New York
• no open on the wire protocol standard

4
Registry/Directory InfrastructureOverall Problem
Statement, contd

• Directory properties
• strongly typed and structured information, like
  RDBMS
• open standard access protocols
• core standard schema
• object-oriented
• highly distributable
• extensible schema
• but cant cut on-the-fly views, no notion of
  report generation, etc.

5
Registry/Directory InfrastructureDefinitions and
Scope

• A Registry is a service that serves the needs of
  applications for coordinated maintenance of
  identity information about a class of business
  objects.
• E.g. People, services, groups
• A Registry is a transaction-oriented service
• Client applications will use it mostly to enter
  and update entries.
• Read-oriented access may be handled by other
  components of the overall system, e.g. the
  Directory.

6
Registry/Directory InfrastructureDefinitions and
Scope, contd

• The scope of the Registry is enterprise-wide
• All people affiliated with the university should
  be in the Registry
• I.e. if you need others within the enterprise to
  recognize your affiliation, you need to be in the
  Registry.
• A primary materialization of this requirement
• Needing an authentication principal - a SUNet ID
• Many network services are authenticated
• E.g. AFS distributed file system, various web
  pages, distributed computing resources (e.g.
  POP-based email service)
• Authentication infrastructure is Kerberos-based

7
Registry/Directory InfrastructureDefinitions and
Scope, contd

• Registry entries are shared via the Directory
• Various infrastructure applications utilize the
  Directory when they need information about
  people, e.g...
• _at_Stanford.edu email routing
• WebAuthentication
• Authenticated Printing service
• DialIn Network Service
• Whitepages (I.e. general purpose) Directory
  service

8
Overall Directory/Registry InfrastructureDissemin
ation
Systems of Record
SLOG (Business Rules Implementation)
Registrar
Desktop Clients
Personnel
Desktop Clients
Desktop Clients
LDAP R/W
TDS
TDS
LDAP-based Directory Service
LDAP Reads
Middleware Event Broker
LDAP Reads
TDS
Network-based Applications
Network-based Applications
Registry
Network-based Applications
9
Overall Directory/Registry InfrastructureUpdate
Systems of Record
SLOG
Registrar
LDAP
Desktop Clients
Personnel
Desktop Clients
Desktop Clients
Directory Service
TDS
TDS
Middleware Event Broker
HTTP (authenticated)
Web-based User Interface for Data Maintenance
TDS
HTTP (authenticated)
TDS
Network-based Applications
Registry
Network-based Applications
Network-based Applications
10
Registry/Directory InfrastructureEmail Routing
To user_at_Stanford.edu (Incoming Email Message)
1. SMTP
2. LDAP
2. cnuser? 3. Maildropuser_at_host.stanford.edu
Directory
Mail Server (MTA)
3. LDAP
4. SMTP
user on Host.stanford.edu
11
Registry/Directory InfrastructureSummary

• Natures of Registries and Directories are subtly
  different
• X.500/LDAP-based directory services are not
  RDBMSs
• Makes sense to combine them into overall system -
  play on their strengths
• Project at Stanford is far from, if ever,
  finished -- will continually evolve

12
Acknowledgements References

• The Registry/Directory team is comprised of (at
  least) Booker Bense, Carol Farnsworth, Michael
  Hart, Jeff Hodges, Craig Jurney, John Klemm, Bill
  Lucker, Lynn McRae, Dennis Michael, RL Bob
  Morgan, Catherine Mulhall, Pat Nolan, Michael
  Puff, Dennis Rayer, Sandy Senti, Tim Torgenrud,
  Dwayne Virnau.

13
Acknowledgements References, contd

• References
• http//www.stanford.edu/group/itss-ccs/project/reg
  istry/
• http//www.stanford.edu/group/itss-ccs/project/reg
  istry/registries.html
• http//www.stanford.edu/group/itss-ccs/project/sun
  etid/
• http//www.stanford.edu/group/networking/directory
  /
• This talk will be available at..
• http//www.stanford.edu/hodges/talks/