This wiki has undergone a migration to Confluence found Here
Difference between revisions of "Shared Artifact Repository - Architectural Principles"
Jump to navigation
Jump to search
| (One intermediate revision by the same user not shown) | |||
| Line 25: | Line 25: | ||
=Items for Consideration= | =Items for Consideration= | ||
Architectural Principles Underlying a Shared Artifact Repository include: | Architectural Principles Underlying a Shared Artifact Repository include: | ||
| − | * The focus should be on the critical capabilities to register artifacts and postpone the other features that a Shared Artifact Repository enables | + | * The focus should be on the critical capabilities to register artifacts and postpone the other features that a Shared Artifact Repository '''enables''' |
* Shared Artifact Repository should consider applicability of existing open source and commercial products | * Shared Artifact Repository should consider applicability of existing open source and commercial products | ||
| + | * A critical design principle will be to recognize the essential capabilities of a registry and distinguish from those additional capabilities that add value to many different processes. | ||
* Core requirements will be identified first and then those that are desirable but may be added on later to meet the more sophisticated requirements | * Core requirements will be identified first and then those that are desirable but may be added on later to meet the more sophisticated requirements | ||
* Identify support and configuration requirements | * Identify support and configuration requirements | ||
Latest revision as of 14:34, 9 September 2010
Background
- Opened during Tooling Conference Call on August 26,2010
- Goal a draft for presentation at OHT Board Meeting 9/30 or 10/1 (Dues date around 9/23)
Description from Tooling Investment Strategy (from 2009)
- Artifact Search and Select
- Query capability to return a set of artifact data based on selected meta-data matches
- Difference++
- User Authentication
- Artifact Management Control
- Artifact Metatdata Manager
- Document artifact content and relationships
- Artifact Identity and Version-Data Manager
- Does not do Version Management, but does know same
- Can accept externally defined Identities or create new ones when required (next)
- Unique Identifier Generator (OID registry ability)
- Artifact Synchronizer++
- Artifact Importer
- Package Assembler
- Artifact Exporter
- Representation Transformer
- Artifact Importer
- Artifact Metatdata Manager
- APIs For other services such as the dependent functions (++ above)
++ Are function that depends upon (Needs, is dying for) a SAR, but is not part thereof
Items for Consideration
Architectural Principles Underlying a Shared Artifact Repository include:
- The focus should be on the critical capabilities to register artifacts and postpone the other features that a Shared Artifact Repository enables
- Shared Artifact Repository should consider applicability of existing open source and commercial products
- A critical design principle will be to recognize the essential capabilities of a registry and distinguish from those additional capabilities that add value to many different processes.
- Core requirements will be identified first and then those that are desirable but may be added on later to meet the more sophisticated requirements
- Identify support and configuration requirements
- Open Source software preferable, weighing the maintenance history and commitment of the community
- Requirements will be met iteratively, with multiple planned releases
- Software should be architected to easily support extensibility without disrupting initial deployments
