System and method for immutably storing electronic assets in a large-scale computer system

• US 20070260620A1
• Filed: 04/26/2007
• Published: 11/08/2007
• Est. Priority Date: 05/05/2006
• Status: Active Grant

• Current Assignee: Business Performance Systems, Leidos Innovations Technology, Inc.
• Original Assignee: Business Performance Systems, Lockheed Martin Corporation (Martin Marietta Corporation)
• Inventors: Ripley, Rodney, Isaac, David, Smolen, Richard, Earman, Daniel
• Granted Patent: US 7,711,703 B2
• Time in Patent Office: Days
• US Class Current: 1/1
• CPC Class Codes: G06F 16/2308 Concurrency control transaction processing G06F9/466
• CPC Class Codes: Y10S 707/948 Product or catalog
• CPC Class Codes: Y10S 707/99953 Recoverability

Abstract

Systems and/or methods for storing and/or retrieving assets in connection with an extremely large scale computer storage system are provided. An asset catalog may comprise a plurality of asset catalog entries stored according to at least one schema and corresponding to a plurality of assets. A storage architecture may be capable of storing the plurality of assets, with the storage architecture comprising a storage locator and a federator. An item identification scheme may be capable of providing identifiers to reference, locate, and/or access said assets and/or said asset catalog entries stored in the asset catalog in the storage architecture. The computer storage system may be scalable essentially without limitation while maintaining asset storage and retrieval flexibility and substantially obsolescence-proof survivability of assets.

Claims

1. A storage architecture for use with an extremely large scale computer storage system, comprising:

at least one storage location capable of storing a plurality of assets and/or a plurality of asset catalog entries corresponding to the plurality of assets;

an object identification service to provide immutable and scalable identifiers for each said asset and each said asset catalog entry;

a storage locator including a mapping database to map assets and/or asset catalog entries to the at least one storage location; and

a federator,

wherein the storage architecture is scalable essentially without limitation while maintaining asset storage and retrieval flexibility and substantially obsolescence-proof survivability of assets.

2. The storage architecture of claim 1, wherein the at least one storage location is arranged such that the asset catalog entries are stored near to their corresponding persisted assets.

3. The storage architecture of claim 1, further comprising at least two storage locations, a first storage location to store aggregate-level asset catalog entries and a second storage location to store item-level assets catalog entries.

4. The storage architecture of claim 1, wherein the at least one storage location comprises a file system, a relational database, and/or an object database.

5. The storage architecture of claim 1, wherein the at least one storage location includes a plurality of storage units and/or sets of storage units, each said asset and asset catalog entry being storable in at least one storage unit or storage unit set.

6. The storage architecture of claim 1, wherein each asset catalog entry is an XML document.

7. The storage architecture of claim 1, further comprising at least two storage locations, each to store the same asset catalog entries and/or assets to provide redundancy for performance, availability, and/or recoverability for the assets and/or asset catalog entries.

8. The storage architecture of claim 1, wherein the assets and/or asset catalog entries are mappable to at least one storage location based at least in part on metadata associated with the respective asset or asset catalog entry and/or configurable mapping rules and/or persisted storage patterns.

9. The storage architecture of claim 1, further comprising a clustering subroutine and/or a caching subroutine configured to improve the performance of the search and access interface.

10. The storage architecture of claim 1, wherein the federator is configured to transparently access a plurality of storage locations of the storage architecture irrespective of a storage implementation associated with a particular storage location.

11. The storage architecture of claim 1, wherein the federator and/or storage locator are configured to implement structured identifiers to enable transparent partitioning and federation of storage subsystems.

12. The storage architecture of claim 1, wherein the storage locator is configured to map at least some of the assets and/or asset catalog entries to multiple locations to improve access performance and/or availability.

13. The storage architecture of claim 12, wherein the storage locator is configured to receive metadata, structured identifier, and/or Universal Resource Identifier qualifier input(s) to locate, access, and/or reference assets and/or asset catalog entries persisted in the at least one storage location.

14. The storage architecture of claim 1, wherein the identifiers are provided according to an immutable identification scheme.

15. The storage architecture of claim 14, wherein the identifiers are structured to map identifiers to physical storage locations of the asset catalog and/or storage architecture.

16. The storage architecture of claim 14, wherein the identifiers are universally unique such that relations among and/or between the asset catalog entries and/or relations to one or more components comprising a particular asset optionally can span multiple storage partitions and/or instances of a federation.

17. The storage architecture of claim 14, wherein the identifiers include two types of identifiers to reference, locate, and/or access said assets and/or said asset catalog entries, the first identifier type being an asset identifier (AID) type and the second identifier type being a Universal Resource Identifier (URI) type.

18. The storage architecture of claim 17, wherein each said AID is a multipart identifier.

19. The storage architecture of claim 18, wherein each said AID is indicative of a registry, package, part, and item associated with the corresponding asset.

20. The storage architecture of claim 19, wherein the item name is unrelated to an original filename of the item, and wherein the original filename and corresponding directory structure is stored as metadata within a corresponding asset catalog entry.

21. The storage architecture of claim 17, wherein each said AID is defined during asset ingest and before a final storage allocation of the storage architecture.

22. The storage architecture of claim 17, wherein each said URI is a standards-based identifier useful for referencing and/or accessing the asset and/or asset catalog entry.

23. The storage architecture of claim 17, wherein each said URI is changeable over time.

24. The storage architecture of claim 17, wherein each said URI is assigned independent of storage of the corresponding asset and/or asset catalog entry.

25. The storage architecture of claim 17, wherein each said URI is structured as:

<

scheme>

;

//<

authority>

/<

path>

?<

query>

#<

fragment> and

wherein the path includes standardized elements.

26. The identification scheme of claim 25, wherein at least some of the standardized path elements are derived from the corresponding AID.

27. A computer-implemented method of maintaining a storage architecture for use with an extremely large scale computer storage system, the method comprising:

providing at least one storage location to store a plurality of assets and/or a plurality of asset catalog entries corresponding to the plurality of assets;

providing an object identification service to provide immutable and scalable identifiers for each said asset and each said asset catalog entry;

providing a storage locator including a mapping database to map assets and/or asset catalog entries to the at least one storage location; and

providing a federator,

wherein the storage architecture is scalable essentially without limitation while maintaining asset storage and retrieval flexibility and substantially obsolescence-proof survivability of assets.

28. The method of claim 27, further comprising arranging the at least one storage location such that the asset catalog entries are stored near to their corresponding persisted assets.

29. The method of claim 27, further comprising providing at least two storage locations, a first storage location to store aggregate-level asset catalog entries and a second storage location to store item-level assets catalog entries.

30. The method of claim 27, wherein the at least one storage location comprises a file system, a relational database, and/or an object database.

31. The method of claim 27, wherein the at least one storage location includes a plurality of storage units and/or sets of storage units, and further comprising storing each said asset and asset catalog entry in at least one storage unit or storage unit set.

32. The method of claim 27, wherein each asset catalog entry is an XML document.

33. The method of claim 27, further comprising providing at least two storage locations, each storing the same asset catalog entries and/or assets to provide redundancy for performance, availability, and/or recoverability for the assets and/or asset catalog entries.

34. The method of claim 27, further comprising mapping the assets and/or asset catalog entries to at least one storage location based at least in part on metadata associated with the respective asset or asset catalog entry and/or configurable mapping rules and/or persisted storage patterns.

35. The method of claim 27, further comprising providing a clustering subroutine and/or a caching subroutine.

36. The method of claim 27, further comprising transparently accessing, via the federator, a plurality of storage locations of the storage architecture irrespective of a storage implementation associated with a particular storage location.

37. The method of claim 27, further comprising enabling transparent partitioning and federation of storage subsystems via structured identifiers.

38. The method of claim 27, further comprising mapping at least some of the assets and/or asset catalog entries to multiple locations to improve access performance and/or availability.

39. The method of claim 38, further comprising receiving metadata, structured identifier, and/or Universal Resource Identifier qualifier input(s) to locate, access, and/or reference assets and/or asset catalog entries persisted in the at least one storage location.

40. The method of claim 27, further comprising providing the identifiers according to an immutable identification scheme.

41. The method of claim 40, further comprising structuring the identifiers to map identifiers to physical storage locations of the asset catalog and/or storage architecture.

42. The method of claim 40, wherein the identifiers are universally unique such that relations among and/or between the asset catalog entries and/or relations to one or more components comprising a particular asset optionally can span multiple storage partitions and/or instances of a federation.

43. The method of claim 40, further comprising including in each of the plurality of identifiers two types of identifiers to reference, locate, and/or access said assets and/or said asset catalog entries, the first identifier type being an asset identifier (AID) type and the second identifier type being a Universal Resource Identifier (URI) type.

44. The method of claim 43, wherein each said AID is a multipart identifier.

45. The method of claim 43, further comprising defining each said AID during asset ingest and before a final storage allocation of the storage architecture.

46. The method of claim 44, further comprising indicating in each said AID a registry, package, part, and item associated with the corresponding asset.

47. The method of claim 46, wherein the item name is unrelated to an original filename of the item, and further comprising storing the original filename and corresponding directory structure as metadata within a corresponding asset catalog entry.

48. The method of claim 43, wherein each said URI is a standards-based identifier useful for referencing and/or accessing the asset and/or asset catalog entry.

49. The method of claim 43, wherein each said URI is changeable over time.

50. The method of claim 43, further comprising assigning each said URI independent of the corresponding asset and/or asset catalog entry storage.

51. The method of claim 43, further comprising structuring each said URI as:

<

scheme>

;

//<

authority>

/<

path>

?<

query>

#<

fragment> and

including standardized path elements in each URI.

52. The method of claim 51, further comprising deriving at least some of the standardized path elements from the corresponding AID.