System and method for performing lookups across namespace domains using universal resource locators

#Naming services and directory services provide a way of identifying and associating names with data. Similarly, naming and directory services may also be used for referencing data and data locations using more easily comprehendible names. For example, NIS and NIS+ are naming services developed by Sun Microsystems for allowing users to access files and applications on any NIS host using a single login name and password. DNS, an Internet naming service, associates people-friendly names with computer network addresses. Additional naming and/or directory services include LDAP (Lightweight Directory Access Protocol), NDS (Novell Directory Services), and COS (Common Object Services). While normally having similar basic functionality, each naming or directory service may specify its own protocols, syntax, nomenclature, naming conventions, etc. When a naming service is implemented in accordance with such specifications, the implementation is often referred to as a namespace. For example, a person using a web browser on a personal computer to access a web page via a friendly DNS name (i.e. www.widgetcompany.com), is considered to be utilizing the DNS namespace.

#Application programming interfaces (“APIs”) such as the Java Naming and Directory Interface (“JNDI”) provide an interface for communication between namespaces. For example, where namespace A and namespace B have been implemented in accordance with JNDI, a request for data from namespace B by a host in namespace A may be satisfied without requiring the host to be configured as a node of namespace B. Likewise, a request for data from namespace A by a host in namespace B may be satisfied without requiring the host to be configured as a node of namespace A. However, inter-namespace data exchange APIs such as JNDI require that a request for data from a foreign namespace by a host in a local namespace include specific location/naming information. Solutions have been offered that require special mechanisms within a naming service itself to create, recognize, and traverse federated junctions between namespaces, however such solutions require participation by the naming service and are therefore limited to naming services that implement identical federation schemes.

#A system and method for performing a lookup in a second namespace, the lookup being performed from a first namespace, whereby a component performing the lookup is not required to be configured for performing a lookup in the second namespace, the system and method further comprising: parsing a first lookup request for a URL tag, the first lookup request for an object located in the second namespace, the lookup request including a symbolic name corresponding to a target location in the second namespace, the URL tag corresponding to a URL context; searching the URL context for a provider URL corresponding to the symbolic name; and creating a second lookup request, the second lookup comprising the provider URL and the object's name.

#FIG. 1 shows the flow of an exemplary lookup request across namespaces.

#FIG. 2 is a continuation of FIG. 1 and shows the flow of an exemplary lookup request across namespaces.

#FIG. 3 shows an exemplary system for performing a lookup request across namespaces.

#In an exemplary embodiment, the invention is used in conjunction with naming services that support namespace lookups via universal resource locators (URLs) and that include a mechanism for delegating namespace requests to a third party provider. For purposes of explanation and example, the embodiments of the invention are described in conjunction with the JNDI SPI/API to satisfy these requirements. It is understood that the invention may be implemented in conjunction with any namespace API/SPI or similar mechanism known to one of ordinary skill in the art without exceeding the scope of this disclosure. While JNDI itself describes the use of URLs in lookup names, this usage incorporates explicit network location information in the URL itself. An embodiment of the invention uses only symbolic names in a federation URL that is mapped locally within the local namespace to the actual network location information, to achieve namespace federation. This provides for the insulation of applications from namespace reconfiguration and changes to topography by prescribing a method to map the application's lookup name to the actual lookup name. Moreover, the an embodiment of the invention advantageously allows programming model neutrality by prescribing a method to map the facilities of a particular naming system to the underlying naming interface (JNDI, for example) without requiring an additional API set that is separate and distinct from the underlying naming interface API set. This provides for federation without the need for disparate namespaces to explicitly participate in a federation scheme.

#JNDI provides a NamingManager that manages naming context creation. Naming contexts are the programming implements used to perform namespace operations, such as lookup and bind. Actual naming contexts are produced by context factories, which are registered with the NamingManager. As prescribed by JNDI, there are both regular and URL (universal resource locator) contexts and context factories. The JNDI NamingManager, using a context factory registered specifically for the purpose of creating regular naming contexts, creates regular naming contexts. Instantiating a new InitialContext object creates a regular naming context in the Java programming language. All JNDI contexts must support URL composite name syntax. This syntax is of the form:

#URL_TAG:<location-information>/<JNDI-name>