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
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

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