Information Technology Reference
In-Depth Information
(conferences, visiting other scientists, etc.), they can access the DCIs and run
applications on them. Recognizing these advantages, more and more scienti
c
communities have decided to build such gateways in order to simplify their use of
the various DCIs.
Using the terminology introduced by the EGI Science gateway Virtual Team,
science gateways (SG) can be divided into two main categories (Lovas 2013): SG
frameworks and SG instances.
SG frameworks
or generic DCI gateway frame-
works are not specialized for a certain scienti
c area, and hence scientists from
many different areas can use them. National Grid Initiatives (NGIs) are good
candidates to set up such gateways to support their very heterogeneous user
communities. Typical gateways belonging to this category are the Catania Science
Gateway (Rotondo 2012), GridPort (Thomas 2001), Vine Toolkit (Dziubecki
2012), and WS-PGRADE/gUSE (Kacsuk 2012). These gateways usually expose a
large set of low-level services for their users. On the one hand, this is an obvious
advantage, but on the other hand in order to exploit their full power, scientists need
a relatively long learning period to ef
ciently use all the available features. The
powerful but complex functionalities offered by a generic SG may be too com-
plicated for end-users but could represent the right abstraction level for IT spe-
cialists, who can develop DCI applications for the scientists.
SG instances
or application-speci
ned set of scientists
typically working in a specific field of science. They provide a simplified user
interface that is highly tailored to the needs of the given scienti
c SGs target a well-de
c community. As a
result, the scientists do not have to learn too much to use the functionalities pro-
vided by the gateway. On the other hand, these services are limited, and hence if a
scientist needs a more complex service, for example, utilizing a new type of DCI,
this cannot be easily created and managed by these gateways. There are two options
in order to create such SG instances there are two options.
The
first option is to write the gateway from scratch. Since the services needed
for a particular community are typically limited, and there are good technologies for
the construction of web portals, like Liferay, it is relatively easy to develop such SG
instances (compared with the development of an SG framework). However, such
simpli
ed gateways typically support the use of only one particular DCI and
possibly do not support some advanced features such as work
ow execution. Some
communities selecting this option may underestimate the required manpower and
time to produce a robust gateway that can be provided as a production 24/7 service
for the large number of members of the community. Problems that typically arise
once the gateway goes into production and becomes successful are scalability (to
cope with more users than initially planned) and
flexibility (to add new functions
requested by the users). Moreover, while building and maintaining such gateways,
the different communities usually solve again and again the same technical issues
independently from each other, which could be avoided by reusing and customizing
solutions implemented by SG frameworks.
The other option is to customize an existing versatile SG framework according
to the needs of a certain user community. In this case the full power of the
underlying portal
framework can be exploited,
for example, by developing
Search WWH ::
Custom Search