|
|
Contents |
Federation is the process of "hooking" together naming systems so that the aggregate can process composite names--names that span the naming systems. There are many examples of composite names and federation in computing. For example, URLs (RFC 1738) and the World Wide Web are excellent examples of composite names and federation. One of the ways that the JNDI federation model differs from these models is in how it provides a single programmatic interface for accessing federations. Not just one API for one federation, but one API for many different types of federations.Federation is a first-class concept in the JNDI. You can use composite names and federation as naturally as you would noncomposite names and single naming systems. You simply supply a name, and the JNDI and service providers take care of any federation and name resolution issues.
How does a composite name get processed by the underlying federation of naming systems? This lesson answers this question from an API user's perspective. That is, it provides descriptions and concepts that help an API user or service provider developer understand how federation works. Details and examples of how to implement support for federation in a service provider are described in the Building Service Providers
trail.
To answer the high-level question, we address three sub-questions:
- How does a service provider for a naming system determine which component(s) to process and which to pass on?
- How does a service provider process the component(s) intended for it?
- How does a service provider "pass on" processing to the service provider for the next naming system?
Lineage
The JNDI model of federation is based on the X/Open Federated Naming (XFN) model. The XFN is a C language-based standard for accessing multiple, possibly federated naming and directory services. Those familiar with the XFN will find many similarities between the XFN and the JNDI, not just in terms of federation, but in many other respects.
|
|
Contents |