Database Reference
In-Depth Information
Integrating a new Middleware
requires to fulfill a set of 10 main functions
and one optional. Most of them are just type conversions functions from the ex-
isting middleware data-type to the new GridRPC data-types. The most complex
function of a middleware module is
grpc remote transfer()
which initiates a
transfer from a remote host to another remote host. A default implementation
is included in the library relying on a middleware service call: the module de-
veloppers have just to implement this simple service using the library transfer
capabilities on the server side.
Remarks:
-
To avoid “name conflicts” between existing GridRPC implementations and
the new definitions of the library, definitions in the library headers files are
automatically prefixed when needed, allowing an easy reuse of the existing
functions without name-clashing at the compilation step.
-
Note on asynchronous calls: they are internally managed by the library from
synchronous calls to middleware. However, middleware functions must be
reentrant for a safe asynchronous use.
At the moment, the modules for the
Diet
and Ninf GridRPC middleware are
available.
Integrating a New Data Manager Module
requires to provide 4 functions:
2 initialization functions corresponding to input and output data, which can
most of the time be left empty; and 2 transfer functions to get and put a data.
They are generally wrappers of existing transfer protocol libraries (
e.g.,
libcurl
for
http
and
ftp
).
At the moment, the library implements the data manager modules for
rsync
and
scp
, using the shell commands;
iRODS
, using the shell command (the library
is only available for Java and PHP);
webdav
, to access
Owncloud
and
Dropbox
servers. It uses the
neon
library and;
curl
, to access
http
and
ftp
via the
curl
library.
Module Initialization.
The library global initialization process reads the
global configuration file to determine which module should be dynamically loaded
at execution time, where to find it, and some parameters available for each mod-
ule in its own separate section.
The initialization function of each module is then processed sequentially, pass-
ing the arguments of the module specific configuration, and potentially reading
more parameters in the deployed module-specific configuration file.
3.2 Asynchronicity Management
We call a request the inner action managed in the library: they correspond to
API calls for remote procedure, API calls for a transfer or a group of transfers
involving a unique data. For example when one source and several destinations
Search WWH ::
Custom Search