The PEAK Developers' Center   NamingSystem UserPreferences
 
HelpContents Search Diffs Info Edit Subscribe XML Print View

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

NamesAddresses
What an object is or doesHow to find it
May be human-friendly formatOften detailed and difficult to read
Long-lastingTransient, may change for a given object
Must be resolved via a naming serviceAllows direct access
Referenced location can be changed at the naming serviceMust be changed at every point of use
Context-sensitiveContext-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 ContextExample NamesExtra Services Examples
Filesystem/usr/bin
/home/somebody/foo
Create or read symbolic links
Set access privileges
LDAP Directorycn=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
DNScvs.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 features not present in JNDI

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:

1.4.3 Other Tools & Systems

urllib, ?

1.5 Related Links

 

PythonPowered
EditText of this page (last modified 2007-03-25 22:33:58)
FindPage by browsing, title search , text search or an index
Or try one of these actions: AttachFile, DeletePage, LikePages, LocalSiteMap, SpellCheck