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
| 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: | ||
| + | * Shared Artifact Repository should conside applicability of commercial products | ||
| + | * Identify core requirements and those that are | ||
Revision as of 14:33, 2 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:
- Shared Artifact Repository should conside applicability of commercial products
- Identify core requirements and those that are
