Information Technology Reference
In-Depth Information
This characteristic has been most important for HELIOGate, whose infrastructure
had to change from a gLite Grid to a PBS cluster when Grid Ireland was discon-
tinued. As SCI-BUS allows a clean design where workflows, applications, user
interfaces, and infrastructure are clearly separated in their own layers, it allowed
HELIOGate to be migrated from grid to cluster minimizing the disruptions. On the
other end, the process of designing and developing workflow-oriented applications
for heliophysics has taken full advantage of the flexibility offered by the abstract
and concrete workflow levels and by the possibility of creating interfaces to the
users that hide all the information that is not strictly needed.
One of HELIOGate
is main functionalities is support for the analysis of how
physical phenomena propagate throughout the Solar System. To support this,
HELIOGate has developed a flexible and versatile set of workflows that take full
advantage of the possibilities offered by SCI-BUS.
Users who want to de
'
ne the very nature of their propagation models can create
their own abstract workflow by composing the existing abstract atomic workflows
that describe basic invocations of the HELIO services. If users do not need this
level of control, they can choose the existing abstract workflows that already
describe the desired behavior. Abstract workflows cover the basic modalities:
simple, assisted, validated, and different combinations of these flavors. By selecting
or designing abstract workflows, users de
ne the topology of the workflows, and
they define the methodology for their approach.
Users who are satis
ed by existing methodologies (abstract workflows) but want
to de
ne implementation details can either select or compose a concrete workflow.
At this level, users can de
ne the scripts or code that will be invoked upon exe-
cution of the node and, most importantly, they can de
ne the cross- and dot-product
patterns that will govern the execution of parameter sweep jobs for the parametric
propagation models. The richness of details that can be set at the concrete workflow
level is usually far too great for an average user who is concerned mainly with the
input of parameters and the analysis of results. For these users, simple views are
available that can be automatically obtained by constraining the level of freedom of
the concrete workflows. By allowing the user to only de
ne the input values, a
simple but useful interface can be offered for each concrete workflow.
Users who do not want to be concerned at all about the underlying technology
and whose investigations can be tackled by the advanced propagation model
approach can use the dedicated portlet. Up to now, users could be seen as belonging
to two main categories: users who have an interest in developing workflows and
who want to be in complete control of all aspects of the model that will use the
abstract and concrete levels for their own work, and users who are mainly focused
on the scienti
c aspect and who are inclined to use exclusively the simple interfaces
and the dedicated portlet.
Finally, users who want to use non-native workflow languages (such as
TAVERNA) can use the workflow interoperability capabilities offered by the
SHIWA technology.
The user experience for the data processing extends the concepts above with yet
another problem. While the study of propagation models relies on existing services
Search WWH ::
Custom Search