|
|
Contents |
Recall that federation is the process of "hooking" together naming systems so that the aggregate system can process composite names--names that span the naming systems. Many examples of composite names and federation are possible in the computing world, for example, URLs (RFC 1738) and the World Wide Web. One way that the JNDI federation model differs from these models is that 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. 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 readers 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.
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. 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 a Service Provider
trail.
To answer this question, this lesson addresses the following three lower-level questions.
|
|
Contents |