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
(New page: =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 Inv...) |
|||
| (6 intermediate revisions by 2 users not shown) | |||
| Line 4: | Line 4: | ||
=Description from Tooling Investment Strategy (from 2009)= | =Description from Tooling Investment Strategy (from 2009)= | ||
*Artifact Search and Select | *Artifact Search and Select | ||
| − | + | **Query capability to return a set of artifact data based on selected meta-data matches | |
| − | |||
| − | **Query capability to return a set of | ||
**Difference++ | **Difference++ | ||
*User Authentication | *User Authentication | ||
*Artifact Management Control | *Artifact Management Control | ||
**Artifact Metatdata Manager | **Artifact Metatdata Manager | ||
| + | ***Document artifact content and relationships | ||
***Artifact Identity and Version-Data Manager | ***Artifact Identity and Version-Data Manager | ||
****Does not <big>'''do'''</big> Version Management, but does know same | ****Does not <big>'''do'''</big> Version Management, but does know same | ||
| Line 22: | Line 21: | ||
*APIs For other services such as the dependent functions (++ above) | *APIs For other services such as the dependent functions (++ above) | ||
| − | ++ Are function that depends | + | ++ Are function that depends upon (Needs, is dying for) a SAR, but is not part thereof |
=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''' | ||
| + | * 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 | ||
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
