Functional Requirements

Functional requirements describe what the system should do. It is important, in this phase, to avoid mentioning how the system should do something. Each requirement is identified with a label Fi and a priority level is associated to it; in some cases a note will be appended to add information about the requirement.

F1 The RCS shall allow clients to maintain consistency among replicated files. To

this purpose, it must be able to propagate update information and apply them to all the replicas of a a logical file.

• Priority: High.

• Notes: This is the main requirement, for flat files. The synchronisation

of files is triggered by a user request on all the replicas of a given logical file. A requirement for an automatic procedure to synchronise replicas with a given periodicity has a low priority.

F2 The RCS shall allow clients to maintain consistency among replicated hetero-

geneous relational databases.

• Priority: High.

• Notes: This is the main requirement, for relational databases. For databases,

on demand synchronisation and automatic synchronisation, with a user- defined periodicity must be provided.

F3 Strict consistency is generally not needed, lazy algorithms must be preferred

(see Section 3).

• Priority: High.

• Notes: The details about the algorithm that will be used for Update Prop-

agation (UP) is not important in this phase. For flat files a synchronous approach will also be provided, but with a low priority.

F4 The RCS shall allow clients to specify a quorum value for an update operation.

• Priority: High.

• Notes: This is a requirement that deals with the possibility of having

some replicas unavailable at the time an update operation is done. The quorum is the minimum number of available replicas required for an up- date operation.

F5 The RCS shall allow clients to retrieve the list of up-to-date replicas of a logical

dataset and the update status of all the replicas of the dataset.

• Priority: High.

• Notes: A replica can be stale with respect to some other replicas of the

same logical dataset when an update operation is running (not yet com- pleted) or when such a replica is unreachable. In order to avoid stale reads the user must be able to retrieve update information about the replica that he wants to access.

F6 The RCS shall allow clients to check the status of an update operation.

• Priority: High.

• Notes: When a user requests an update operation, he must be able to

6.2. Requirements 87

F7 For flat files, the RCS shall work independently from the Replica Management

Service (RMS).

• Priority: High.

• Notes: We will start designing the system to work independently from

the RMS. The integration with a RMS will have a low priority.

F8 The RCS shall allow privileged users to register/unregister logical datasets as

well as their replicas, putting them under or removing them from the RCS control.

• Priority: High.

• Notes: The RCS maintains consistency only of those replicas that have

been previously registered to it.

F9 The RCS shall allow privileged users to set the UP protocol and its details, if

any, but, at any time, there can only be one active protocol responsible for all the datasets and all the update operations (one-for-all).

• Priority: High.

• Notes: The consequences of a change of protocol when some update

operations are still running must be considered.

F10 The UP protocol can be different for different types of dataset (one-per-dataset-

type).

• Priority: Low.

• Notes: At a certain point in time the RCS can use a protocol to update

flat files and a different one to update databases.

F11 The RCS shall allow different UP protocols to be used by different VOs (one-

per-VO).

• Priority: Low.

• Notes: Assuming that the RCS is unique in a Grid architecture, and serves

different VOs, it must be able to use different UP protocols for different VOs. The feasibility of using different UP protocols at the same time needs to be evaluated.

F12 The RCS shall allow clients (or privileged users) to set/change the UP protocol

of a logical dataset: the protocol will act in the same way for all the update operations concerning a logical dataset (one-per-dataset).

• Priority: Low.

F13 The RCS shall allow clients to choose the UP protocol of any update operation

(one-per-operation).

• Priority: Low.

• Notes This is a very complex case that needs to be refined.

F14 The RCS shall allow an external monitoring system to retrieve useful data

about the consistency of replicated data.

• Priority: Low.

• Notes: We have to provide the system with proper methods that can be

used by a monitoring system for retrieving status information about the service. The integration with a specific monitoring system must still be defined.

F15 The RCS shall allow privileged clients to choose an update mechanism.

• Priority: Low.

• Notes We will start with a fixed update mechanism, that is log based for

databases and file replacement for flat files.

F16 For flat files, the RCS shall work with Replica Management Service (RMS).

• Priority: Low.

• Notes: We will start designing the system to work independently from

the RMS. The integration with a RMS will have a low priority.

Requirements F9 through F13 define the flexibility/configurability of the proto- col, specifying different numbers of degrees of freedom.

Requirement F9 is the less flexible in that it provides a fixed protocol to deal with the consistency of all the datasets. It is likely that more flexibility will be required, for example, to use a different protocol for files and databases (Requirement F10). Requirement F11 instead would allow different VOs to set their own protocol; this flexibility level could be useful in case VOs can be logically grouped basing on their

6.2. Requirements 89

RCS usage pattern. Increasing again the degree of flexibility, Requirement F12 could allow privileged users to choose the best protocol for each logical dataset; some ser- vice clients could need to use different protocols for different datasets, in case the requirements in terms of consistency is logically bound to the semantics of the data. Requirement F13 is at the other extreme in terms of flexibility: in this case even the same file can be treated differently depending on some dynamic criteria like the user requesting the operation or the execution time of the operation. In Figure 6.1 these different approaches are ordered along a flexibility axis.

In case a protocol is bound to a VO, to a dataset or to a dataset type, it should be clarified whether this association can change over time. This case could present some issues when a protocol change overlaps some update operations involved with the change.

At the beginning, we decided to focus our attention on the simplest case, that is Requirement F9.

Protocol flexibility

− +

one−per−dataset one−per−operation

one−for−all one−per−dataset−type one−per−VO

Figure 6.1: Flexibility provided by different consistency protocol setups The functional requirements are summarised in Table 6.1.