1. Terms

2. Requirements

1. Atomic operations - There are no rollbacks. Every operation is either successful or failed.

• Each operation involving file and file instance creation and deletion should involve one one request

2. All operations must have timeout. Timeout should be given either as total timeout or as transfer speed limit (adaptive timeout).

3. Service ownership - interoperating SE and NI can belong to different VOs. NI and SE can server multiple VOs.

4. In first implementation NI is centralized (per VO, experiment,etc.). This requires flexible authorization rules.

5. There is no limit on number of interoperating NIs and SEs. UT should be able to communicate with multiple NIs.

6. NI registers to MDS (or any other Information System) and provides information about served VOs.

7. SE registers to MDS (or any other Information System)and provides information about served VOs and subtrees (see below).

3. Scenarios

1. Creation of new file.

• Registration of already existing instance (should be used only in extreme cases).

1. UT contacts NI and provides all metadata necessary to create file

• File instance is uploaded to SE.

1. UT contacts SE to reserve place and provide file's metadata to be passed to NI

2. SE contacts NI to register new file and it's instance as not ready yet

3. UT uploads file to SE

4. SE marks instance in NI as ready to be used

• File instance is downloaded from third place.

1. UT contacts SE and provides file's metadata and URL for source

2. SE registers new file and it's instance as not ready yet in NI

3. SE downloads file instance from provided URL

4. SE marks downloaded instance in NI as ready to be used

• Replication (creation) of file instance. Replications are made by SEs on request from UT or initiated by local policies.

1. UT contacts SE and provides name of file to be replicated to that SE

2. SE contacts NI to obtain information about available instances

3. SE registers new instance as not ready yet in NI

4. SE downloads file

5. SE marks downloaded instance in NI as ready to be used

• Deletion of file instance

1. UT contacts SE and provides name of file to be deleted.

2. SE removes instance and contacts NI to unregister instance

• Deletion of file.

1. UT contacts NI to obtain information about all instances.

2. UT contacts all SEs and deletes instances

• Accessing file instance.

• Through MDS

1. UT searches in MDS for suitable NI.

2. UT contacts NI to obtain list of SEs and optionally handles of those instances

3. UT contacts SE to obtain handle (if not available yet) and uses it to access file instance.

• Through NI directly

1. Same as through MDS with first step skipped (assuming UT already knows URL of NI).

• Through MDS with dead NI

1. UT searches in MDS for suitable NI.

2. UT fails to contact NI.

3. UT search in MDS for suitable Ses.

4. UT contacts SEs asking for full file name.

5. UT uses obtained handles to access file instances.

• Accessing non-existing file instance.

1. UT knows about super-fast local SE.

2. UT contacts that SE and asks for replication of file instance.

3. Either SE does not respond to UT's request till replication is finished or UT checks for completion periodically (both ways should be possible).

4. SE

For each instance stored at SE following information is stored:

• Full name of file

• Minimal amount of metadata needed to check authenticity of file

• Status of file (being uploaded, being downloaded, in use, ready, ...)

• SE can be implemented either to contact NI to check if file can be accessed by UT or to keep such information locally. In later case such information should be periodically synchronized with NI.

Each file instance has corresponding handle (URL) generated by SE. UT obtains such handle from querying SE for full file name or from NI. This handle is used to access file instance.

SE service is responsible of refreshing information in NI. Deleting temporary files. Caching files on request

5. NI

NI can serve different VOs. Each VO has directory-like structure of objects. Tree consists of objects Group (directory). Groups contain other Groups and

• SE - description of SE accepting file instances belonging to this group and all subgroups (served subtree). It can contain following attributes:

• Restrictions on served files (to be defined, for example it could store only content not longer than 1GB)

• Restriction on served users (like if ordinary member of is allowed to created temporary instance).

• Optional name of SE. If defined SE can be mentioned in other objects by it's name.

• Instance - URL of SE storing instance of file, optionally URL of file instance, metadata related to instance:

• DN of user or service which requested creation of that instance

• Status of that instance (being prepared, ready to be used, temporary, primary, etc.)

• External instance - URL of file instance stored at some place which has no SE's capabilities (should be used only in extreme cases).

• DN of user or service which requested creation of that instance

• Virtual instance - contains instructions on how to create content of file. Most probably it should consist of RSL and contact person (DN + email) who created that RSL.