Information Technology Reference
In-Depth Information
CADDSuite (Kohlbacher 2012) is able to handle input containing complete ligand
libraries; these must to be in SDF-format. All these details have to be covered by
user-friendly portlets.
Surveys of user requirements revealed that beside individual needs, all appli-
cation domains have certain elements in common. The workflow has to be selected,
which needs to be accompanied by a structured display of available workflows
including a meaningful description of all tasks. Normally all scienti
c workflows
require the provision of some kind of input data, the de
nition of simulation
parameters, settings for the computational resources, and consequently analysis of
the output. After the submission of a workflow, it needs to be monitored, and the
user should have the possibility to manipulate the data contained in it. These three
main steps de
ne the ground for the import, submission, and monitoring tabs.
For the MoSGrid science gateway a uniform user interface was anticipated to
improve the usability of the portal, while still offering application domain speci
c
adjustment. This goal was reached by creating the PortletAPI, a generic framework
used to generate portlets. The PortletAPI uses the ASM API for the management of
the whole lifecycle of pre-con
gured workflows and is based on MSML (Grunzke
2013) templates (Sect.
11.3.1
). The PortletAPI takes advantage of Vaadin (Gr
รถ
nroos
2010), a Java framework for building web applications and portlets. Vaadin offers a
large library of GUI components and facilitates the communication handling
between server-side and client-side components. There are a multitude of services
hidden from the user, which are handled through the PortletAPI. To name only a
few, gUSE workflow imports, ASM-based workflow management, remote
le
access, and metadata handling are covered. Although all domain-speci
c portlets
have these services in common, speci
c extensions are possible by overwriting the
default implementation in one of many extension hooks.
In order to include a new application, or even a new application domain into the
MoSGrid portal, only a few extensions have to be made, due to the concept of the
PortletAPI. First of all, the application has to be installed on a remote DCI con-
nected to MoSGrid through the UNICORE middleware. The IDB of UNICORE
offers a uniform interface enabling UNICORE clients, such as the MoSGrid portal
to send jobs to DCIs where the desired application is actually available. The
applications reside completely on the DCI-side, and speci
c details, e.g., installa-
tion path or modules, are completely included in the IDB. Relying on a common
name for an application versioning and provision of computing resources is largely
standardized. The input parameters for a given application are de
ned within an
MSML dictionary. Default values and ranges have been proven to be very useful to
guide inexperienced users. For expert users most values can be left freely editable.
The PortletAPI is capable of reading a workflow-speci
c template and dynamically
creating a GUI containing a parameter masks corresponding to all jobs inside the
workflow.
Since MoSGrid is based on gUSE, it offers a gateway-wide workflow repository
providing access to all workflows with their default settings. Before a workflow can
be submitted, it needs to be imported into the user
s local repository. The MSML
template accompanying each workflow contains a unique identi
'
er allowing the
Search WWH ::
Custom Search