-To support scientists of different disciplines, different fields of Computer Science have developed tools and infrastructures with the aim of giving them access to vast computational resources in the easiest possible way. Such extremely complex structures have evolved naturally in the last decades both in depth and breath and, in addition to scientists, a plethora of heterogeneous actors (system administrators, developers, etc.) cooperate and interact with them. This complex and unstructured flow of actions and information poses difficulties in the development and usage of Science Gateways because information can be missing or hard to isolate at the right layer. In this paper, we aim to start a discussion on how to best manage these information flows to help the design and implementation of more flexible and userfriendly Science Gateways and workflow management systems in the future. Index Terms-Workflows, eScience Portals, eInfrastructures, Science Gateways, Information Flows, Interoperability, Distributed Computing Infrastructures, Workflow Management Systems
In modern days, science relies on computation to such an
extent that the term in silico has been added to the terms in
vivo and in vitro. To support scientists of different disciplines
in accessing computational resources that are ever growing in
size and complexity, different fields of Computational Science
have developed tools and infrastructures that fall under the
broad definition of Science Gateways (SGs) [
The challenges posed by the need to harness distributed
computing infrastructures (DCI) that vary greatly in their
implementation, such as Clouds, Grids, Desktop Grids and
High Performance Computing, have been at the center of
many successful efforts [
The need to formalize and share the scientific process
have also been satisfied by different scientific communities by
adopting the workflows concept originally developed for the
industry. Several such workflows [
All these layers, of infrastructure and workflows, are connected to each other by flows of requests and replies that are unstructured and heterogeneous by nature. Requests propagate downward from the upper to the lower layers, while replies propagate upward from the lower to the upper layers and eventually reach the users who originated them. Replies carry information on the status and on the outcome of the request (often merged together), offering to the upper layer a partial view on the overall information of the lower layer.
These multi-layered infrastructures are used by a plethora
of actors with different skills [
The complexity of these information flows poses relevant
difficulties in the development and usage of Science Gateways,
as information can be missing or hard to isolate at the right
layer. This is true both for scientific users and administrators
(e.g. error messages can be absent or difficult to understand),
but also for developers as it is difficult to build systems that
autonomously react to undesired events, and to dispatch the
right information type to the proper users.
In this paper we start a discussion on how to best manage
these information flows to help the design and implementation
of more flexible and user-friendly Science Gateways and
Workflow Management Systems in the future. The first step
of this discussion is to propose a model to describe these
information flows and the architecture that hosts them. The
domain we are attempting to model is extremely vast and
diverse, so we start by analyzing a sub-domain encompassing
solutions with which the authors are well acquainted. Also,
this paper proposes a qualitative approach without any formal
description that will be attempted after the initial model has
been validated. The overall goal is to increase the usability
for the diverse user groups of Science Gateway systems. Our
model considers standards, setting the context and suggesting
methods for measuring user experience. Such standards
include CISU-R (Common Industry Specification for Usability
Requirements) [
The paper is structured as follows: Section II introduces preliminary concepts and terminology, and Section III introduces the model to describe the information flows. Section IV describes some currently used tools and technologies and Section V discusses the road ahead.
mds May 10, 2016
The proposed model is based on the followig assumptions and concepts. Firstly, we assume that Science Gateways are composed of several Layers. We define a Layer as an entity that represents an element of a Science Gateway. A Layer can have different implementations and it exposes a well-defined set of functionalities to its users. Example of Layers are Presentation and Service Layers, Distributed Computing Infrastructure Layers (e.g. Grids and Clouds), Workflow Layers (e.g. TAVERNA or WS-PGRADE). Each Layer is composed of various Elements and is described by its Status
Elements of each Layer fall into two main categories: structural and transient. Structural Elements are static entities that deliver functions and services inside the Layer (e.g. the Job Execution Service or Information Service in a DCI). Transient Elements are dynamic entities created by the user inside the Layer (e.g. jobs description, files, workflows) to run a specific application. Each Layer can be accessed by Access Components, which are entities that enable access. Access Components can be user-oriented such as Graphical User Interfaces and Command Line Tools or programmatic interfaces such as an API.
Layers communicate through the means of Requests and Replies and are defined by the status of their Structural and Transient Elements. We define their combination as its
exchange of information between Elements in different Layers.
The information flows that describe part of the Information Domains to the upper layers have different characteristics and related challenges. We focus here on three such challenges: Heterogeneous information represents the challenge of high utility information mixed with information of less relevance. Incomplete information represents the challenge that arises when Users cannot directly access all the required information. Finally, the problem ofInformation interoperability arises whenever different implementation of the same Layer impose the use of different languages and interaction patterns to perform the same action.
Also, from each user’s perspective, information flows may be more or less useful and more or less easy to manipulate. To describe this, we introduce the concepts of Utility, Cost and Value. Utility defines the usefulness to the user, Cost describes the difficulty to obtain the information and Value represents the difference between the two.
To increase the overall Value of the information, we have observed that the scientific communities have devised different systems. Heterogeneity Reduction Functions do not modify the Utility of information but reduce the Cost associated to their fruition. Information Extension Functions increment the Utility of information while maintaining its Cost fixed. Interoperability Functions offer a unified interface to multiple implementations of the same Layer.
The domain we attempt to model spans multiple layers and many different implementations for each layer, therefore it is therefore arduous to draw a conclusive and exhaustive schema. Nevertheless, we observed some recurring architectural patterns that suggest to adopt an abstraction encompassing four main layers:
Scientific Domain layer for interaction with the scientific user using domain concepts.
Generic Portal layer for interaction with generic users and to offer tools and APIs to build the applications of the above layer.
Workflow Management layer, where the processing orchestration is described and executed.
and data, which are normally represented by one or more DCIs.
To model how the different layers and actors interact through Information Flows, we try to simplify such a complex system and then adapt step by step the model to the complexity of real systems.
The layers are examined under the consideration of CISUR, which defines three levels of compliance for usability. Level 1: Context of use must consider individually:
The intended physical and social environments.
Scenarios of use specifying tasks in context.
Any prerequisite documentation/training materials. Level 2: Measures must include:
Performance measures, i.e. achieving user goals.
Satisfaction measures via known questionnaires.
Level 3: The test method specifies how it is planned to evaluate that the requirements are met.
The model focuses at this stage on setting the context regarding level 1: from stakeholders (science gateway and workflow management providers), intended user groups (e.g., domain scientists, administrators) and main goals for each group. The computing and technical environment as well as scenarios are analyzed via case studies. Keeping the model as generic as possible, we aim to incorporate and apply it for diverse physical and social environments.
Here we model a single layer of the full stack and its interactions with the users. It is important to stress that this does not attempt to model an entire stack as a Single Layer but rather to model a generic layer of the full stack.
Figure 1 presents a simple model of a generic layer of the stack, which could be used to model a portal, a workflow submission system or a DCI middleware.
Layer I+1 The proposed model comprises the following entities: Layer I describes a generic Layer in the structure such as a portal, a Workflow Management System, or DCI). Layer I will be described by its Information Domain that includes its status. The description of the status has to take into account the dual, interconnected nature of the Layer: that of its own structure and that of the actions it is performing. An example of this is the possibility of a job to fail because of the inconsistent status of the DCI or because of a failure of the job itself.
Access to Layer I is an Access Component that models APIs for programmatic access as well as command line and graphical user interfaces for direct human interaction. Access Components can restrict access to the Layer depending on Authorization policies.
Structural Elements model the internal components of the layer.
Transient Elements model the objects defined by the user that are currently handled by the layer (e.g jobs or Workflows being managed).
External to the layer, there are either human users or other programmatic entities that connect to it. We model the interactions between these entities as represented in Figure 1 by employing the concepts of Layers, Requests, Replies, Structural Elements, and Transient Elements.
Layer I+1 issues Requests (possibly involving Transient Elements) to the Layer I and obtains Replies in return. It is important to highlight that an action may modify the status of both Structural and Transient Elements of the layer, but the ending status of these entities does not strictly follow the ones that preceded the action (as other events may have occurred while the action was executed). Requests are detailed by parameters that may include Transient Elements or references to them. As an example, the submission of a job to a DCI can be modeled as a Request of a submission action of a Transient Element describing a job that will take as parameters the job description itself, additional parameters and details of the identity of the entity submitting the job. Replies include different, heterogeneous elements such as an exit/error code, job results and logging information.
We also model the situation when users may not be able allowed to issue all Requests to a layer and that they may not be able to directly access the entire set of the Information Domain of the Layer. This can be the case of Authorization policies. We define the subset of the Information Domain accessible by each user as being Directly Accessible.
Finally, we model the different profiles of actors connecting to the layer through three main profiles: Result
Henceforth we will refer to all actors accessing Layer I as Users encompassing in this generic term both human users and programmatic components. In any case, even software components will have to be executed with a certain identity either by delegation, robot certificates or other means. Resultoriented users model actors whose main interest is in the results provided by the layer. They want to be shielded as much as possible from the technical details of the layer. Ideally, a Result-Oriented User would like to treat the entire layer as a black box that would either return the results correctly or, in case of failure, deliver within expected time the result along with a contact point for addressing the issue. Since jobs or tasks can be active over long periods of time, it is important to provide and visualize information for monitoring active jobs. Layer-oriented users model actors that have an opposite view. They are interested in the internals and status of the layer, which should be seen as a transparent box allowing complete access and manipulation of the inner workings. They are mainly concerned with the maintenance of the Structural Elements of the layer. Such users include Workflow Management and DCI Providers, who need detailed information optimization and error resolution. Development-Oriented users Request Domain (Rx) (Implementation X)
Reply Domain (Px) (Implementation X)
Request Domain (Ry) (Implementation Y)
Reply Domain (Py) (Implementation Y)
Value Increasing Components (VIC)
Value Increasing Elements (VIE) model actors whose main focus is the development of either the Structural Elements that compose layers or Transient Elements such as Workflows on behalf of Result-Oriented users.
We also have to model the fact that layers have multiple implementations as presented in 2. In this case Layer I+1 triggers actions and receives results from two separate implementations of the same model. As there is no explicit interoperability provision between the two implementations, Layer I+1 will have to support two separate access modalities (syntax that defines Requests, Transient Elements, Reply formats, etc...) by explicitly dealing with two separate Requests, Replies and Information Domains.
The concepts of Value, Utility and Cost are fundamental in this model, which can be expressed differently for each of the user Profiles. Utility describes how useful the information contained within a Reply is to any particular user profile. The Cost describes how difficult it is to obtain that information, thus covering both the action of extracting information from the Reply and issuing the related Request (e.g. extracting the relevant information about the failure of a Workflows executed on multiple DCIs may be very hard to perform). Finally Value describes the difference between the Utility and the Cost.
Utility, Cost and Value need to be quantified for usage in the proposed model, which is still topic of ongoing debate. A possibility would be to use a real numbers in the range from 0 to 1, where 0 represents low scores. For example, a Request returning useless information (Utility=0) that is very difficult to understand for a particular user profile (Cost=1) would have a Value of -1. Another Request returning useful information (Utility=1) that is very easy to understand (Cost=0) would have a have a Value of +1.
There are three main characteristics that reduce the Value to different user profiles. Firstly the information that has the highest Utility to different User profiles is often mixed with information that has less Utility. We refer to this problem as that of Heterogeneous Information. Secondly, the required information may not be directly reachable by a user, a problem that we refer to as Incomplete Information. Finally, different implementations of the same layers impose the use of different languages and interaction patterns to perform the same action (e.g. the execution of a workflows), which we coin Information
Science Gateway developers have devised different solutions to these problems which we attempt to model as either a Structural Element-Value Increasing Structural Element (VISE), or as a smart Transient Element - Value Increasing Transient Element (VITE). VISE’s are usually result of the effort of Layer-Oriented Users that modify Structural Elements of one Layer to increase its usability by one or more Users. VISE’s are usually the result of efforts by DevelopmentOriented or Result-Oriented Users that modify job descriptions or workflows to increase the usability of one Layer, for example jobs or Workflows that internally manage information flows and/or automatically perform value-adding actions.
Layer I+1 Request Domain (R*)
User Reply Domain
(P*)
VISE
Information Domain (I*)
We envisage four main types of operations to increase the value of Information Flows, the so called .
1) Heterogeneity Reduction Function: They are filtering functions that isolate sub-set of a Reply in order to make it more accessible to different user profiles. An example would be a function that filters job results, error codes and logging information. Result-Oriented Users will see only the job result, if any, while Layer-Oriented Users will see only error codes and logging information, if directly available. These functions do not increase Utility but reduce the Cost thus increasing Value.
2) Information Extension Function: The second type extends the information domain directly available to the user. An example would be a an automatic operation that automatically retrieves information on the status of the Layer (e.g. retrieval and parsing of log files) on the failure of a job. These functions do not modify the status of the Transient Elements in the layer, but the Information Domain made available to the user has a greater Utility and the same Cost thus resulting in increased Value1.
3) Compound Actions: The third type of functions, coined Compound Actions, can perform a variety of actions that can modify the status of the Transient Elements in the Layer. An example would be the execution of pilot jobs prior to the submission of the real job to foresee problems in the layer and/or the automatic execution of diagnostic jobs and routines on the failure of jobs.
of functions, which we coin Interoperability Functions offer a unified interface to multiple implementations of the same layer. Examples are the submission to multiple DCIs infrastructures by a single set of commands or the possibility to execute a workflow written for one Workflow Management System on a different system. These functions offer the combined Utility of several implementation while requesting the same Cost of one implementation, thus radically increasing the overall Value
We argue that there are five different ways in which Layers and VISEs can interact. We also define a set of Improved Requests, Improved Replies and Improved Information Domains provided by the VISE.
The first solution is to use a VISE as an additional, separate Layer as presented in the left part of Figure 4. In this case the upper Layer can access both Improved and Original sets of Requests and Replies. This arrangement supports VISEs that offer abstractions of different implementations of the same Layer allowing for interoperability. Examples are a VISE that optimizes the Information Flow of different DCIs or a VISE that optimizes the information flows from different Workflow Management Systems The central part of Figure 4 shows a VISE embedded within the access component of Layer I The right part of Figure 4 shows an opposite solution where a VISE is embedded in Layer I+1 that uses it in a totally transparent way Figure 5 shows a Multi-Layer VISE that connects to different layers on the left and a Multi-Layer MultiImplementation VISE on the right. A multi-layer VISE has the advantage of offering improved Requests and Replies that combine the Information Domains of multiple layers. A Multi-Layer, Multi-Implementation VISE extends the functionalities of a Multi-Layer VISE across different implementations of the same layer.
The examples presented here represent the experience from a large of Science Gateway-oriented solutions of knowledge to the authors.
Interoperability has been tackled at both the Workflow and
DCI layers within a set of related projects (SCI-BUS [
VISE as part of the access to layer
VISE as internal component Fig. 4. Different ways to connect Layers with Value Increasing Structural Elements
Multi-Layer VISE
Multi-Layer and Multi-Implementation VISE
Fig. 5. Multi-Layer and Multi-Implementation VISEs
SHIWA [
Interoperability at computation infrastructure level is
supported by the gUSE technology, which offers an abstraction
layer to multiple heterogeneous providers (Grid, HPC
resources, Desktop grids) called DCI-Bridge. It can be combined
with another VISE offering an abstraction layer to different
Cloud Providers called CloudBroker [
Interoperability between different implementation of
Workflow systems has been achieved by the SHIWA Interoperability
platform [
Interestingly enough, the solutions fall under two main
categories. The technology-oriented partners in SCI-BUS
composed by Layer-Oriented and Development-Oriented experts
created VISE’s that had structural relevance in the overall
architecture of the system. The domain expert partners
composed mainly by Result-Oriented and Development-Oriented
experts developed multi-layered design patterns for their own
Workflows that acted as Value Increasing Transient Elements
(VITEs). Three out of four communities in ER-FLOW
developed Value-Increasing Transient Elements by creating
multilayered patterns of Workflows [
One of communities used a powerful feature offered by
gUSE that allowed the easy development of interfaces [
This research is still its infancy and further examination will be necessary to evaluate its worth. Firstly, the model has now been used to describe systems that are closely related with each other and developed by interconnected communities, so it may fail when used to describe solutions based on different philosophies such as the HubZero platform. Should the proposed model succeed in describing additional platforms, it could become the basis for further refinement and a more formal approach.
This research would not have been possible without the help and support of all the partners of the ER-FLOW, SCI-BUS and HELIO projects. The authors are particularly grateful to Prof. Kacsuk, Prof Herres-Pawlis, Dr. Sciacca, Dr. Becciani, Dr. Castelli and Dr. Taffoni.