Naming III – Attribute based Naming
Updated:
- Domain Name System (DNS)
- DNS Zone Data
- Attribute-base Naming: Directory Services
- LDAP: Lightweight Directory Access Protocol*
- Java Naming and Directory Interface (JNDI)
- Discovery in Web Services: UDDI
- Summary
Domain Name System (DNS)
- To access http://aws.amazon.com → amazon’s web service
- First you ask how to get to aws.amazon.com – address
- IP will talk to a company or local DNS server – it redirects the request to root DNS server as IP address of amazon is not in the cache
- Root DNS must have the IP address of aws.amazon → so it returns the IP address to local DNS
- Local DNS server send the information to the client and cache to future use
- You get the website IP address of the website
DNS partitioning
- DNS with global, administrative, and managerial level which is v imp!!!
DNS Zone Data
- How its structured – it’s a tree and could look up for names through some form of attributes
- Names and IP address of at least two name servers with authoritative data for the zone.
- Names and IP addresses of name servers holding authoritative data for delegated sub-domains.
- Importance of caching and replication
- Data will keep changing – frequent on the leaf and less in root
- Gotta ensure that when data is replicated, we have consistency when accessing the actual data
- Even when you cache data the data, in the meantime could’ve changed → hence update needed
- Each name server is free to cache from others, – but make sure that
client is told such data are non-authoritative.
- So when it comes to updating the data, make sure you are talking to the server
- Concept of TTL – time to live – cached data can be used by client up
to a time, but they need to call or ask server with authority to
check the consistency of the data
- E.g – what would be a TTL?
- Since data change you need to ask authoritative to check and v frequently
- Simply depends on which server and which zone we are on
- E.g – what would be a TTL?
DNS: Information in a Node
| Type | Refers to | Description |
|---|---|---|
| SOA | Zone | Holds info on the represented zone |
| A | Host | IP addr. of host this node represents |
| MX | Domain | Mail server to handle mail for this node |
| SRV | Domain | Server handling a specific service |
| NS | Zone | Name server for the represented zone |
| CNAME | Node | Symbolic link |
| PTR | Host | Canonical name of a host |
| HINFO | Host | Info on this host |
| TXT | Any kind | Any info considered useful |
Attribute-base Naming: Directory Services
- Is also known as directory services, where the entities have a set of associated attributes that can be used for searching.
- DNS is a traditional Naming service
- Given a name of the server, gives IP address back
- Its conceptually equivalent to using a telephone directory. Give name, and it give you the num.
- Directory service is a different approach
- Implemented as a distributed database
- A description is stored at a node and a partial description can be used to retrieve nodes
- Lookup entities by means of their attributes.
- Yellow pages – you look for a plumber service– it gives list of companies and numbers
LDAP: Lightweight Directory Access Protocol*
- Directory service and implemented on top of TCP and helps you access info all over the internet
- Seen as a standard for internet-based directory services
- In modern directory service, it has LDAP interface
- Microsoft’s Active directory service is designed to centralise
large company networks into one repository where admins can
manage easily.
- All the student record, staff records, labs, etc – is represented as a record.
- When you store info and attributes you will always be able to search with entities you are looking for
- Microsoft’s Active directory service is designed to centralise
large company networks into one repository where admins can
manage easily.
- [13 pdf 9] table - Each directory entry consists of standard
(attribute, value) pairs, and is uniquely named for lookups
- These are attribute names and have values associated with it
- Country – UK, locality – Leeds, organisation – Leeds university
- It has 2 very imp elements:
- Directory Information Base – collection of all directory entries
in an LDAP service
- Each node is uniquely named as a sequence of naming attributes, Relative distinguished name, so that it can be looked up.
- When you do lookup you always start with Relative distinguished name and say this is my first point of entry – I’m starting with country, locality, organisation, etc.
- → RDN as a root of where you start looking
- Directory Information Tree - the naming graph of an LDAP
directory service, each node represents a directory entry
- It leads to a hierarchy of the collection of directory entries
- When I wanna do a search, I start with Relative Distinguished Name.
- Directory Information Base – collection of all directory entries
in an LDAP service
LDAP: Search Example
- Two directory entries having Hostname as RDN
| Attribute | Value | Attribute | Value |
|---|---|---|---|
| Locality | Leeds | Locality | Leeds |
| Organisation | Leeds University | Organisation | Leeds University |
| OrganisationalUnit | Computing | OrganisationalUnit | Computing |
| CommonName | Main server | CommonName | Main server |
| HostName | comp-pc3211 | HostName | comp-pc3212 |
| HostAddress | 192.31.231.11 | HostAddress | 192.31.231.12 |
- If I do a search on LDAP, id get this.
- Result of search(‘‘(C=UK)(O=Leeds University)(OU=*)(CN=Main server)’’) gives us a host name and address of Leeds uni
- We are using a standard - the directory service should be designed in a way that search like below works.
Java Naming and Directory Interface (JNDI)
- There is some code and you need access the directory service – how?
- JNDI is an API for directory service that allows clients to discover and lookup data and objects via a name
- Is independent of underlying implementation – it’s an interface
- It specifies SPI – service provider interface – to plug the directory service into the framework
- API will allow you to:
- To find an object name and therefore bind to it
- Lookup in the directory
- Provides interface that allows clients to see which directory entries have been modified since the last time you made the request
JNDI Architecture
- JDNI is an interface that abstracts the platform or infrastructure, you expect to have API.
- And the JNDI API talks to the naming manager → the heart of JDNI
- Interface – I’m gonna talk to a service provider through one of the protocols
- So it fits nicely with LDAP, DNS and old shit like RMI and COBRA
- Just to plug it in! I’m gonna talk to LDAP
JNDI code example
- Functionality is mainly provided by javax.naming package, esp the Context and InitialContext class
- Client creates a starting point for lookup, using InitialContext
- Client calls lookup to find sub context or objects by names.
- Server gets the appropriate context and call bind on it.
- Once you have the account you can access the object the way you want
- Account acct = new AccountImpl(“12345”);
- ctx.bind(“John”, acct);
Using LDAP via JNDI
- LDAP for JNDI comes as standard with java.
- Instead of context you have InitialDirContext class and DirContext interface
- When it comes to searching, you could search using specific
attribute names
- NamingEnumeration results = ctx.search(“o=leeds.ac.uk”, “(&(sn=Smith)(mail=*))”, ctl);
Discovery in Web Services: UDDI
- Another service – who help businesses find what web services are exposed, how can developers find WSDL they need etc → through UDDI!
- You could then invoke the service once you find it and see if you do can use it.
The Big Picture
- You have SOAP/REST client and you want to interact with it through a request reply, therefore you need an interface, which comes as WSDL or directly as a URL in REST.
Fundamentals of UDDI
- Organisations wishing to expose their web services create a UDDI business registration in XML and publish it.
- These registrations are held in a db, the UDDI business registry, replicated at UDDI operator sites.
- It itself is a web service and could send query to the web and get back the interface via SOAP over HTTP
- Relevant SOAP msgs can be constructed/ parsed by calls to a standard inquiry API and publishing API
Example: a UDDI Query using JAXR: Java API for XML Registries
- Create ConnectionFactory and set its properties, and create connection
- Obtain RegistryService object from connection, whuch exposes a BusinessQueryManager
- Call appropriate method of BusinessQueryManager to execute query, result being returned as a BulkResponse object
- Call methods of BulkResponse object to check for success or failure and extract details of organisations and services you need.
Summary
- Naming services allow us to bind a name to the attributes of some entity in a DS, and resolve a name into those attributes.
- A directory service allows us to look up an entity by its attributes rather than its name.
- LDAP: an important standard for directory services, commonly used these days
- UDDI supports the publishing and discovery of Web services via a replicated database accessed as a Web service itself
- JNDI provides a standard interface to naming services.
Leave a comment