Mechanisms to support multiple name space aware projects

• US 8,341,190 B2
• Filed: 08/05/2008
• Issued: 12/25/2012
• Est. Priority Date: 08/05/2008
• Status: Active Grant

• Current Assignee: Emc IP Holding Company LLC (Dell Technologies Inc.)
• Original Assignee: EMC Corporation (Dell Technologies Inc.)
• Inventors: Lowry, Lee Edward, Scheuber-Heinz, Volker Gunnar, Street, William, Thurgood, Brent, Vasudevan, Rajesh, Cox, Ryan, Carter, Stephen R
• Primary Examiner(s): REYES, MARIELA D
• Application Number:
  US12/186,166
• Publication Number:
  US 20100036870A1
• Time in Patent Office: 1,603 Days
• Field of Search: 707/796, 707/804
• US Class Current: 707/796
• CPC Class Codes: G06F 16/289 Object oriented databases
• CPC Class Codes: G06F 8/20 Software design

Abstract

Mechanisms to support multiple name space aware projects are provided. Multiple roots of a project declare multiple namespacing mechanisms. Resources of the project can utilize each of the multiple namespacing mechanisms. In some cases, a particular resource of the project can override and use a foreign namespace that is associated with a different project hierarchy even while that particular resource resides within a project hierarchy associated with the original project and even while the project hierarchy does not declare, at the root, the foreign namespace.

Claims

1. A method for supporting multiple namespaces, comprising:

recognizing at a root of a project hierarchy of a project a first namespace root object declaration, the first namespace root object declaration defining a first namespace associated with said project;

recognizing within said project hierarchy a second namespace root object declaration defining a second namespace associated with said project;

supporting first objects declared under the first namespace root object declaration of the project hierarchy within the first namespace, the first namespace having its own data storage conventions and interfaces, the first objects are associated with the first namespace by being organized under the first namespace root object and the root objects are not stamped with any particular namespace;

supporting second objects declared under the second namespace root object declaration of the project hierarchy within the second namespace, the second namespace having its own data storage conventions and interfaces that are different from the first namespace, the second objects are associated with the second namespace by being organized under the second namespace root object and the second objects are not stamped with any particular namespace; and

managing the first objects as a first sub-project hierarchy within the project hierarchy and the second objects as a second sub-project hierarchy within the project hierarchy, wherein structure is shared within the project hierarchy but the first and second namespaces are different from one another.

2. The method of claim 1 further comprising, maintaining the first namespace root object declaration and the second namespace root object declaration as separate independent containers for storage and retrieval of the first objects and second objects within the project hierarchy.

3. The method of claim 1 further comprising, identifying a particular first object that declares a foreign namespace that is different from the first namespace and the second namespace and that is associated with a different project hierarchy and a different project.

4. The method of claim 3 further comprising, dynamically deploying the particular first object to the foreign namespace via a foreign namespace specification that provides a mechanism for deployment to the foreign namespace.

5. The method of claim 1, wherein recognizing the second namespace root object declaration further includes permitting the second namespace root object declaration to be referenced and declared within the project hierarchy as a second project having a different project hierarchy from the project hierarchy and having the second namespace.

6. The method of claim 1 further comprising, storing content data associated with the first objects and the second objects in a data storage repository that is independent of the first namespace and the second namespace, and dynamically using a first namespace specification and a second namespace specification to retrieve and render the content data, when accessed during the lifecycle of a project, to the first and second namespaces from the data storage repository.

7. A machine-implemented system, comprising:

a project model for a project implemented in a machine-accessible and computer-readable storage medium and accessible to services that process on a machine of a network; and

a generic project manager implemented in a machine-accessible and computer-readable storage medium and to process on the machine or a different machine of the network;

wherein the project model is organized as an object hierarchy, each object representing a resource of the project, and wherein multiple independent namespaces are declared as objects within the object hierarchy and are associated with said project, and the generic project manager selectively loads resources to the multiple namespaces in response to the object hierarchy, each namespace having its own data storage conventions and interfaces, and each object is not stamped with any particular namespace, rather each object is assigned to a given namespace based on its organization under a particular namespace object within the object hierarchy, the objects assigned to said namespaces being managed within different sub-project hierarchies within said project model; and

a data storage repository that is independent of said multiple namespaces for storing content data associated with said multiple objects.

8. The system of claim 7, wherein at least one object is defined within the object hierarchy as a reference to a different project model having a different object hierarchy and being associated with a different particular namespace.

9. The system of claim 7, wherein particular resources associated with a particular namespace are declared within the object hierarchy following a particular object.

10. The system of claim 7, wherein the generic project manager permits each resource defined within the object hierarchy to override its namespace assignment and be used with a different namespace.

11. The system of claim 7, wherein the generic project manager requests an external generic project manager to deploy a particular resource to a particular namespace when that particular resource borrows structure and the particular namespace from a different project model associated with a different object hierarchy.

12. The system of claim 7, wherein the generic project manager uses translation utilities to permit each of the resources to be moved and used between the multiple namespaces within the object hierarchy.