Diff for "NamingSystem" - The PEAK Developers' Center

Differences between version dated 2002-12-13 14:51:20 and 2007-03-25 22:33:58 (spanning 13 versions)

Additions are marked like this.

= An Introduction to PEAK Naming Services =

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

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.

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 client for "spam" will produce very different results. But an address is context-independent, and will always refer to the same location, although what is in that location might change over time.[[BR]][[BR]]

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.)[[BR]][[BR]]

||Referenced location can be changed at the naming service||Must be changed at every point of use||

||LDAP Directory||`cn=Phillip Eby,o=eby-sarna.com`[[BR]]`cn=Copier,ou=Accounting Department,o="BigCompany, Inc."`||Store data associated with names[[BR]]Search for objects based on associated data||

||LDAP Directory||`cn=Phillip Eby,o=eby-sarna.com`[[BR]]`cn=Copier,ou=Accounting,o="BigCompany, Inc."`||Store data associated with names[[BR]]Search for objects based on associated data||

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 (`/DevGuide/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'''.

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

== The peak.naming package ==

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

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

=== Other Tools & Systems ===

* The [http://java.sun.com/products/jndi/tutorial/getStarted/concepts/glossary.html 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.