Remote Storage Resource Management in WS-PGRADE/gUSE - Science Gateways for Distributed Computing Infrastructures - page 72

seeks for adaptor implementations on startup, and registers adaptors in the Adaptor
Registry . Adaptors are associated with the protocols they can handle; one adaptor
can support more than one protocol or storage resource, respectively.
Web service operation requests sent to the Blacktop use Uniform Resource
Identi

(files or folders). These resources are
of the form: protocol://host/path, where protocol speci

ers (URIs) to refer to storage resources (

es the protocol

used to communicate with the storage resource, host speci es the location of the

storage, and path speci file or a folder resides on the

storage. For example: gsiftp://gridftp.host.net/home/user/file.
dat refers to a

es the location where the

file.dat, in the subdirectory /home/user/ on host
gridftp.host.net accessible over GridFTP protocol. Based on the protocol
(scheme) part of the URI, the Blacktop can choose the appropriate adaptor in the
Adaptor registry, and dispatch the operation request. This is performed by the
Operation dispatcher component.
Connecting to a storage resource for the

file named

first time can be expensive due to a
number of required initial activities (e.g., creating clients, opening ports, creating
VOMS proxies, etc.). This cost can be avoided in subsequent accesses using ses-
sions . Blacktop creates a session container for each “ ”

to be passed to
the adaptor, which can store any objects related to the current session, to be reused
in subsequent calls. The Blacktop ensures that the same session container is passed
to the adaptor on subsequent requests from the same client, and also ensures that
objects within the container are properly closed on session timeout before being
discarded. These tasks are performed by the Session manager component.
In contrast to synchronous operations (such as list , mkdir , rmdir , delete ,
rename ), which are known to be completed when the operation response is
returned, the execution of copy and move operations may take a longer time (even
hours, which likely exceeds client sessions). Such asynchronous transfers are
performed simultaneously, and for this reason, copy/move operations return a
reference ( id ) of the related transfer just started. This id can be used to poll ( get-
State ) progress (bytes transferred) or state details information (transferring, done,
failed) about the task, or abort it ( cancel ), respectively. The Blacktop maintains,
creates, and passes a so-called transfer monitor object ( listener ) for each transfer to
the corresponding adaptor, through which progress and status information can be
updated by the related adaptors. Transfer monitors are managed by the Transfer
manager component.
An adaptor may declare to support copy operations itself between the handled
storage resources (e.g., an adaptor can exploit third-party transfer between GridFTP
servers or S3 regions). In this case, such a copy task is entirely delegated by the
Blacktop to the adaptor for optimum performance. In other cases, however,
Blacktop performs copy or move operations via streaming, by reading and writing
resource input and output streams (e.g., copy between storage resources managed
by different adaptors).
File uploads and downloads are performed via so-called aliases . Aliases are
unique, temporary HTTP URLs created on the Blacktop host, which can be read
(HTTP GET) or written (HTTP PUT or POST) over HTTP protocol. This interface

client session