NamingSystem

UserPreferences

1 An Introduction to PEAK Naming Services

Abstract

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

1. An Introduction to PEAK Naming Services
1. Naming Concepts
1. Names vs. Addresses
2. Contexts, Naming Systems, and Federation
3. Compound and Composite Names
2. The peak.naming package
3. Use Cases
4. Competitive Analysis
1. JNDI
2. CORBA Naming Service ("CosNaming")
3. Other Tools & Systems
5. Related Links

1.1 Naming Concepts

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.

1.1.1 Names vs. Addresses

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.)

Names	Addresses
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
Context-sensitive	Context-independent

1.1.2 Contexts, Naming Systems, and Federation

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
Filesystem	/usr/bin /home/somebody/foo	Create or read symbolic links Set access privileges
LDAP Directory	cn=Phillip Eby,o=eby-sarna.com cn=Copier,ou=Accounting,o="BigCompany, Inc."	Store data associated with names Search for objects based on associated data
DNS	cvs.eby-sarna.com peak.telecommunity.com	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.

1.1.3 Compound and Composite Names

Hierarchical, path-like names are called compound names

XXX etc...

1.2 The peak.naming package

1.3 Use Cases

1.4 Competitive Analysis

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.

1.4.1 JNDI

JNDI features not present in PEAK

• PEAK contexts can only iterate their own contents, not the contents of their subcontexts. So where in JNDI you would say aContext.listBindings(nameOfSubcontext), in PEAK you would say aContext.lookup(nameOfSubcontext).items(), or aContext[nameOfSubcontext].items(). This is an intentional simplification that makes it easier to implement naming contexts, and is more in keeping with Python idioms for working with name-to-object mappings.
• An equivalent to JNDI's Directory package is not currently available. This means that PEAK doesn't supply much LDAP-specific naming functionality as yet. (Or NDS, or MSDS, or x.500, or similar naming systems.) We intend to supply some simple LDAPv2-related functionality going forward; more advanced features like controls and LDAP schemas will have to be contributed by others, until/unless we come across a need for this in our work.
• An equivalent to JNDI's Event package is not available, and we don't currently have any plans to add one. We'd consider any contributions in this area, but it's a very specialized thing. We'd rather see it integrated as part of peak.events, rather than as a rarely-useful one-off for the naming package.

PEAK features not present in JNDI

• PEAK uses configuration properties to look up URL scheme providers, making it easier to support schemes supplied from a variety of sources; by contrast, JNDI requires specification of paths from which it will try to import providers based on a standardized name mangling. PEAK lets you simply point individual schemes to a provider.
• Where JNDI uses a specialized configuration system just for naming services, peak.naming shares a configuration system with the rest of the PEAK framework. Thus, you can use any application component to supply a "parent environment" for a naming context, and many of PEAK's binding and configuration tools will handle this for you automatically.
• Object factories are also located using the configuration system, which can be used to override the choice of class names found in Reference objects.
• PEAK includes a convenient modelling framework for implementing new URL types, that automatically handles most simple URL parsing and formatting tasks.
• PEAK provides simple shortcuts to look up names without requiring you to manually create an ?InitialContext, the way you do in JNDI. These shortcuts are also integrated with the peak.binding package, so that you can link object attributes to arbitrary name lookups. For example, a component class that needs access to a particular database via a name lookup, can simply define an attribute as binding.Obtain("name_of_database"). These features allow for dramatically improved ease-of-use over JNDI.
• PEAK includes easy-to-extend base classes for creating contexts that handle composite/compound names and URLs automatically. Other included base classes support parsing of specialized URL types. By comparison, JNDI effectively requires you to build contexts and URL handlers from the ground up, while rewriting large quantities of essentially boilerplate code.

1.4.2 CORBA Naming Service ("CosNaming")

PEAK's naming system offers a functional superset of the CORBA naming service interfaces. The primary differences are:

• CosNaming only supports compound names and URLs; PEAK, like JNDI, also supports composite names.
• CosNaming defines specialized variants of the bind() and rebind() context methods specifically for placing contexts inside of contexts (bind_context() and rebind_context()), as well as offering a method to create an anonymous new context object. PEAK follows the JNDI approach in these areas, permitting bind() and rebind() to accept objects of any kind, and only allowing named subcontexts to be created via the context interface, rather than allowing creation of arbitrary anonymous detached contexts.
• CosNaming is an interface specification; PEAK offers both interfaces and reusable base classes that supply most of the "boilerplate code" needed for implementation.
• CosNaming has some specialized, CORBA-specific URL and name syntaxes defined; for example, name parts have both a "kind" and an "id". These are not built-ins for PEAK, but would probably be straightforward to implement over its base classes and utility functions, if needed.

1.4.3 Other Tools & Systems

urllib, ?

1.5 Related Links

• The JNDI Tutorial's Glossary is a good vocabulary of naming system terminology; the terms that aren't specific to LDAP or Java are applicable to peak.naming as well.