Table 4 ‘Data replication service’ use case requirements
Architecture Core | ‘Data Replication Service’ |
|---|---|
Building Block | Stakeholder Requirements |
Mature and | (R1) The technology required |
Extensible | must be mature to guarantee |
Storage | a highly available and robust |
Technology | service. |
(R2) CCSMs need to have | |
functionality which data objects | |
and collections need replication. | |
(R3) A policy-based feature | |
enables that all centers can be | |
audited (e.g. DSOA) in order | |
to establish trust with clearly | |
described policy rules. | |
(R4) Powerful policy functions | |
are required to enable CCSMs | |
to specify M replicas to be | |
stored for N years. | |
Persistent | (R5) Each data object in the |
Identifier | data infrastructure should |
Service | have a clearly assigned PID |
(R6) The use of PIDs for | |
replicated data objects enables | |
CSMs to know whether the | |
replicas are identical | |
with the source. | |
Monitoring | (R7) The infrastructure |
Service | services must be monitored |
in order to obtain information | |
about their production status. | |
Federated | (R8) CCSMs need replicas to be |
AAI | accessible by users while |
APIs | maintaining the access |
permissions as defined by the | |
originating community center. | |
Local | (R9) The storage technology |
Long-term | should require as little changes |
Archiving | as possible on the community data |
organization side that is already | |
established around the local LTAs. | |
Common | (R10) Ticketing service and |
Services | help desk support should be |
established for end-users. | |
Web-based | (R11) Virtual workspaces making |
Workbench | the services accessible to users. |