Diff for "NamingSystem" - The PEAK Developers' Center

Differences between version dated 2002-12-14 15:53:23 and 2007-03-25 22:33:58 (spanning 6 versions)

Deletions are marked like this.

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 '''object factories''' and '''state 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.bindTo()`. And, there are naming API functions like `naming.lookup()` which can be applied to any kind of name or 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.

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

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.

* Reference objects are replaced by the IAddress interface. This means you can't create multi-address references "out of the box"; but you can always supply your own IAddress implementation which contains multiple "real" addresses to try. This is an intentional change to make simple things simple; complex things are of course still possible.

* 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 a more general event handling framework for PEAK, than as a rarely-useful one-off for the naming package.

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

* 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 and state factories are also located using the configuration system (using `config.findUtilities()`), and can also be overridden with keyword arguments.

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

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

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

urllib, Zope 3 paths

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