|The PEAK Developers' Center||FrontPage||RecentChanges||TitleIndex||WordIndex||SiteNavigation||HelpContents|
Enterprise applications use resources, and resources move around. Writing code to directly connect to databases or application servers simply doesn't scale. PEAK's naming package is an extensible framework for providing uniform access to any software-accessible resource. Resources may be accessed by an address (a string or object that contains all necessary information to access a resource) or by a name (which is looked up in a context or naming service to retrieve the resource or its address).
Developers can extend the framework at will by creating their own name and address types, syntaxes, and context objects (naming services). Developers can also supply or override the default serialization and de-serialization handlers (called state factories and object factories respectively). All address types and naming services can be used as the target of attribute bindings provided by the peak.binding package, such as binding.Obtain(). And, there are naming API functions like naming.lookup() which can be applied to any kind of name or address.
Finally, PEAK-supplied or developer-supplied context objects can provide the ability to bind (save) an object or its address under a chosen name, to unbind or remove the object, rename bound objects, and handle LinkRef (symbolic link) objects.
Table of Contents
What's a naming system, and why do you want one for your programs? Naming systems let you use names instead of addresses to refer to the objects you use. Whether the objects in question are database connections, printers, documents, or distributed object services, replacing addresses with names makes programs clearer, more flexible, and easier to maintain.
What's the difference between a name and an address, and why is it important? A name tells us what something is, or is for, while an address tells us where to find it. This is significant because "where" something is can change far more quickly than "what" it is.
Let's say for example, we are in a grocery store, and I would like to obtain a certain canned meat product. I could either say, "go to the back of the store, in aisle 4, on the right-hand side, and get the item from the top shelf," or I could simply say, "I'd like a can of spam please." Obviously, if the store is later reorganized, my "address" for spam may have to be changed, but as long as it's still called spam, I can always ask a clerk or look at a store directory to find it by its name. (Of course, this means that I must go through an intermediary to obtain my spam, rather than going directly to it, but that is the price I pay for the brevity and stability of using a name.)
Notice that the presence of an intermediary also means that names are context-sensitive. That is, the interpretation of a name can vary according to the context. Asking my grocer or my e-mail software for "spam" will produce very different results, according to who I ask! But an address is context-independent, and will always refer to the same location. (Of course, what is in that location might change over time.)
|What an object is or does||How to find it|
|May be human-friendly format||Often detailed and difficult to read|
|Long-lasting||Transient, may change for a given object|
|Must be resolved via a naming service||Allows direct access|
|Referenced location can be changed at the naming service||Must be changed at every point of use|
A context is something that provides a mapping from names to objects. For example, a directory in a filesystem is a context that maps from filenames to file and directory objects. Contexts may provide a variety of operations for using or managing the mapping from names to objects. For example, one can create subdirectories of a directory, add or remove files, etc. Here are some examples of naming contexts:
|Example Context||Example Names||Extra Services Examples|
|Create or read symbolic links|
Set access privileges
|LDAP Directory||cn=Phillip Eby,o=eby-sarna.com|
|Store data associated with names|
Search for objects based on associated data
|Multiple records per name|
Different contexts follow different naming conventions and syntax for their names. As you can see from the examples, these conventions and syntax can vary considerably. DNS names, for example, are hierarchical from right to left, with the name parts separated by dots. UNIX filesystem names, on the other hand, are hierarchical from left to right, and use '/' as a separator. Some naming systems are "flat", and do not have a hierarchy or separators at all.
A set of conventions for naming, and the contexts that implement those conventions, are called a naming system. Naming systems that use hierarchical names can have contexts contained in other contexts, in the sense that a /usr/bin directory can be contained inside a /usr directory.
While most naming systems are quite useful by themselves, it is also often useful to combine them. For example, you are probably accessing this page via a combination of a DNS name (peak.telecommunity.com) and a filesystem name (/DevCenter/NamingSystem). Names which incorporate parts from more than one naming system are called composite names, and the process of combining naming systems is called federation.
Hierarchical, path-like names are called compound names
Interoperability note: although PEAK uses very similar terminology, concepts, and even interfaces to JNDI, CORBA Naming, and other similar standards, it does not provide any actual implementation code to talk to providers of these other services. The good news is that, given the close similarity in interfaces, writing an adapter to expose JNDI or CORBA naming services to the PEAK naming framework should be very straightforward, should the need arise.
In practice, it's unlikely that such adaptation will be useful outside of enterprises where such naming services are already deployed, and if they are already deployed, the odds that the environment is a candidate for use of PEAK seem rather low. In any event, for PEAK's primary authors, actual interfacing with CORBA or JNDI is of negligible utility.
JNDI features not present in PEAK
PEAK features not present in JNDI
PEAK's naming system offers a functional superset of the CORBA naming service interfaces. The primary differences are: